Discussione:
[Talk-it] confini amministrativi comunali OSM - Istat
Dino Michelini
2015-12-17 18:38:45 UTC
Permalink
Salve a tutti, vorrei segnalare alla comunità che mappando il faggeto
di Allumiere (RM) mi sono accorto che i confini amministrativi comunali
tra i comuni di Allumiere e Tolfa in OSM sono differenti rispetto al
limite amministrativo prodotto da Istat nel 2011 e disponibile open data
al link http://www.istat.it/it/archivio/104317#confini [1]; ho fatto
anche una seconda verifica per il confine amministrativo tra i comuni di
Oriolo Romano, Vejano e Bassano Romano riscontrando lo stesso problema.
Fermo restando che anche i dati Istat sono affetti a loro volta da un
certo errore di precisione, rimane il fatto che sono i confini
amministrativi comunali ufficiali e legali approvati dai comuni in
occasione della revisione delle basi territoriali propedeutica al
censimento della popolazione ed edifici.

Confronto confine
amministrativo tra i comuni di Allmumiere e Tolfa (riferimento il campo
sportivo)

Confronto confine amministrativo tra i comuni di Oriolo
Romano, Vejano e Bassano Romano (riferimento angolo alto sx)
--
Dino
Michelini



Connetti gratis il mondo con la nuova indoona: hai la chat, le chiamate, le video chiamate e persino le chiamate di gruppo.
E chiami gratis anche i numeri fissi e mobili nel mondo!
Scarica subito l’app Vai su https://www.indoona.com/
Luca Delucchi
2015-12-28 08:30:40 UTC
Permalink
Ciao,
Salve a tutti, vorrei segnalare alla comunità che mappando il faggeto di Allumiere (RM) mi sono accorto che i confini amministrativi comunali tra i comuni di Allumiere e Tolfa in OSM sono differenti rispetto al limite amministrativo prodotto da Istat nel 2011 e disponibile open data al link http://www.istat.it/it/archivio/104317#confini; ho fatto anche una seconda verifica per il confine amministrativo tra i comuni di Oriolo Romano, Vejano e Bassano Romano riscontrando lo stesso problema. Fermo restando che anche i dati Istat sono affetti a loro volta da un certo errore di precisione, rimane il fatto che sono i confini amministrativi comunali ufficiali e legali approvati dai comuni in occasione della revisione delle basi territoriali propedeutica al censimento della popolazione ed edifici.
la maggior parte dei confini comunali sono stati importanti dai dati
istat anni fa, quando la qualità dei dati era ancora più bassa. Una
parte della comunità all'epoca era contraria ma "alcuni" ne avevano
assolutamente bisogno per provare a fare del routing.
Penso che sia arrivato il momento che "qualcuno" sistema il pasticcio
creato all'ora.
Dino Michelini
--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Simone Cortesi
2015-12-28 12:29:15 UTC
Permalink
Post by Luca Delucchi
la maggior parte dei confini comunali sono stati importanti dai dati
istat anni fa, quando la qualità dei dati era ancora più bassa. Una
parte della comunità all'epoca era contraria ma "alcuni" ne avevano
assolutamente bisogno per provare a fare del routing.
Penso che sia arrivato il momento che "qualcuno" sistema il pasticcio
creato all'ora.
Luca, mi sai indicare una buona fonte di confini comunali di tutta italia?

una soluzione tecnica a cui avevo pensato era quella di usare il
sistema di josm che permette di fare il "sostituisci geometria" dopo
aver evidenziato quei confini che sono molto distanti da quelli
ufficiali non semplificati.
--
-S
Maurizio Napolitano
2015-12-28 12:43:27 UTC
Permalink
Post by Simone Cortesi
Luca, mi sai indicare una buona fonte di confini comunali di tutta italia?
(anche se non sono luca)
IMHO:
la fonte più autorevole rimane ISTAT.
I dati più aggiornati sono quelli al 2014 e si trovano qui
http://www.istat.it/it/archivio/124086
Di questo è importante prendere quelli *non* generalizzati
Come proiezione partirei dal WGS84 UTM32N

Sarebbe poi oppurtuno recuperare una lista dei comuni che
si sono uniti nel 2015 e, da quelli, unire le geometrie
Rimangono aperte le questioni sulle enclave
Simone Cortesi
2015-12-28 12:52:55 UTC
Permalink
Post by Maurizio Napolitano
la fonte più autorevole rimane ISTAT.
I dati più aggiornati sono quelli al 2014 e si trovano qui
http://www.istat.it/it/archivio/124086
Di questo è importante prendere quelli *non* generalizzati
Come proiezione partirei dal WGS84 UTM32N
quelli istat, anche quelli non generalizzati non sono abbastanza
precisi se confrontati con confini forniti da altri enti "minori".

