Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Il 23 novembre 2011 12:16, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2011/11/23 Ruggero giurr...@gmail.com: questo edit è mio: sinceramente non ci vedo niente di male, meglio una informazione in più che una in meno. Il database di suo non si lamenta. secondome non va bene meglio una informazione in più che una in meno +1 alcune informazioni sono inutili...pensavo che cose del genere in italia non accadessero, ho preso un po' in giro i giapponesi a sotm per alcuni import che hanno fatto, ma avrei prima dovuto guardare bene in casa mia :-( se non si tratta di informazioni geografici ma informazioni riguardando un altro dataset. Se tutto il mondo riempie il database con informazioni inutili (per OSM) riguardando datasets di terzi lo spazio richiesto per gestire i nostri dati diventa immenso (e si rallenta moltissimo l'elaborazione dei nostri dati senza guadagnare niente). e complica un sacco la possibilità di utilizzarli...perchè non tutti hanno terabyte di spazio nelle loro macchine/cluster Posso capire che si spera che la nuova versione del dataset CTR / Lombardia mantiene gli ID. Allora serve _una_ chiave per connettere i due datasets, non 14. +1 I codici ASL e ISTAT per esempio non sono dati specifici della CTRN della Lombardia, o sbaglio? +1 it:lombardia:ctrn:cod_asl = 4 it:lombardia:ctrn:cod_istat = 19060 Va bene che si capisce che abbiamo preso i dati dal CTRN, ma si potrebbe mettere questa informazione nei changeset comments dove appartiene. Se manca un tag per una zona ASL o ISTAT allora inventiamolo, ma non credo che il suo prefisso dovrebbe essere it:lombardia:ctrn. basterebbe un ref:asl o un ref:istat Non sto criticando questo import in particolare, anzi sono contento che qualcuno si è dato per farlo, ha messo tempo suo per noi, grazie. Invece ho aperto questo thread per discutere come possiamo agire nel futuro in casi simili. per prima cosa parlandone in lista o documentare sul wiki quello che si vuole fare e poi passare il link in mailing list ciao, Martin -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
-Original Message- From: Luca Delucchi [mailto:lucadel...@gmail.com] Sent: venerdì 2 dicembre 2011 15:50 To: openstreetmap list - italiano Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga e complica un sacco la possibilità di utilizzarli...perchè non tutti hanno terabyte di spazio nelle loro macchine/cluster Anche la fondazione avrebbe bisogno di nuovo hardware per tenere il passo con le dimensioni dei dati, e ha aperto una colletta [1] per finanziarne l'acquisto [1] http://blog.osmfoundation.org/2011/12/01/funding-drive/ Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Il 02 dicembre 2011 19:19, Alberto Nogaro bartosom...@yahoo.it ha scritto: Anche la fondazione avrebbe bisogno di nuovo hardware per tenere il passo con le dimensioni dei dati, e ha aperto una colletta [1] per finanziarne l'acquisto scusa ma c'è già un altro thread su questo argomento ;-) Ciao, Alberto -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Come da oggetto: la Lombardia sta messo bene nella competizione per la chiave più lunga. Guardate questa statistica e invertite l'ordine: http://taginfo.openstreetmap.org/reports/key_lengths#keys E' pieno di tags del genere: it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3 vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se chi importa dati da ctr si tiene un database a parte dove si memorizza quale entità osm è correllato a quale oggetto / livello della ctr? Secondome il tag da usare in osm è boundary=administrative admin_level=x non è it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3 o it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_7-10 informazioni del tipo lista 1 si possono benissimo mettere nel commento del changeset. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo? :) No, scherzi a parte, mi sembra che sia un import senza un minimo di elaborazione, come i confini istat che hanno chiavi simili a quella, bisognerebbe toglierli ed usare lo standard esistente. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
2011/11/22 Martin Koppenhoefer dieterdre...@gmail.com: vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se chi importa dati da ctr si tiene un database a parte dove si memorizza quale entità osm è correllato a quale oggetto / livello della ctr? Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non importarlo. Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora va importato in OSM perché è l'unico posto che può mantenere memoria della correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way, e quindi non sono una buona chiave primaria) Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
2011/11/22 Federico Cozzi f.co...@gmail.com: Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora va importato in OSM perché è l'unico posto che può mantenere memoria della correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way, e quindi non sono una buona chiave primaria) non è un problema se cambia l'ID osm. Nello storico viene tutto conservato ;-) Se faccio un merge / split di una way del genere ho una seria di altri problemi (dovrei cambiare probabilmente tanti tags, vedi sotto). Secondome non ha senso replicare il database di un altro ente in OSM, come è stato fatto qui. Guardate qui: http://www.openstreetmap.org/browse/way/44356578 admin_level = 8 boundary = administrative it:lombardia:ctrn:area = 0.0 it:lombardia:ctrn:cod_asl = 4 it:lombardia:ctrn:cod_istat = 19060 it:lombardia:ctrn:cod_istatn = 03019060 it:lombardia:ctrn:cod_pro = 19 it:lombardia:ctrn:cod_reg = 03 it:lombardia:ctrn:dstrato = Comune it:lombardia:ctrn:nome_asl = CREMONA it:lombardia:ctrn:nome_com = MOSCAZZANO it:lombardia:ctrn:nome_pro = CREMONA it:lombardia:ctrn:nome_reg = LOMBARDIA it:lombardia:ctrn:perimeter = 19115.05364 it:lombardia:ctrn:sig_pro = CR it:lombardia:ctrn:strato_ctr = CO name:left = Ripalta Guerina name:right = Moscazzano __ alcuni tags hanno senso, ma un identificativo istat non è per esempio un tag specifico per la Lombardia. A cosa serve un perimetro, poi in precisione assurda ( 0.00 mm)? Cosa significa it:lombardia:ctrn:area = 0.0 ? Cosa identifica il codice ISTAT, questo way o una delle aree che delimita? Dove si trova la documentazione? Invece mancanno i dati che interessano: Da quando sono questi dati?. Come mi devo comportare se correggo un oggetto del genere? Devo modificare la lunghezza del perimetro? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Il giorno 22 novembre 2011 11:29, Federico Cozzi f.co...@gmail.com ha scritto: 2011/11/22 Martin Koppenhoefer dieterdre...@gmail.com: vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se chi importa dati da ctr si tiene un database a parte dove si memorizza quale entità osm è correllato a quale oggetto / livello della ctr? Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non importarlo. Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora va importato in OSM perché è l'unico posto che può mantenere memoria della correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way, e quindi non sono una buona chiave primaria) Ciao Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire alla fonte? Così facendo probabilmente i dati non si evolvono perchè rimangono legati a come erano in origine. Così l'ho pensata, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
2011/11/22 sabas88 saba...@gmail.com: Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire alla fonte? Supponiamo che la Lombardia ci dia i dati aggiornati, e supponiamo anche (estrema fortuna) che conservino gli ID. Potremmo ipotizzare di aggiornare i dati già importati con i nuovi dati. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
2011/11/22 Federico Cozzi f.co...@gmail.com: 2011/11/22 sabas88 saba...@gmail.com: Ma se uno fa un import, perchè dovrebbe dover aver bisogno di risalire alla fonte? Supponiamo che la Lombardia ci dia i dati aggiornati, e supponiamo anche (estrema fortuna) che conservino gli ID. Potremmo ipotizzare di aggiornare i dati già importati con i nuovi dati. Nel caso dove noi non abbiamo toccato un way di solito dovrebbe aver mantenuto il suo ID osm e nel caso che noi abbiamo modificato un way vorrei mantenere il nostro way modificato, non quello del CTR aggiornato. In una ipotesi teorica potrei imaginare che noi per la nostra organizzazione dei dati abbiamo spezzato / unito un way (se abbiamo potuto unire probabilmente il dato originale non era ottimo) senza cambiare effettivamente qualcosa. Comunque per capirlo dovresti vedere la versione di ogni nodo contenuto nel way e paragonarla alla versione che aveva quando il way è stato creato. Out of curiosity: ma i CTR, vanno fatto in un modo che gli oggetti si mantegono la loro ID da una versione all'altra? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Il giorno 22 novembre 2011 10:25, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Come da oggetto: la Lombardia sta messo bene nella competizione per la chiave più lunga. ... è inutile: noi meridionali siamo veramente indietro di quarant'anni, anche su queste cose... :-) Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
-Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: martedì 22 novembre 2011 10:25 To: openstreetmap list - italiano Subject: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga E' pieno di tags del genere: it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID_lista1-3 Riconosco questo tag ;-) La parte it:lombardia:ctrn:Limite_amministrativo_09 serve ad identificare la fonte come lo strato denominato Limite_amministrativo_09 della Carte Tecnica Regionale della Regione Lombardia. Forse si poteva abbreviarlo, ma sarebbe diventato ancora più criptico. La parte OBJECTID serve per dire che quello è l'identificativo univoco che il database della Regione Lombardia associa a quell'oggetto. E' veramente un'informazione utile? Non lo so. Se nelle versioni successive il database della Regione manterrà gli stessi identificativi si potrebbe pensare di usarlo per automatizzare l'importazione degli aggiornamenti. Mi sembra che siano parecchi gli import che hanno mantenuto traccia della correlazione tra elemento OSM ed elemento sorgente. Se poi questi tag siano mai stati utilizzati non lo so, forse no. Comunque se ci si pente della loro importazione si fa anche presto a cancellarli, il processo inverso non è possibile. Non è un'informazione che può andare sul changeset, perché riguarda un solo oggetto OSM. La parte _lista1-3 ha una storia a sè. Quando ho importato i confini, ho voluto, come credo logico, usare una solo way per tutto il tratto di confine che separa due comuni. Nel database della regione, in alcuni casi il confine tra due comuni è spezzato in diversi segmenti. In questi casi nell'importarlo ho unito i segmenti in un'unica way, e come valore della chiave it:lombardia:ctrn:Limite_amministrativo_09:OBJECTID ho messo tutti gli ID concatenati in una lista. In alcuni casi (per fortuna rarissimi) il confine era talmente spezzettato che la stringa degli ID superava la lunghezza in caratteri ammessa da OSM. Non ho trovato di meglio da fare che spezzare l'informazione su più tag, nel caso che hai citato ho dovuto usare 3 tag distinti per farci stare tutti gli ID. Non ho idea perché questi confini siano così spezzettati nel database della regione, penso che abbiano commesso qualche errore di elaborazione. vogliamo veramente questi tags nei dati di OSM? Non sarebbe meglio se chi importa dati da ctr si tiene un database a parte dove si memorizza quale entità osm è correllato a quale oggetto / livello della ctr? Forse si, ma la cosa si complica, io certamente non ho le capacità per realizzarlo. Poi questo database esterno andrebbe anche reso accessibile ad altri utenti che volessero consultarlo. Tieni presente che l'import dei confini della Lombardia è stato fatto da più persone che hanno operato indipendentemente. E comunque anche gli ID che OSM associa ad un oggetto possono cambiare per tanti motivi, per risalire con sicurezza a quello memorizzato nel database esterno bisognerebbe spulciarsi la history, mica agevole. Secondome il tag da usare in osm è boundary=administrative admin_level=x Si, quelli ci sono comunque. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Se proprio si vogliono togliere i tag che si riferiscono al database sorgente, o rinominarli in forma più abbreviata, si fa abbastanza presto. Ma non capisco cosa intendi per import fatto senza un minimo di elaborazione. Cosa si sarebbe dovuto fare che non si è fatto? Se per standard esistente intendi luso delle relazioni multipoligono, i confini ISTAT non li usano perché allepoca dellimportazione non esistevano. Gli import della Lombardia (e credo anche di tutte le altre regioni italiane) hanno mantenuto limpostazione originaria ISTAT, non è attuale ma almeno è uniforme in tutta Italia. Ciao, Alberto From: sabas88 [mailto:saba...@gmail.com] Sent: martedì 22 novembre 2011 10:29 To: openstreetmap list - italiano Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo? :) No, scherzi a parte, mi sembra che sia un import senza un minimo di elaborazione, come i confini istat che hanno chiavi simili a quella, bisognerebbe toglierli ed usare lo standard esistente. Ciao, Stefano _ No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1873 / Virus Database: 2101/4632 - Release Date: 11/22/11 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
-Original Message- From: Federico Cozzi [mailto:f.co...@gmail.com] Sent: martedì 22 novembre 2011 11:30 To: openstreetmap list - italiano Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga Dipende da cosa vuol dire il tag. Se è senza significato, è meglio non importarlo. Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora va importato in OSM perché è l'unico posto che può mantenere memoria della correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way, e quindi non sono una buona chiave primaria) Si, è proprio quello il motivo per cui è stato importato. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Nei confini che ho importato io ci sono solo i tag standard, questi sembrano presi dal file del ctr e piazzati là :D Il giorno 22 novembre 2011 22:01, Alberto Nogaro bartosom...@yahoo.it ha scritto: Se proprio si vogliono togliere i tag che si riferiscono al database sorgente, o rinominarli in forma più abbreviata, si fa abbastanza presto.* *** ** ** Ma non capisco cosa intendi per “import fatto senza un minimo di elaborazione”. Cosa si sarebbe dovuto fare che non si è fatto? ** ** Se per standard esistente intendi l’uso delle relazioni multipoligono, i confini ISTAT non li usano perché all’epoca dell’importazione non esistevano. Gli import della Lombardia (e credo anche di tutte le altre regioni italiane) hanno mantenuto l’impostazione originaria ISTAT, non è attuale ma almeno è uniforme in tutta Italia. ** ** Ciao, Alberto ** ** *From:* sabas88 [mailto:saba...@gmail.com] *Sent:* martedì 22 novembre 2011 10:29 *To:* openstreetmap list - ital iano *Subject:* Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga ** ** Non sono gli italiani che si divertono a giocare a chi ce l'ha più lungo? :) No, scherzi a parte, mi sembra che sia un import senza un minimo di elaborazione, come i confini istat che hanno chiavi simili a quella, bisognerebbe toglierli ed usare lo standard esistente. Ciao, Stefano -- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1873 / Virus Database: 2101/4632 - Release Date: 11/22/11* *** ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
-Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: martedì 22 novembre 2011 13:56 To: openstreetmap list - italiano Subject: Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga Nel caso dove noi non abbiamo toccato un way di solito dovrebbe aver mantenuto il suo ID osm e nel caso che noi abbiamo modificato un way vorrei mantenere il nostro way modificato, non quello del CTR aggiornato. Dipende perché lo abbiamo modificato, e perché lo ha fatto la CTR. Nel caso della Lombardia ad esempio, non si capiva dove fossero alcuni confini, perché i documenti catastali si contraddicevano. Chi ha preparato la nuova versione della CTR in questi casi ha cercato di mettere d'accordo i comuni interessati, quando ci è riuscito i comuni hanno firmato un nuovo confine concordato, quindi l'aggiornamento della CTR è coinciso con l'accordo sul nuovo andamento ufficiale dei confini. Il giochetto non è riuscito con le regioni confinanti, e con la Svizzera neppure si è tentato, e li rimane il dubbio sui reali confini. Out of curiosity: ma i CTR, vanno fatto in un modo che gli oggetti si mantegono la loro ID da una versione all'altra? Non lo so, speriamo che pubblichino finalmente le versioni aggiornate, così ci togliamo anche questo dubbio. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] la Lombardia sta messo bene nella competizione per la chiave più lunga
Il 22 novembre 2011 11:58, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2011/11/22 Federico Cozzi f.co...@gmail.com: Se invece permette di correlare gli oggetti OSM con gli oggetti CTR, allora va importato in OSM perché è l'unico posto che può mantenere memoria della correlazione (gli ID di OSM possono cambiare ad es. con split/merge di way, e quindi non sono una buona chiave primaria) non è un problema se cambia l'ID osm. Nello storico viene tutto conservato ;-) Se faccio un merge / split di una way del genere ho una seria di altri problemi (dovrei cambiare probabilmente tanti tags, vedi sotto). Secondome non ha senso replicare il database di un altro ente in OSM, come è stato fatto qui. Guardate qui: http://www.openstreetmap.org/browse/way/44356578 admin_level = 8 boundary = administrative it:lombardia:ctrn:area = 0.0 it:lombardia:ctrn:cod_asl = 4 it:lombardia:ctrn:cod_istat = 19060 it:lombardia:ctrn:cod_istatn = 03019060 it:lombardia:ctrn:cod_pro = 19 it:lombardia:ctrn:cod_reg = 03 it:lombardia:ctrn:dstrato = Comune it:lombardia:ctrn:nome_asl = CREMONA it:lombardia:ctrn:nome_com = MOSCAZZANO it:lombardia:ctrn:nome_pro = CREMONA it:lombardia:ctrn:nome_reg = LOMBARDIA it:lombardia:ctrn:perimeter = 19115.05364 it:lombardia:ctrn:sig_pro = CR it:lombardia:ctrn:strato_ctr = CO name:left = Ripalta Guerina name:right = Moscazzano __ alcuni tags hanno senso, ma un identificativo istat non è per esempio un tag specifico per la Lombardia. A cosa serve un perimetro, poi in precisione assurda ( 0.00 mm)? Cosa significa it:lombardia:ctrn:area = 0.0 ? Cosa identifica il codice ISTAT, questo way o una delle aree che delimita? Dove si trova la documentazione? Invece mancanno i dati che interessano: Da quando sono questi dati?. Come mi devo comportare se correggo un oggetto del genere? Devo modificare la lunghezza del perimetro? ciao, Martin questo edit è mio: sinceramente non ci vedo niente di male, meglio una informazione in più che una in meno. Il database di suo non si lamenta. Ruggero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
