credo sia una svista: non ho convertito le coords dal formato ED50 in WGS84 quando ho fatto la conversione degli shapefiles.
purtroppo ho il SW necessario altrove e posso rifare il tutto solo la prossima settimana.
ti faccio sapere.
Allora: ho ricostruito la cosa. quello che avevo linkato ieri era un tentativo andato male di usare gli shapefiles dell'istat.
Quello che linko di seguito è invece stato costruito sui dati reperibili su geonames.org; questi dati sono pieni di duplicati che avevo in parte corretto... Quindi, dovrebbe funzionare ma va testato estensivamente!
Nel caso in cui funzionasse invierò la patch alla issue queue del modulo.
Se lo usi fammi sapere
Atenzione ad un problema, gli Zip code sono chiavi univoche per i DB, ma in italia i CAP non lo sono (più paesi possono avere stesso CAP, o stesso paese può avere CAP differenti). Purtroppo i problemi che ne derivano sono alquanto insidiosi e non facilmente risolvivili. Non so se con le ultime relese hanno sistemato, ma quando l'ho usato io mi ha dato non poche noie. -.-
infatti..
il mio obiettivo originale era di tirar fuori dei centroidi dai poligoni .shp di ciascun CAP partendo dai dati che ha rilasciato l'istat l'anno scorso. Questo in modo da avere 1 solo record per ciascun CAP.
Purtroppo mi sono impantanato e ho ripiegato su geonames.org.
Vorrei riprovarci ma forse è più efficiente lavorare sull'API di Gmaps in modo da tirar fuori le coordinate o il CAP quando uno solo dei 2 valori viene inserito.
Che ne dici?
Sto provando a caricare il file da qualche ora ma continua a darmi errore di max execution time. Sistemando il file mysql come gli altri ne carica quasi il doppio ma mi si blocca comunque.
Volevo caricarli un po' alla volta, ma visto i problemi indicati da Mavimo ed il fatto che funziona bene anche senza per il momento ho cambiato idea.
@Bohz: il problema non sono solo le coordinate, purtroppo tutto il sistema è basato sul fatto dell'univocità Paese/CAP, o si omettono dei comuni (e si accorpano) o il sistema non regge. Purtroppo per quello che dovevo fare io non potevo accorpare i comuni, fare la modifica voleva dire riscriver buona parte delle API fondamentali di Location, quindi -nonostante ci avessi provato- ho dovuto abbandonare l'idea.
Altre soluzioni potrebbero essere di usare i CAP e triangolare le posizioni, ma non è molto preciso, dalle mie parti ci sono comuni lontani anche 40km che hanno lo stesso CAP (e in mezzo altri comuni con un CAP diverso), quindi si otterrebbe un dato molto impreciso e "antipatico" per i possibili risultati che fornisce.
Purtroppo la VERA soluzione è la prima, ma non facilmente praticabile a causa dell'elevato lavoro da fare per riuscire ad inserire questa funzionalità, magari le nuove API che dovrebbero essere state introdotte un paio di mesi fa hanno reso più semplice l'inserimento, non so, dovrei riguardarci... :/
Mi sorge il dubbio che, essendo il DB dei CAP proprietà delle Poste (che lo vendono), distribuire questi file possa non essere legale. Non per terrorizzarvi, eh, ma credo che il problema vada posto.
@pinolo: ho avuto anche io questi dubbi però:
1. i dati che ho usato non sono "pirati" ma provengono dalla FSF e/o dall'ISTAT; in entrambi i casi ci sono margini più o meno ampi per un uso non commerciale DIRETTO dei dati (ovvero vendere i dati "as is")
2. nel caso del modulo location, si tratta di una rielaborazione ai semplici fini di geolocalizzazione dei contenuti e quindi, anche se usati in un sito commerciale, i dati sarebbero usati in modo non direttamente connesso con i profitti
...ma non sono un legale nemmeno io quindi sono d'accordo che la cautela è d'obbligo.
@krima: sto lavorando ad una versione con i soli centroidi dei CAP, senza i nomi dei comuni (vedi zipcodes.uk.mysql) che bypassa il problema descritto da @mavimo, al momento ho dei problemi con alcuni valori errati (il 5% circa) difficili da individuare...
@lorenzo: mandarini, please, che le arance mi fanno acidità, specialmente dopo pasti a base di pane e acqua
Questo ti può aiutare?
http://drupal.it/node/6179
<--- Andrea Mancini - biso.it --->
Grazie ma non è quello che cerco. Potrei anche crearlo quel file, ma essendo un lavoraccio speravo di trovarlo già pronto.
cosa fa il mdulo location?
E' scritto qui: http://drupal.org/project/location
@krima:
il lavoraccio lo feci io a suo tempo. vedi se va e facci sapere:rimosso perchè le coordinate sono sbagliate. strano. cerco la versione corretta :(
Certified to Rock
Grazie :-) anche se non riesci a trovarlo...
Ho visto che il modulo funziona bene comunque.
credo sia una svista: non ho convertito le coords dal formato ED50 in WGS84 quando ho fatto la conversione degli shapefiles.
purtroppo ho il SW necessario altrove e posso rifare il tutto solo la prossima settimana.
ti faccio sapere.
Certified to Rock
Ottimo! Magari se ti va potresti segnalarlo qui: http://drupal.org/project/issues/location?text=&status=Open&priorities=A...
Allora: ho ricostruito la cosa. quello che avevo linkato ieri era un tentativo andato male di usare gli shapefiles dell'istat.
Quello che linko di seguito è invece stato costruito sui dati reperibili su geonames.org; questi dati sono pieni di duplicati che avevo in parte corretto...
Quindi, dovrebbe funzionare ma va testato estensivamente!
Nel caso in cui funzionasse invierò la patch alla issue queue del modulo.
Se lo usi fammi sapere
http://rapidshare.com/files/414080607/geonames-zipcodes.it.zip
Certified to Rock
Ottimo! Lo provo e ti faccio sapere.
Intanto, grazie mille!!!
...ecco, lo sapevo...
lat e lon sono invertite, che palle!
a tra poco per una versione (speriamo) testabile.
...sorry
Certified to Rock
...aggiornato il link in #9, speriamo per l'ultima volta...
Certified to Rock
Atenzione ad un problema, gli Zip code sono chiavi univoche per i DB, ma in italia i CAP non lo sono (più paesi possono avere stesso CAP, o stesso paese può avere CAP differenti). Purtroppo i problemi che ne derivano sono alquanto insidiosi e non facilmente risolvivili. Non so se con le ultime relese hanno sistemato, ma quando l'ho usato io mi ha dato non poche noie. -.-
Ciao
Marco
--
My blog
Working at @agavee
infatti..
il mio obiettivo originale era di tirar fuori dei centroidi dai poligoni .shp di ciascun CAP partendo dai dati che ha rilasciato l'istat l'anno scorso. Questo in modo da avere 1 solo record per ciascun CAP.
Purtroppo mi sono impantanato e ho ripiegato su geonames.org.
Vorrei riprovarci ma forse è più efficiente lavorare sull'API di Gmaps in modo da tirar fuori le coordinate o il CAP quando uno solo dei 2 valori viene inserito.
Che ne dici?
Certified to Rock
Sto provando a caricare il file da qualche ora ma continua a darmi errore di max execution time. Sistemando il file mysql come gli altri ne carica quasi il doppio ma mi si blocca comunque.
Volevo caricarli un po' alla volta, ma visto i problemi indicati da Mavimo ed il fatto che funziona bene anche senza per il momento ho cambiato idea.
Se vuoi il file modificato puoi scaricarlo da qui
@Bohz: il problema non sono solo le coordinate, purtroppo tutto il sistema è basato sul fatto dell'univocità Paese/CAP, o si omettono dei comuni (e si accorpano) o il sistema non regge. Purtroppo per quello che dovevo fare io non potevo accorpare i comuni, fare la modifica voleva dire riscriver buona parte delle API fondamentali di Location, quindi -nonostante ci avessi provato- ho dovuto abbandonare l'idea.
Altre soluzioni potrebbero essere di usare i CAP e triangolare le posizioni, ma non è molto preciso, dalle mie parti ci sono comuni lontani anche 40km che hanno lo stesso CAP (e in mezzo altri comuni con un CAP diverso), quindi si otterrebbe un dato molto impreciso e "antipatico" per i possibili risultati che fornisce.
Purtroppo la VERA soluzione è la prima, ma non facilmente praticabile a causa dell'elevato lavoro da fare per riuscire ad inserire questa funzionalità, magari le nuove API che dovrebbero essere state introdotte un paio di mesi fa hanno reso più semplice l'inserimento, non so, dovrei riguardarci... :/
Ciao
Marco
--
My blog
Working at @agavee
Mi sorge il dubbio che, essendo il DB dei CAP proprietà delle Poste (che lo vendono), distribuire questi file possa non essere legale. Non per terrorizzarvi, eh, ma credo che il problema vada posto.
Ho trovato questa vecchia discussione che è vicina credo a questo problema:
http://drupal.org/node/31685
http://www.indiapost.gov.in/Pincode.html
(le arance a Boz gliele porto io :D )
questo l'avrete già visto
http://forums.mysql.com/read.php?23,3868,188087
Lavatrice ad ultrasuoni
Sito http://www.ultrasuoni.net > Client service and contacts: [email protected]
@pinolo: ho avuto anche io questi dubbi però:
1. i dati che ho usato non sono "pirati" ma provengono dalla FSF e/o dall'ISTAT; in entrambi i casi ci sono margini più o meno ampi per un uso non commerciale DIRETTO dei dati (ovvero vendere i dati "as is")
2. nel caso del modulo location, si tratta di una rielaborazione ai semplici fini di geolocalizzazione dei contenuti e quindi, anche se usati in un sito commerciale, i dati sarebbero usati in modo non direttamente connesso con i profitti
...ma non sono un legale nemmeno io quindi sono d'accordo che la cautela è d'obbligo.
@krima: sto lavorando ad una versione con i soli centroidi dei CAP, senza i nomi dei comuni (vedi zipcodes.uk.mysql) che bypassa il problema descritto da @mavimo, al momento ho dei problemi con alcuni valori errati (il 5% circa) difficili da individuare...
@lorenzo: mandarini, please, che le arance mi fanno acidità, specialmente dopo pasti a base di pane e acqua
Certified to Rock