ho fatto delle prove a campione nei mesi passati.
--
-S
Maurizio Napolitano
2015-12-28 12:56:33 UTC
Permalink
Post by Simone Cortesi
quelli istat, anche quelli non generalizzati non sono abbastanza
precisi se confrontati con confini forniti da altri enti "minori".
hai un elenco in modo da contribuire ad arricchirlo?
Simone Cortesi
2015-12-28 13:00:12 UTC
Permalink
Post by Maurizio Napolitano
Post by Simone Cortesi
quelli istat, anche quelli non generalizzati non sono abbastanza
precisi se confrontati con confini forniti da altri enti "minori".
hai un elenco in modo da contribuire ad arricchirlo?
no
--
-S
Maurizio Napolitano
2015-12-28 13:03:17 UTC
Permalink
Post by Maurizio Napolitano
hai un elenco in modo da contribuire ad arricchirlo?
no
Ti facevo più ordinato :)
Luca Delucchi
2015-12-28 13:04:21 UTC
Permalink
Post by Simone Cortesi
Post by Luca Delucchi
la maggior parte dei confini comunali sono stati importanti dai dati
istat anni fa, quando la qualità dei dati era ancora più bassa. Una
parte della comunità all'epoca era contraria ma "alcuni" ne avevano
assolutamente bisogno per provare a fare del routing.
Penso che sia arrivato il momento che "qualcuno" sistema il pasticcio
creato all'ora.
Luca, mi sai indicare una buona fonte di confini comunali di tutta italia?
spulciare i vari siti di open data regionali, provinciali e
comunali... io ho fatto lo stesso per avere un DTM accurato
comunque ISTAT 2011 e spero anche 2014 è migliore di quello presente ora su OSM
Post by Simone Cortesi
una soluzione tecnica a cui avevo pensato era quella di usare il
sistema di josm che permette di fare il "sostituisci geometria" dopo
aver evidenziato quei confini che sono molto distanti da quelli
ufficiali non semplificati.
io ho provato un po' ma è veramente lungo... visto che c'è un po' di
gente che ci sballa a mappare da casa questo sarebbe un ottimo task
per loro ;-)
Post by Simone Cortesi
--
-S
--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Simone Cortesi
2015-12-28 13:06:40 UTC
Permalink
Post by Luca Delucchi
Post by Simone Cortesi
una soluzione tecnica a cui avevo pensato era quella di usare il
sistema di josm che permette di fare il "sostituisci geometria" dopo
aver evidenziato quei confini che sono molto distanti da quelli
ufficiali non semplificati.
io ho provato un po' ma è veramente lungo... visto che c'è un po' di
gente che ci sballa a mappare da casa questo sarebbe un ottimo task
per loro ;-)
infatti pensavo esattamente a questo.
--
-S
Federico Cortese
2015-12-28 13:51:58 UTC
Permalink
Qualche mese fa provai ad aggiustare i confini comunali della
Basilicata in base a quanto pubblicato sul portale regionale.
Ho fatto una prova offline ed in mezza giornata avrei potuto completare l'opera.
Il problema è che se si assimila ad un import bisogna rispettare tutte
le procedure, limitando fortemente l'operatività, altrimenti potrei
velocemente sistemare tutta la Basilicata.
Per la Puglia il discorso è un po' diverso perchè i dati della regione
sono più vecchi, quindi come geometrie sono più attendibili rispetto
agli ISTAT attualmente in OSM, ma non sono aggiornati in base alle
fusioni/cessioni avvenute negli ultimi anni.

Ciao
Federico
Martin Koppenhoefer
2015-12-28 20:11:36 UTC
Permalink
sent from a phone
Post by Federico Cortese
Il problema è che se si assimila ad un import bisogna rispettare tutte
le procedure, limitando fortemente l'operatività,
per me si potrebbe essere meno rigido in questo aspetto, nel caso che si sostituisse dati meno precisi e importati prima (e mai modificati in nessuna parte/nemmeno i nodi spostati). Licenze compatibili presupposti, ovviamente (preferibilmente senza alcun vincolo, cc0, pd, ecc.)


ciao,
Martin
Dino Michelini
2015-12-28 13:56:30 UTC
Permalink
Oltre ai confini comunali il problema riguarda anche i limiti
provinciali per due ragioni: dal 2001 al 2014 sono state create nuove
provincie mentre dal 2015 Ú iniziato il processo di riordino ed
accorpamento. Sono d'accordo che operare con josm a mano la correzione Ú
molto oneroso per cui chiedo se Ú possibile intervenire a livello di db:
infatti, nell'export gpx trovo un tag limiti comunali credo che sia
anche così per i confini provinciali. Se a livello di db fosse possibile
selezionare e cancellare le geometrie con limiti XXXXXXXXX si potrebbe
poi caricare il file istat dei confini amministrativi comunali,
provinciali e regionali aggiornati.
PS. seppure più precisi eviterei di
utilizzare dati di singole amministrazioni in quanto possono creare
problemi nella mosaicatura.

