formato json non corretto

[marlenesco]

Ciao @matteocontrini sto usando il tuo repository per un progetto, grazie prima di tutto per averlo messo su github, volevo dirti che il formato json è errato e non viene parsato correttamente, è solo una piccola cosa, basta mettere tutto entro parentesi quadre.

[matteocontrini]

Ciao e grazie, hai perfettamente ragione. Non è un formato JSON valido. Non l'ho usato direttamente per cui non ci ho fatto nemmeno caso. Ti faccio notare anche che al momento il file non è completo perché non include i range di CAP per i comuni che hanno più CAP! Me ne sono accorto da poco e proverò ad aggiornarlo nei prossimi giorni 😄

[marlenesco]

Ciao e grazie per la risposta, guarda, sarebbe molto utile avere anche i range dei cap per i comuni che li includono, inoltre, almeno per me sarebbe utile avere direttamente anche un sql ma questo posso farlo anche successivamente via query, la cosa assurda che ho notato facendo alcune ricerche è che è possibile avere questi cap solo a pagamento dal sito delle poste. Fortunatamente, e per puro caso, sono incappato su un retweet di @lorenzoferrarajr, un mio caro amico che mi aveva fatto scoprire questo repository. Altra cosa, sarebbe utile mettere composer e/o bower al repository. Farei una pull-request se avessi un po' di tempo da dedicarci ma sono troppo incasinato. Comunque grazie ancora e un saluto.

[matteocontrini]

Ho trovato il modo di raccogliere facilmente di nuovo tutti i CAP aggiornati ad aprile, anche con i "range", che in realtà si chiamano zone postali. Ora però non so come includere nella struttura JSON questi intervalli. Una opzione sarebbe inserire nel campo cap che è una stringa una cosa del tipo 40121-40141. Altra opzione sarebbe lasciare cap vuoto e usare altri due campi per indicare il valore minimo e massimo dei CAP delle zone postali. Altra soluzione ancora, che per l'uso che ne faccio sarebbe la più adeguata, sarebbe far diventare il campo cap un array con tutti i CAP (uno se il cap è singolo, N se il cap è multiplo). Quest'ultima soluzione mi sembra particolarmente adatta a database NoSQL che uso prevalentemente, e semplificherebbe le query. Tu che usi SQL cosa preferiresti avere?

Per lo script SQL che hai chiesto, preferisco tenere la struttura generica come un file JSON in modo che ognuno poi possa utilizzarla come vuole :)

Stessa cosa vale per l'aggiunta ai vari package/dependency manager. Oltre al fatto che non conosco bene né Composer né Bower (uso npm), non considero il file di questa repository come una dipendenza "diretta", piuttosto come una fonte da scaricare ed elaborare per poi essere integrata in un'applicazione.

[marlenesco]

Ciao Matteo, scusa il ritardo ma durante il ponte non ho potuto risponderti, allora, la soluzione dell'array credo proprio sia la migliore, anche perché non è detto che se usi un range hai tutti i numeri, ad esempio, analizzando la provincia di Rieti, avresti 02010-02100 ma non hai 90 cap ma 73.

Per quanto mi riguarda, io non ho bisogno di un db nosql il mio problema è molto più semplice, ho preso il tuo comuni.json e l'ho importato in mysql tramite Mysql Workbench, tramite una serie di query poi l'ho adattato a quello che mi serviva che sarebbe una singola tabella con pochi campi, non il massimo dell'eleganza ma semplice, sotto uno screenshot della tabella coi primi 8 record:

Questo perché la mia necessità è abilitare o meno delle lead generation e fare un controllo sulle lead provenienti da google una comune ricerca google, se la zona non è coperta dal servizio (controllo tramite cap) allora devo avvisarlo. Sto creando un bundle symfony ad-hoc per questa cosa. Ultimissima cosa e metto le mani avanti, io sono un Front end developer che si arrangia con symfony 3, non sono un mago del php ne di sql.

Ciao e grazie ancora @matteocontrini

[matteocontrini]

I range di CAP sarebbero per il comune, non per la provincia. Ad esempio Torino come comune ha un intervallo 10121-10156 ed è continuo nel senso che ogni numero nell'intervallo è assegnato a una zona di Torino città.

Proverò a lavorarci comunque

[lorenzoferrarajr]

Ciao @matteocontrini e @marlenesco,

la soluzione proposta da @matteocontrini

far diventare il campo cap un array con tutti i CAP

penso sia l'approccio migliore. Personalmente lascerei il campo cap un array anche se c'è un solo codice e userei gli intervalli quando possibile. L'utilizzo degli intervalli rende le ricerche un po' più complicate, ma migliora tanto la manutenibilità del JSON (sarebbe comunque facile generare un JSON derivato con tutti i CAP elencati).

Esempio della struttura:

{
  "nome" : "Ala di Stura",
  "codice" : "001003",
  ...
  "cap" : [
    "10069",
    "10070",
    [
        "da": "10072",
        "a": "10075"
    ],
    [
        "da": "10077",
        "a": "10078"
    ],
  ]
}

[matteocontrini]

Ciao @lorenzoferrarajr, la struttura che proponi non è un JSON valido però. Inoltre non esistono comuni con più intervalli o comuni con CAP singoli e intervalli.

La mia proposta sarebbe stata eventualmente una cosa del genere:

{
  "nome": "Bologna",
  "cap": ["10140", "10141", "10142", "10143"]
}

che faciliterebbe, almeno nel mio caso, le ricerche del comune dato il CAP.

[lorenzoferrarajr]

@matteocontrini giusto, parliamo di comuni e non di province. Quindi la soluzione che proponi mi pare la migliore.