Il 28.12.2015 14:06 Simone Cortesi ha
Post by Simone Cortesi
una
soluzione tecnica a cui avevo pensato era quella di usare il sistema di
josm che permette di fare il "sostituisci geometria" dopo aver
evidenziato quei confini che sono molto distanti da quelli ufficiali non
semplificati.
Post by Simone Cortesi
io ho provato un po' ma Ú veramente lungo... visto che
c'Ú un po' di gente che ci sballa a mappare da casa questo sarebbe un
ottimo task per loro ;-)
Post by Simone Cortesi
infatti pensavo esattamente a questo.
Connetti gratis il mondo con la nuova indoona: hai la chat, le chiamate, le video chiamate e persino le chiamate di gruppo.
E chiami gratis anche i numeri fissi e mobili nel mondo!
Scarica subito l’app Vai su https://www.indoona.com/
Federico Cortese
2015-12-28 14:06:04 UTC
Permalink
Oltre ai confini comunali il problema riguarda anche i limiti provinciali
per due ragioni: dal 2001 al 2014 sono state create nuove provincie mentre
dal 2015 è iniziato il processo di riordino ed accorpamento. Sono d'accordo
che operare con josm a mano la correzione è molto oneroso per cui chiedo se
è possibile intervenire a livello di db: infatti, nell'export gpx trovo un
tag <desc>limiti comunali</desc> credo che sia anche così per i confini
provinciali. Se a livello di db fosse possibile selezionare e cancellare le
geometrie con <desc>limiti XXXXXXXXX</desc> si potrebbe poi caricare il file
istat dei confini amministrativi comunali, provinciali e regionali
aggiornati.
PS. seppure più precisi eviterei di utilizzare dati di singole
amministrazioni in quanto possono creare problemi nella mosaicatura.
Secondo me dovremmo usare i dati più corretti dal punto di vista geometrico.
La mosaicatura si risolve valutando il caso singolo, se l'operazione è
fatta a mano.
Chiaramente se è fattibile quello che suggerisci, cioè sistemare tutta
Italia direttamente nel db, allora ben venga il file ISTAT.
Poi le regioni che hanno pubblicato i confini aggiornati si possono
sistemare manualmente, come ad esempio può essere fatto per la
Basilicata.
Tutti i problemi che solleva Andrea Albani sono reali, ma possono
essere tranquillamente risolti caso per caso, spostando i confini con
il "contour merge" e adeguandoli alle geometrie corrette, mantenedo
quindi tutte le relazioni intatte. Dove i nodi sono condivisi con
altre geometrie conviene separarli manualmente.

Ciao
Federico
Simone Cortesi
2015-12-28 15:28:26 UTC
Permalink
Post by Federico Cortese
PS. seppure più precisi eviterei di utilizzare dati di singole
amministrazioni in quanto possono creare problemi nella mosaicatura.
Secondo me dovremmo usare i dati più corretti dal punto di vista geometrico.
La mosaicatura si risolve valutando il caso singolo, se l'operazione è
fatta a mano.
Chiaramente se è fattibile quello che suggerisci, cioè sistemare tutta
Italia direttamente nel db, allora ben venga il file ISTAT.
Poi le regioni che hanno pubblicato i confini aggiornati si possono
sistemare manualmente, come ad esempio può essere fatto per la
Basilicata.
Tutti i problemi che solleva Andrea Albani sono reali, ma possono
essere tranquillamente risolti caso per caso, spostando i confini con
il "contour merge" e adeguandoli alle geometrie corrette, mantenedo
quindi tutte le relazioni intatte. Dove i nodi sono condivisi con
altre geometrie conviene separarli manualmente.
mi sembrano ottime idee.
--
-S
Maurizio Napolitano
2015-12-28 17:13:16 UTC
Permalink
Post by Federico Cortese
Secondo me dovremmo usare i dati più corretti dal punto di vista geometrico.
La mosaicatura si risolve valutando il caso singolo, se l'operazione è
fatta a mano.
Chiaramente se è fattibile quello che suggerisci, cioè sistemare tutta
Italia direttamente nel db, allora ben venga il file ISTAT.
Secondo me è meglio usare i dati non generalizzati di ISTAT proprio
per prevenire problemi sui confini fra comuni diversi.
Ho guardato i confini comunali di Ravenna e di Trento e confrontato
con quelli ISTAT:
ci sono differenze (in particolare su Ravenna) ma dire quale è giusto
è un po' problematico
visto che dipende anche dal modo con cui i dati sono stati rilevati
(es. tracciamento da foto aerea ad una determinata scala).
Da un lato mi verrebbe da dire quelli del comune, se non fosse però
che la zona del porto è tagliata.
Post by Federico Cortese
Poi le regioni che hanno pubblicato i confini aggiornati si possono
sistemare manualmente, come ad esempio può essere fatto per la
Basilicata.
Concordo
Dario Zontini Gmail
2015-12-30 12:11:13 UTC
Permalink
il giorno 1/1/2016 verranno istituiti dei nuovi comuni (la maggior parte
in Trentino), qualcuno vuole unire i confini attuali il primo gennaio?
C'è modo di tenere traccia della situazione storica?

In questa pagina c'è l'elenco completo

[1]
https://it.wikipedia.org/wiki/Fusione_di_comuni_italiani#1.C2.BA_gennaio_2016

ciao
Post by Maurizio Napolitano
Post by Federico Cortese
Secondo me dovremmo usare i dati più corretti dal punto di vista geometrico.
La mosaicatura si risolve valutando il caso singolo, se l'operazione è
fatta a mano.
Chiaramente se è fattibile quello che suggerisci, cioè sistemare tutta
Italia direttamente nel db, allora ben venga il file ISTAT.
Secondo me è meglio usare i dati non generalizzati di ISTAT proprio
per prevenire problemi sui confini fra comuni diversi.
Ho guardato i confini comunali di Ravenna e di Trento e confrontato
ci sono differenze (in particolare su Ravenna) ma dire quale è giusto
è un po' problematico
visto che dipende anche dal modo con cui i dati sono stati rilevati
(es. tracciamento da foto aerea ad una determinata scala).
Da un lato mi verrebbe da dire quelli del comune, se non fosse però
che la zona del porto è tagliata.
Post by Federico Cortese
Poi le regioni che hanno pubblicato i confini aggiornati si possono
sistemare manualmente, come ad esempio può essere fatto per la
Basilicata.
Concordo
_______________________________________________
Talk-it mailing list
https://lists.openstreetmap.org/listinfo/talk-it
--
Dario Zontini


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Marcello
2015-12-29 13:25:51 UTC
Permalink
Post by Federico Cortese
Secondo me dovremmo usare i dati più corretti dal punto di vista
geometrico. La mosaicatura si risolve valutando il caso singolo, se
l'operazione è fatta a mano. Chiaramente se è fattibile quello che
suggerisci, cioè sistemare tutta Italia direttamente nel db, allora
ben venga il file ISTAT. Poi le regioni che hanno pubblicato i confini
aggiornati si possono sistemare manualmente, come ad esempio può
essere fatto per la Basilicata. Tutti i problemi che solleva Andrea
Albani sono reali, ma possono essere tranquillamente risolti caso per
caso, spostando i confini con il "contour merge" e adeguandoli alle
geometrie corrette, mantenedo quindi tutte le relazioni intatte. Dove
i nodi sono condivisi con altre geometrie conviene separarli
manualmente. Ciao Federico
Ho verificato la situazione in Umbria, per la provincia di Terni non c'è
nessuna variazione tra i confini Istat inseriti in OSM (credo del 1991)
e quelli nell'archivio Istat 2014, mentre per la provincia di Perugia
c'è sicuramente un miglioramento, quelli in OSM sono molto più
semplificati. Dato che i confini regionali corrispondono in tutto il
perimetro tranne che per qualche miglioramento con la sola provincia di
Rieti credo che il database dell'Istat sia stato aggiornato a livello
provinciale.

Per l'Umbria non ho trovato altre fonti per confrontare la bontà dei
dati Istat 2014, ma sicuramente migliorerebbero quelli inseriti in OSM
per la provincia di Perugia. Visto che non sono molti si può procedere
manualmente senza grosso sforzo, con il contour merge non dovrebbero
sorgere problemi anche nel caso di eventuale utilizzo del confine in
altre relazioni. Che ne pensate?

Ciao
Marcello
Gianmario Mengozzi
2015-12-29 13:37:53 UTC
Permalink
scusate Ú disponibile il WMS dei confini Istat 2014?
Secondo me dovremmo usare i dati più corretti dal punto di vista
geometrico. La mosaicatura si risolve valutando il caso singolo, se
l'operazione Ú fatta a mano. Chiaramente se Ú fattibile quello che
suggerisci, cioÚ sistemare tutta Italia direttamente nel db, allora
ben venga il file ISTAT. Poi le regioni che hanno pubblicato i confini
aggiornati si possono sistemare manualmente, come ad esempio può
essere fatto per la Basilicata. Tutti i problemi che solleva Andrea
Albani sono reali, ma possono essere tranquillamente risolti caso per
caso, spostando i confini con il "contour merge" e adeguandoli alle
geometrie corrette, mantenedo quindi tutte le relazioni intatte. Dove
i nodi sono condivisi con altre geometrie conviene separarli
manualmente. Ciao Federico
Ho verificato la situazione in Umbria, per la provincia di Terni non c'Ú
nessuna variazione tra i confini Istat inseriti in OSM (credo del 1991)
e quelli nell'archivio Istat 2014, mentre per la provincia di Perugia
c'Ú sicuramente un miglioramento, quelli in OSM sono molto più
semplificati. Dato che i confini regionali corrispondono in tutto il
perimetro tranne che per qualche miglioramento con la sola provincia di
Rieti credo che il database dell'Istat sia stato aggiornato a livello
provinciale.
Per l'Umbria non ho trovato altre fonti per confrontare la bontà dei
dati Istat 2014, ma sicuramente migliorerebbero quelli inseriti in OSM
per la provincia di Perugia. Visto che non sono molti si può procedere
manualmente senza grosso sforzo, con il contour merge non dovrebbero
sorgere problemi anche nel caso di eventuale utilizzo del confine in
altre relazioni. Che ne pensate?
Ciao
Marcello
_______________________________________________
Talk-it mailing list
https://lists.openstreetmap.org/listinfo/talk-it
--
- Gianmario
Damjan Gerl
2015-12-29 14:22:28 UTC
Permalink
Vorrei qui segnalare lo stato dei confini in FVG: nel 2009 sono stati
importati in osm i confini comunali dai dati messi a disposizione dalla
regione. Nello stesso anno sono stati importati i confini con la
Slovenia, dati molto più precisi che quelli regionali. In quel tempo i
confini istat erano molto grezzi, ma si sono evoluti col tempo fino alla
versione attuale (2014). Anche i dati della regione si sono evoluti,
l'ultimo aggiornamento risale al 30. novembre 2015. Più di qualche volta
si è parlato in lista regionale/nazionale che dovremmo reimportare i
dati regionali (che ora sono anche abbastanza differenti da quelli
importati nel 2009) però il lavoro è abbastanza oneroso e quindi si è
lasciato stare. Anche perché essendo abbastanza tempo in osm ci sono
abbastanza posti dove ci sono state collegate altre cose alle way dei
confini!
Forse ora si potrebbe pensare all'import nuovo dai confini comunali dai
dati regionali. Lascerei stare come stà il confine con la Slovenia che
mi sembra ancora quello più preciso, anche se i dati regionali attuali
per quella parte sono quasi identici, tranne qualche piccolo dettaglio!
I dati istat attuali sono una versione dei confini che non combacia ne
con i dati regionali del 2009 ne con quelli attuali. Forse combaciano
con qualche versione intermedia, ma non sono andato a verificare.
Analizzando i dati regionali attuali però mi sembra che ci siano troppi
vertici. Sembrerebbe una digitalizzazione da qualche altro formato. Qui
da noi i cippi dei confini ci sono solo sul confine di stato, ma non tra
quelli comunali. Comunque tutti quei vertici tra comuni mi sembrano
irreali che ci possano essere nella realtà. Comunque restano i dati
migliori.

Ciao
Damjan
Federico Cortese
2015-12-29 13:48:08 UTC
Permalink
Questo messaggio potrebbe essere inappropriato. Clicca per visualizzarlo
Francesco Pelullo
2015-12-29 14:00:21 UTC
Permalink
Post by Federico Cortese
Si ho proposto il contour merge proprio per questo motivo. Non ci sono
problemi con le relazioni, ma bisogna fare attenzione ai nodi
condivisi con altri oggetti, che andrebbero separati manualmente (a
meno che non ci siano altre soluzioni che mi sfuggono).
Se si decidesse di separare gli oggetti manualmente, dovremmo cercare (se
esiste) un modo per fare sì che questa fosse l'ultima volta che si rende
necessaria questa separazione.

Esempio: i confini non cambiano spesso, si possono importare i confini
amministrativi "esatti" in un database a parte? Del tipo che sono
liberamente scaricabili, ma editabili solo previa procedura apposita.

Ciao
/niubii/
Stefano
2015-12-29 14:07:36 UTC
Permalink
Ciao,
io uso replace geometry. Tiene traccia della storia, non ha problmi con la
separazione degli oggetti, l'unica condizione Ú che sia scaricata tutta
l'area intorno al segmento che si va a sostituire e che non si effettuino
sostituzioni di più di 6-700 nodi (questo perché altrimenti si impalla).
Post by Francesco Pelullo
Post by Federico Cortese
Si ho proposto il contour merge proprio per questo motivo. Non ci sono
problemi con le relazioni, ma bisogna fare attenzione ai nodi
condivisi con altri oggetti, che andrebbero separati manualmente (a
meno che non ci siano altre soluzioni che mi sfuggono).
Se si decidesse di separare gli oggetti manualmente, dovremmo cercare (se
esiste) un modo per fare sì che questa fosse l'ultima volta che si rende
necessaria questa separazione.
Esempio: i confini non cambiano spesso, si possono importare i confini
amministrativi "esatti" in un database a parte? Del tipo che sono
liberamente scaricabili, ma editabili solo previa procedura apposita.
Ciao
/niubii/
_______________________________________________
Talk-it mailing list
https://lists.openstreetmap.org/listinfo/talk-it
Martin Koppenhoefer
2015-12-30 07:59:54 UTC
Permalink
sent from a phone
Tiene traccia della storia, non ha problmi con la separazione degli oggetti,
riguardando la separazione e fusione dei oggetti: talvolta un confine è costituito da un fiume o una strada o simile, e in quel caso la topologia corretta per mapparlo in osm sarebbe di avere quel oggetto nella relazione, non solo una copia.

ciao,
Martin
Federico Cortese
2015-12-30 08:44:30 UTC
Permalink
Post by Martin Koppenhoefer
Tiene traccia della storia, non ha problmi con la separazione degli oggetti,
riguardando la separazione e fusione dei oggetti: talvolta un confine è costituito da un fiume o una strada o simile, e in quel caso la topologia corretta per mapparlo in osm sarebbe di avere quel oggetto nella relazione, non solo una copia.
Il confine amministrativo è una cosa, il fiume o la strada un'altra,
io sarei per tenere le due cose separate, anche dove il confine segue
l'andamento di altri elementi.

Ciao
Federico
Martin Koppenhoefer
2015-12-30 11:26:38 UTC
Permalink
Il confine amministrativo Ú una cosa, il fiume o la strada un'altra,
non sempre, al meno al livello globale un fiume o una strada possono essere
la definizione di un confine, e quando si sposta il fiume si sposta anche
il confine. Similmente le coste.
Non conosco la realtà italiana al livello di definizioni di confini, e di
relativa giurisdizione.

Ciao,
Martin
Luca Delucchi
2015-12-29 14:59:51 UTC
Permalink
Post by Federico Cortese
Potremmo decidere quindi o di intervenire a livello nazionale con
ISTAT 2014 e poi migliorare a livello locale, oppure ragionare
direttamente per regioni, andando ad importare ISTAT 2014 solo dove
non c'è cartografia regionale libera.
direi che la seconda opzione è migliore, la prima costringerebbe un
doppio lavoro
Post by Federico Cortese
Ciao
Federico
--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Any File
2015-12-29 21:09:41 UTC
Permalink
Post by Marcello
Ho verificato la situazione in Umbria, per la provincia di Terni non c'è
Una volta che si è scaricato il (grande) file dal sito dell'Istat e
compresso il file, c'è un modo per ritagliare solo i dati relativi ad
una parte d'Italia?

AnyFile
Maurizio Napolitano
2015-12-29 23:40:34 UTC
Permalink
Post by Any File
Post by Marcello
Ho verificato la situazione in Umbria, per la provincia di Terni non c'è
Una volta che si è scaricato il (grande) file dal sito dell'Istat e
compresso il file, c'è un modo per ritagliare solo i dati relativi ad
una parte d'Italia?
da qgis
carichi il file .shp
premi il bottone destro sul nome del layer caricato e scegli "filter"
e da lì imposti su quale valore vuoi impostare il fitlro (es
COD_PRO=22 se vuoi avere i dati dei comuni in Provincia di Trento

da command line
ogr2ogr -F "ESRI Shapefile" -where COD_PRO=22 trentino.shp Com2014_WGS84.shp
Marcello
2015-12-30 13:10:26 UTC
Permalink
Post by Maurizio Napolitano
Post by Any File
Post by Marcello
Ho verificato la situazione in Umbria, per la provincia di Terni non c'è
Una volta che si è scaricato il (grande) file dal sito dell'Istat e
compresso il file, c'è un modo per ritagliare solo i dati relativi ad
una parte d'Italia?
da qgis
carichi il file .shp
premi il bottone destro sul nome del layer caricato e scegli "filter"
e da lì imposti su quale valore vuoi impostare il fitlro (es
COD_PRO" se vuoi avere i dati dei comuni in Provincia di Trento
da command line
ogr2ogr -F "ESRI Shapefile" -where COD_PRO" trentino.shp Com2014_WGS84.shp
Io ho fatto più o meno la stessa cosa con Josm, ho caricato il file .shp
e fatto una ricerca sulla chiave COD_REG=10, così mi ha selezionato solo
l'Umbria, ho copiato gli oggetti selezionati in un nuovo livello e
salvato come file .osm. Sul nuovo livello si possono aggiungere tutti
gli oggetti che interessano, facendo ricerche multiple o componendo la
ricerca in modo adeguato, quindi è semplice crearsi un'estrazione
personalizzata dal file Istat.

Ciao
Marcello
Gianmario Mengozzi
2016-01-06 12:47:50 UTC
Permalink
Il comune di Cesena mette da un pò di tempo (
http://dati.unionevallesavio.it/) a disposizione alcuni dati cartografici
del territorio con licenza CC0 BY.

I dati di confine comunali sono più dettagliati rispetto all'estratto
istat2011 importati in osm ma mi paiono comunque coincidere con i dati
aggiornati istat2014. Provo a fare un'operazione di allineamento manuale.

I confini dei quartieri sono admin_level 9 o 10?

-- sent by Nexus 5
Post by Maurizio Napolitano
Post by Maurizio Napolitano
Post by Marcello
Ho verificato la situazione in Umbria, per la provincia di Terni non
c'Ú
Post by Maurizio Napolitano
Una volta che si Ú scaricato il (grande) file dal sito dell'Istat e
compresso il file, c'Ú un modo per ritagliare solo i dati relativi ad
una parte d'Italia?
da qgis
carichi il file .shp
premi il bottone destro sul nome del layer caricato e scegli "filter"
e da lì imposti su quale valore vuoi impostare il fitlro (es
COD_PRO" se vuoi avere i dati dei comuni in Provincia di Trento
da command line
ogr2ogr -F "ESRI Shapefile" -where COD_PRO" trentino.shp
Com2014_WGS84.shp
Io ho fatto più o meno la stessa cosa con Josm, ho caricato il file .shp
e fatto una ricerca sulla chiave COD_REG=10, così mi ha selezionato solo
l'Umbria, ho copiato gli oggetti selezionati in un nuovo livello e
salvato come file .osm. Sul nuovo livello si possono aggiungere tutti
gli oggetti che interessano, facendo ricerche multiple o componendo la
ricerca in modo adeguato, quindi Ú semplice crearsi un'estrazione
personalizzata dal file Istat.
Ciao
Marcello
_______________________________________________
Talk-it mailing list
https://lists.openstreetmap.org/listinfo/talk-it
Martin Koppenhoefer
2015-12-28 20:14:57 UTC
Permalink
sent from a phone
PS. seppure più precisi eviterei di utilizzare dati di singole amministrazioni in quanto possono creare problemi nella mosaicatura.
sarei invece per prendere i dati più precisi e per risolvere i problemi, casomai si dovessero porre...

ciao,
Martin
Any File
2015-12-28 21:54:09 UTC
Permalink
Post by Martin Koppenhoefer
PS. seppure più precisi eviterei di utilizzare dati di singole amministrazioni in quanto possono creare problemi nella mosaicatura.
sarei invece per prendere i dati più precisi e per risolvere i problemi, casomai si dovessero porre...
Ma il problema è se due comuni confinanti segnano sui loro siti due
confini diversi. Se invece usi una sola fonte, questo problema non
dovrebbe porsi.

Per quanto riguarda la domanda di Andrea Albani circa il replace
geometry di Josm e le relazioni, da quel che mi ricordo dovrebbe
funzionare (questo comando non fa altro che modificare la way, è
quindi come inserire un novo nodo in una way, salvo che in questo caso
potrebbero non esserci nodi in comune tra la way vecchia e quella
nuova. Questo comando conserva il numero della way, che è proprio
quello che serve per non aver bisogno di andare a cambiare la
relazione).

AnyFile
Martin Koppenhoefer
2015-12-28 22:01:27 UTC
Permalink
sent from a phone
Post by Any File
Ma il problema è se due comuni confinanti segnano sui loro siti due
confini diversi.
succede anche al livello di stati (dove non c'è altra soluzione seria che mettere entrambe le versioni), ma tra comuni ci sarà un' autorità per decidere chi ha "ragione"? Parliamo di casi aperti (non è chiaro dove si trova il confine/i comuni reclamano entrambi uno stesso pezzo di terra), oppure di problemi di generalizzazione/scala/semplificazione differenti, ma della stessa versione comunemente accettata?

ciao,
Martin
Francesco Pelullo
2015-12-29 06:36:46 UTC
Permalink
succede anche al livello di stati (dove non c'Ú altra soluzione seria che
mettere entrambe le versioni), ma tra comuni ci sarà un' autorità per
decidere chi ha "ragione"?

Per stabilire chi ha ragione in questi casi si fa riferimento ai cippi di
pietra (termini lapidei) fisicamente presenti sul confine e che lo
individuano univocamente.

Il confine comunale segue il limite delle particelle catastali (in realtà
sarebbe il contrario: le particelle catastali sono suddivise _anche_ in
base al confine comunale).

La migliore fonte per importare i confini dovrebbe essere la CTR al 5000 o
al 2000, sulla quale sono segnati persino i cippi di confine.

Non saprei però quanto corrispondano i bordi di due CTR adiacenti. IMHO i
dati ISTAT sono derivati dalle CTR o dai fogli di mappa catastali con tutti
i problemi che questo comporta.

Ciao
/niubii/
Martin Koppenhoefer
2015-12-29 09:12:14 UTC
Permalink
sent from a phone
Per stabilire chi ha ragione in questi casi si fa riferimento ai cippi di pietra (termini lapidei) fisicamente presenti sul confine e che lo individuano univocamente.
una buona notizia, perché questi li possiamo rilevare anche noi (nel dubbio, in pratica il lavoro Ú comunque enorme)

ciao,
Martin


ps: se qualcuno li spostasse (reato, lo so), credo che quando se ne accorge qualcuno sarebbero rispostati. Sicuro che ancora ad oggi non c'Ú una versione digitale ufficiale unificata dei confini?


ciao,
Martin
Maurizio Napolitano
2015-12-29 10:26:16 UTC
Permalink
Post by Martin Koppenhoefer
ps: se qualcuno li spostasse (reato, lo so),
... ogni tanto ci pensa anche la natura a spostarli
Post by Martin Koppenhoefer
credo che quando se ne accorge
qualcuno sarebbero rispostati. Sicuro che ancora ad oggi non c'è una
versione digitale ufficiale unificata dei confini?
rimango dell'idea che l'unica versione digitale unificata aperta sia
quella di ISTAT.
Simone Cortesi
2015-12-29 10:32:57 UTC
Permalink
Post by Maurizio Napolitano
Post by Martin Koppenhoefer
credo che quando se ne accorge
qualcuno sarebbero rispostati. Sicuro che ancora ad oggi non c'è una
versione digitale ufficiale unificata dei confini?
rimango dell'idea che l'unica versione digitale unificata aperta sia
quella di ISTAT.
in Italia esistono circa 1000 dispute territoriali fra Comuni confinanti.

Quella attuale di ISTAT è comunque una approssimazione che di fatto
prende, per ogni singolo caso, arbitrariamente una delle due parti.

Da questo discende che non avremo mai il catasto online e tutto il resto...

CMQ sono d'accordo con Maurizio.
--
-S
Stefano
2015-12-29 10:35:54 UTC
Permalink
Post by Maurizio Napolitano
Post by Martin Koppenhoefer
ps: se qualcuno li spostasse (reato, lo so),
... ogni tanto ci pensa anche la natura a spostarli
Post by Martin Koppenhoefer
credo che quando se ne accorge
qualcuno sarebbero rispostati. Sicuro che ancora ad oggi non c'Ú una
versione digitale ufficiale unificata dei confini?
rimango dell'idea che l'unica versione digitale unificata aperta sia
quella di ISTAT.
Ci sarebbero anche gli strati prioritari del CISIS, che sarebbero frutto
dell'unificazione dei dbt regionali...
http://www.centrointerregionale-gis.it/DBPrior/DBPrior.asp
Però mi sa che non ne Ú uscito niente di dettagliato..

Stefano
Post by Maurizio Napolitano
_______________________________________________
Talk-it mailing list
https://lists.openstreetmap.org/listinfo/talk-it
Maurizio Napolitano
2015-12-29 10:45:40 UTC
Permalink
Post by Stefano
Ci sarebbero anche gli strati prioritari del CISIS, che sarebbero frutto
dell'unificazione dei dbt regionali...
http://www.centrointerregionale-gis.it/DBPrior/DBPrior.asp
Però mi sa che non ne è uscito niente di dettagliato..
è disegnato da rilievo a 10.000 metri.
Il progetto è interessante, peccato però sia fermo al 2011 :(
Andrea Albani
2015-12-28 13:47:45 UTC
Permalink
Post by Simone Cortesi
una soluzione tecnica a cui avevo pensato era quella di usare il
sistema di josm che permette di fare il "sostituisci geometria" dopo
aver evidenziato quei confini che sono molto distanti da quelli
ufficiali non semplificati.
In questo caso dobbiamo preoccuparci di tutti quei nodi delle way boundary
che nel frattempo sono diventati parte di altre way di differente
tipologia. Citando casi concreti:
- parti del boundary che diventano highway o porzioni di landuse: da un
rapido check vedo che Josm cambia la geometria solo alla way selezionata e
lascia (duplica) i nodi facendi parti di altre way
- boundary spezzato secondo le esigenze e inserito un una relazione di tipo
landuse: non sono in grado di verificare che succede, ma ad occhio il
risultato non deve essere simpatico.

Un paio di altri dubbi:
- come sappiamo i boundary attuali non sono way uniche, ma tante way
contigue: nell'ipotesi che i problemi di cui sopra siano risolti allora
replace geometry funziona solo se i nuovi boundary sono spezzati +/- allo
stesso modo. Ma se i confini sono cambiati ? ovvero se una way Ú stata
spezzata perchÚ ad esempio su un lato del confine ora ci sono due comuni
confinanti invece che uno ?
- replace geometry gestisce le relazioni, oppure Ú necessario riassociare
alla relazione boundary le way sostituite a mano ?

Ciao
Dino Michelini
2015-12-29 14:55:04 UTC
Permalink
Sulla questione mi porrei alcune domande:

* servono i limiti
amministrativi in OSM?
* quali sono le fonti di produzione dei dati
ufficiali?
* quale grado di precisione e accuratezza devono avere i
limiti amministrativi?
* Ú necessario definire un nuovo standard sulla
geometrie e topologia o Ú meglio utilizzare cose già esistenti?
* come
possono essere costantemente aggiornati e da chi?

Quesito 1.
Considerato l'interessante lavoro fatto sulle statistiche di OSN direi
che avere geometrie e topologie che definiscano i limiti amministrativi
può essere molto utili

Quesito 2. Ad oggi i produttori ufficiali di
cartografia sono IGM, Agenzia delle Entrare (ex Agenzia del Territorio),
ISPRA, Regioni, Istat. Ad oggi tra questi produttori solo Istat dispone
di dati amministrativi di Comuni, Provincie e Regioni, open,
sufficientemente aggiornati, codificati e standardizzati

Quesito 3.
Dal 2010 Istat aggiorna ogni anno i limiti amministrativi (anche quelli
con zone in contestazione di cui evidenzia l'area e non decide
arbitrariamente il limiti) di tutti i Comuni, Provincie e Regioni.
L'aggiornamento viene fatto con base ortofoto AGEA a colori del 2012 con
una risoluzione a terra di un metro e viene validato dalle singole
amministrazione interessate mediante il portale
http://basiterritoriali.istat.it/ [1]. Inoltre con Agenzia delle Entrate
dispone archiviazione dei numeri civici e stradario di tutta l'Italia.
Le altre fonti di produzione cartografica purtroppo non sono sempre
aggiornate, hanno come dettaglio al max la scala di 1:5000 delle CTR e
poche sono quelle disponibili in formato vector.

Quesito 4.
Considerando che OSM Ú una comunità open dove Ú difficile gestire e
mantenere standard.

Quesito 5. Se avete la pazienza di leggere la
pagina al seguente link
http://www.istat.it/strumenti/definizioni/comuni/ [2] comprenderete di
quanto lavoro in realtà stiamo parlando. Quindi, sarebbe auspicatile
utilizzare dati che coprano il 100% della superficie italiana e che
possano in caso di aggiornamento essere facilmente elaborati tramite
procedure a livello di db senza dover ricorrere ai mappatori che posso
non comprendere il significato di in limite amministrativo. Adottare per
il riporto cartografico dei limiti amministrativi lo stesso metodo usato
per il mapping locale dove varie tipologie di mappatori ciascuna con un
background culturare e professionale diverso rappresenta un rischio che
eviterei di correre: ad es. se mi confondi dalle ortofoto un nocchieto
od uliveto con una faggeta o castagneto la cosa Ú grave ma Ú puntuale e
si può risolvere con un tag e qualche punto, viceversa con i limiti
amministrativi potresti avere tra qualche anno nuovamente la necessità
di rimettere mano pesantemente alla cartografia presentandoti non un
mosaico uniforme e standardizzato ma un puzzle confuso di aree da
sistemare. COMUNI E PROVINCIE

ANNO
COMUNI
PROVINCIE
CITTÀ
METROPOLITANE

1991
8100
95

2001
8101
103

2011

8092
110

2015
8046
75?
10

CITTÀ METROPOLITANE


Città Metropolitana
Superficie
km² Numero Comuni


Denominazione

1.
BARI
3.863
41

2.
BOLOGNA

3.702
56

3.
FIRENZE
3.514
42

4.
GENOVA

1.834
67

5.
MILANO
1.576
134

6.
NAPOLI

1.179
92

7.
REGGIO CALABRIA
3.210
97

8.
ROMA
CAPITALE
5.363
121

9.
TORINO
6.827
315

10.

VENEZIA
2.473
44

Città Metropolitane
33.541
1.009


% su Italia
11,10%
12,50%

Italia
302.073
8.057

Il
2015-12-29 11:26
Post by Martin Koppenhoefer
credo che quando se ne
accorge
Post by Martin Koppenhoefer
qualcuno sarebbero rispostati. Sicuro che ancora ad oggi non
c'Ú una
Post by Martin Koppenhoefer
versione digitale ufficiale unificata dei confini?
rimango dell'idea che l'unica versione digitale unificata aperta sia
quella di ISTAT.
in Italia esistono circa 1000 dispute territoriali
fra Comuni confinanti.
Quella attuale di ISTAT Ú comunque una
approssimazione che di fatto
prende, per ogni singolo caso,
arbitrariamente una delle due parti.
Da questo discende che non
avremo mai il catasto online e tutto il resto...
CMQ sono d'accordo
con Maurizio.




Connetti gratis il mondo con la nuova indoona: hai la chat, le chiamate, le video chiamate e persino le chiamate di gruppo.
E chiami gratis anche i numeri fissi e mobili nel mondo!
Scarica subito l’app Vai su https://www.indoona.com/
Loading...