Import civici Milano - regole di traduzione

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Import civici Milano - regole di traduzione

Andrea Musuruane
Ciao,
    oggi vediamo come tradurre i dati dei civici dal formato originario a quello OSM.

Caricate i dati in QGIS per mezzo della funzione "Layer -> Aggiungi layer -> Aggiungi layer testo delimitato". Come "Campo X" e "Campo Y" scegliete rispettivamente WGS84_X e WGS84_Y. Come proiezione "WGS 84 / UTM zone 32N (EPGS:32632)".

Salvate quindi il layer così ottenuto in uno shapefile (io ho usato per comodità lo stesso nome del file CSV ovvero Civici_20180718) avendo cura di usare la stessa proiezione.

Per convertire i dati dal formato shapefile al formato OSM, usiamo ogr2osm con la seguente regola di traduzione.

La traduzione funziona secondo le seguenti regole:

  • loc_ref contiene IDMASTER. Questo è l'ID ufficiale del civico e sarà usato per fare la conflation in import futuri. Il tag loc_ref è già usato a Milano sulle highway per indicare il codice arco AMAT.
  • addr:housenumber contiente NUMEROCOMPLETO convertito in minuscolo (per l'esponente).
  • addr:street contiene il toponimo OSM della strada identificata da CODICE_VIA nello stradario generato precedentemente. Se CODICE_VIA non ha una corrispondenza, viene aggiungo un tag fixme.
  • addr:city contiene Milano. I confini amministrativi ISTAT sono spesso imprecisi ed è meglio sempre specificare la città per evitare casi dubbi.
Inoltre, vengono scartati anche tutti i civici soppressi.

Per avere una migliore qualità dei dati e per ridurre il processo di QA successivo all'import, bisogna correggere i problemi identificati nei dati OSM descritti nella mail "Import civici Milano - primi passi".

Il file OSM risultante è disponibile qui:

Con questo si può iniziare iniziare ad analizzare la qualità dei dati con JOSM, mettendo come sfondo una mappa (OSM Carto o altro). Mi raccomando di NON fare l'upload di questi dati.

Ricordo che c'è necessità di mapper milanesi (sia residenti che pendolari) per poter fare questo import. Iniziate a segnarvi sulla wiki:

La prossima volta vedremo come fare la conflation.

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

cascafico
Andrea Musuruane wrote
>    - *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in minuscolo
>    (per l'esponente).

Sto facendi delle prove per impostare una conflation collaborativa via
browser. Come è stato deciso di comporre l'indirizzo? Per esempio:

NUMERO+lowercase(LETTERA)+"/"+BARRA
NUMERO+uppercase(LETTERA)+"/"+BARRA
NUMERO+" "+uppercase(LETTERA)+"/"+BARRA
...

Avrebbe senso usare un ref che indichi il dataset sorgente? Per esempio
ref:MI_ds634





-----

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it

--
cascafico.altervista.org
twitter.com/cascafico
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist
In reply to this post by Andrea Musuruane
Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane <[hidden email]>:
Ciao,
    oggi vediamo come tradurre i dati dei civici dal formato originario a quello OSM.

Caricate i dati in QGIS per mezzo della funzione "Layer -> Aggiungi layer -> Aggiungi layer testo delimitato". Come "Campo X" e "Campo Y" scegliete rispettivamente WGS84_X e WGS84_Y. Come proiezione "WGS 84 / UTM zone 32N (EPGS:32632)".

Salvate quindi il layer così ottenuto in uno shapefile (io ho usato per comodità lo stesso nome del file CSV ovvero Civici_20180718) avendo cura di usare la stessa proiezione.

Per convertire i dati dal formato shapefile al formato OSM, usiamo ogr2osm con la seguente regola di traduzione.

La traduzione funziona secondo le seguenti regole:

  • loc_ref contiene IDMASTER. Questo è l'ID ufficiale del civico e sarà usato per fare la conflation in import futuri. Il tag loc_ref è già usato a Milano sulle highway per indicare il codice arco AMAT.

per me è inutile. L'indirizzo dovrebbe essere sufficiente per future verifiche per capire di quale oggetto si parla. In più avremmo la lista di tutti gli oggetti caricati con questo import (dalla lista dei changesets del caricamento nella documentazione del import nel wiki), quindi si potrà vedere cosa è successo con gli oggetti caricati, senza dover ricorrere a degli ID esterni.
 

  • addr:housenumber contiente NUMEROCOMPLETO convertito in minuscolo (per l'esponente).
  • addr:street contiene il toponimo OSM della strada identificata da CODICE_VIA nello stradario generato precedentemente. Se CODICE_VIA non ha una corrispondenza, viene aggiungo un tag fixme.
  • addr:city contiene Milano. I confini amministrativi ISTAT sono spesso imprecisi ed è meglio sempre specificare la città per evitare casi dubbi.
Inoltre, vengono scartati anche tutti i civici soppressi.


soppressi significa che non ci sono più i cartelli in loco?
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Dal dato si capisce a cosa si riferisce il civico (ingresso ad un fabbricato, cancello nel perimetro, ecc.)?

Ciao,
Martin

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Alessandro Palmas
Il 31/10/18 11:29, Martin Koppenhoefer ha scritto:
> Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane
> <[hidden email] <mailto:[hidden email]>>:
>
.......

>
>     La traduzione funziona secondo le seguenti regole:
>
>       * *loc_ref* contiene *IDMASTER*. Questo è l'ID ufficiale del
>         civico e sarà usato per fare la conflation in import futuri. Il
>         tag loc_ref è già usato a Milano sulle highway per indicare il
>         codice arco AMAT.
>
>
> per me è inutile. L'indirizzo dovrebbe essere sufficiente per future
> verifiche per capire di quale oggetto si parla. In più avremmo la lista
> di tutti gli oggetti caricati con questo import (dalla lista dei
> changesets del caricamento nella documentazione del import nel wiki),
> quindi si potrà vedere cosa è successo con gli oggetti caricati, senza
> dover ricorrere a degli ID esterni.


Non commettiamo l'errore già fatto in precedenza.
Tenere un campo ref del database di origine in caso di future probabili
rielaborazioni/aggiornamenti ecc.. eviterebbe un pesante lavoro di
ricostruzione del passato.
Già con la conflation molti civici non saranno inseriti; quando tra
qualche anno quei dati verranno ripresi nel frattempo chissà quante
volte saranno stati spostati, magari cancellati e ripristinati.
Sì, tecnicamente nel db OSM si ritrova tutto, ma se abbiamo un campo che
ci facilità l'interoperabilità con un db esterno trovo masochista il
volerlo togliere.
Quale sarebbe il vantaggio, avere un estratto dell'Italia di qualche
kilobyte più leggero?

Vogliamo fare i puri ad ogni costo? Però ai vicini francesi nessuno ha
fatto cancellare *ad ogni geometria importata* dal catasto il tag
source="cadastre-dgi-fr source : Direction Générale des Impôts -
Cadastre. Mise à jour : 2011"


Alessandro

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist
Am Mi., 31. Okt. 2018 um 12:23 Uhr schrieb Alessandro Palmas <[hidden email]>:
Non commettiamo l'errore già fatto in precedenza.
Tenere un campo ref del database di origine in caso di future probabili
rielaborazioni/aggiornamenti ecc.. eviterebbe un pesante lavoro di
ricostruzione del passato.


solo se ti fidi cecamente del "aggiornamento"
Quanto sia pesante il lavoro di ricostruzione del passato dipende in primis quanto è stato organizzato e documentato bene l'import. Con la lista dei changesets completa è un gioco di ragazzi risalire a tutti gli oggetti. In più, con gli indirizzi la situazione è diversa che per tante altre cose, perché il civico già dice molto bene dove si trova (nel insieme di tutti gli altri civici), e dovrebbe essere univoco (al livello di dati pubblici sui civici, in OSM naturalmente lo stesso indirizzo (di un POI, di qualcosa) può occorere infinite volte).

 
Già con la conflation molti civici non saranno inseriti; quando tra
qualche anno quei dati verranno ripresi nel frattempo chissà quante
volte saranno stati spostati, magari cancellati e ripristinati.


certamente. E cosa faremmo quindi? Buttiamo via tutti questi spostamenti, cancellazioni e ripristinazioni? Probabilmente no, quindi l'ipotetico confronto con un aggiornamento del dataset esterno sarà molto oneroso con ID e senza ID. Per identificare un civico non serve un ID. Il civico stesso è un ID.

 

Vogliamo fare i puri ad ogni costo? Però ai vicini francesi nessuno ha
fatto cancellare *ad ogni geometria importata* dal catasto il tag
source="cadastre-dgi-fr source : Direction Générale des Impôts -
Cadastre. Mise à jour : 2011"


credo nessuno abbia fatto gli applausi a questa scemenza. Di lamentele su questo ne abbiamo sentite tante invece.

Ciao,
Martin


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by cascafico
Ciao Giovanni,
    grazie per aver ripreso questo thread.

Visto il poco interesse da parte di mapper milanesi, l'attività si è un po' arenata. Maurizio, coordinatore OSM per la Lombardia, sta cercando partecipanti.


On Wed, Oct 31, 2018 at 11:18 AM cascafico <[hidden email]> wrote:
Andrea Musuruane wrote
>    - *addr:housenumber* contiente *NUMEROCOMPLETO* convertito in minuscolo
>    (per l'esponente).

Sto facendi delle prove per impostare una conflation collaborativa via
browser. Come è stato deciso di comporre l'indirizzo? Per esempio:

NUMERO+lowercase(LETTERA)+"/"+BARRA
NUMERO+uppercase(LETTERA)+"/"+BARRA
NUMERO+" "+uppercase(LETTERA)+"/"+BARRA
...


Il campo addr:housenumber conterrà il valore di NUMEROCOMP, con le eventuali lettere convertite in minuscolo.

NUMEROCOMP, seguendo quanto descritot nel file Istruzioni tecniche per l'utilizzo dei dati_CIVICI.pdf è: NUMERO+LETTERA+BARRA

Lo slash non viene usato se non per separare gli esponenti numerici.

 
Avrebbe senso usare un ref che indichi il dataset sorgente? Per esempio
ref:MI_ds634


L'uso di loc_ref mi sembra coerente con quello che già avviene per le strade. Non mi sembra il caso di usare altri tag.

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by dieterdreist
Ciao Martin,

On Wed, Oct 31, 2018 at 11:31 AM Martin Koppenhoefer <[hidden email]> wrote:
Am Fr., 31. Aug. 2018 um 12:16 Uhr schrieb Andrea Musuruane <[hidden email]>:

La traduzione funziona secondo le seguenti regole:

  • loc_ref contiene IDMASTER. Questo è l'ID ufficiale del civico e sarà usato per fare la conflation in import futuri. Il tag loc_ref è già usato a Milano sulle highway per indicare il codice arco AMAT.

per me è inutile. L'indirizzo dovrebbe essere sufficiente per future verifiche per capire di quale oggetto si parla. In più avremmo la lista di tutti gli oggetti caricati con questo import (dalla lista dei changesets del caricamento nella documentazione del import nel wiki), quindi si potrà vedere cosa è successo con gli oggetti caricati, senza dover ricorrere a degli ID esterni.

Il tempo dedicato alla conflation è molto elevato: amalgamare due data set differenti non è semplice anche avendo a disposizione degli ottimi tool a supporto. L'indirizzo infatti non è sufficiente a riconciliare due civici (spesso la strada è scritta in OSM e nel dataset di origine in modo differente, a volte anche il civico è scritto in modo differente, ecc).

Il campo loc_ref non è un semplice ID esterno, ma è l'ID ufficiale del civico generato dal Comune di Milano. Senza il Comune di Milano quel dato non esiste. Ed è lo stesso ente che decide quando decade.

Dato che il Comune di Milano aggiorna regolarmente il dataset dei civici, avere a disposizione l'ID ufficiale del civico, permetterà import futuri più veloci e precisi perché semplificherà notevolmente la fase di conflation.

  • addr:housenumber contiente NUMEROCOMPLETO convertito in minuscolo (per l'esponente).
  • addr:street contiene il toponimo OSM della strada identificata da CODICE_VIA nello stradario generato precedentemente. Se CODICE_VIA non ha una corrispondenza, viene aggiungo un tag fixme.
  • addr:city contiene Milano. I confini amministrativi ISTAT sono spesso imprecisi ed è meglio sempre specificare la città per evitare casi dubbi.
Inoltre, vengono scartati anche tutti i civici soppressi.


soppressi significa che non ci sono più i cartelli in loco?

Sì.
 
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.
 
Dal dato si capisce a cosa si riferisce il civico (ingresso ad un fabbricato, cancello nel perimetro, ecc.)?

C'è l'indicazione del fatto che sia anche un passo carraio.

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist


sent from a phone

> On 31. Oct 2018, at 15:49, Andrea Musuruane <[hidden email]> wrote:
>
> Dato che il Comune di Milano aggiorna regolarmente il dataset dei civici, avere a disposizione l'ID ufficiale del civico, permetterà import futuri più veloci e precisi perché semplificherà notevolmente la fase di conflation.


io rimango dell’idea che non dovremmo fare aggiornamenti automatici, al meno non per quelli civici che sono già in osm (anche dall’import precedente). Visto che ora li controllate tutti, ogni modifica in futuro dovrebbe essere verificata individualmente. Altrimenti osm sarebbe usato come repository di dati ufficiali, non toccabili oppure toccabili ma senza senso, sapendo che il prossimo import sovrascriverà il lavoro fatto.

Con o senza id del comune devi vedere se un determinato civico già esiste nei dati di osm (perché i civici rilevati “a mano” non avranno id), anche per futuri import.

Ciao, Martin
_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist
In reply to this post by Andrea Musuruane


sent from a phone

On 31. Oct 2018, at 15:49, Andrea Musuruane <[hidden email]> wrote:

soppressi significa che non ci sono più i cartelli in loco?

Sì.


capisco, aveva tutt’altra idea e pensavo fossero civici di cui il comune aveva deciso che non erano più validi...


 
Dal dato si capisce a cosa si riferisce il civico (ingresso ad un fabbricato, cancello nel perimetro, ecc.)?

C'è l'indicazione del fatto che sia anche un passo carraio.


però non distingue tra passi carrai all’interno di fabbricati e quelli all’aperto?
Insomma, la distinzione tra entrance=yes/no e barrier=gate non è estraibile?


Ciao, Martin 

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Damjan Gerli
In reply to this post by dieterdreist
01.11.2018 - 17:22 - Martin Koppenhoefer:
io rimango dell’idea che non dovremmo fare aggiornamenti automatici, al meno non per quelli civici che sono già in osm (anche dall’import precedente). Visto che ora li controllate tutti, ogni modifica in futuro dovrebbe essere verificata individualmente. Altrimenti osm sarebbe usato come repository di dati ufficiali, non toccabili oppure toccabili ma senza senso, sapendo che il prossimo import sovrascriverà il lavoro fatto.
Con o senza id del comune devi vedere se un determinato civico già esiste nei dati di osm (perché i civici rilevati “a mano” non avranno id), anche per futuri import.

Ciao, Martin

Vero. Anche avendo l'id come trovi fuori un civico che durante l'importazione è stato corretto? (p.es. spostato nella posizione giusta). Per non rispostarlo nella posizione originale "sbagliata" durante l'aggiornamento?

Damjan

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by dieterdreist
Ciao,

On Thu, Nov 1, 2018 at 5:23 PM Martin Koppenhoefer <[hidden email]> wrote:

> On 31. Oct 2018, at 15:49, Andrea Musuruane <[hidden email]> wrote:
>
> Dato che il Comune di Milano aggiorna regolarmente il dataset dei civici, avere a disposizione l'ID ufficiale del civico, permetterà import futuri più veloci e precisi perché semplificherà notevolmente la fase di conflation.

io rimango dell’idea che non dovremmo fare aggiornamenti automatici, al meno non per quelli civici che sono già in osm (anche dall’import precedente). Visto che ora li controllate tutti, ogni modifica in futuro dovrebbe essere verificata individualmente. Altrimenti osm sarebbe usato come repository di dati ufficiali, non toccabili oppure toccabili ma senza senso, sapendo che il prossimo import sovrascriverà il lavoro fatto.

Con o senza id del comune devi vedere se un determinato civico già esiste nei dati di osm (perché i civici rilevati “a mano” non avranno id), anche per futuri import.

Io veramente non ho detto nulla di tutto questo. Ho solo detto che inserire un ref al dataset originario semplificherà la fase di conflation per futuri import, che altrimenti deve essere rifatta da zero, perdendo molto tempo che si può tranquillamente risparmiare. Tutto il resto sono tue congetture.

Ciao,

Andrea




_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by dieterdreist
Ciao,

On Thu, Nov 1, 2018 at 5:28 PM Martin Koppenhoefer <[hidden email]> wrote:
Dal dato si capisce a cosa si riferisce il civico (ingresso ad un fabbricato, cancello nel perimetro, ecc.)?

C'è l'indicazione del fatto che sia anche un passo carraio.

però non distingue tra passi carrai all’interno di fabbricati e quelli all’aperto?
Insomma, la distinzione tra entrance=yes/no e barrier=gate non è estraibile?

No, perché un passo carraio può essere un cancello, un garage, ecc.

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Alessandro P.
Il 01/11/18 17:58, Andrea Musuruane ha scritto:

>>
>>     C'è l'indicazione del fatto che sia anche un passo carraio.
>
>     però non distingue tra passi carrai all’interno di fabbricati e
>     quelli all’aperto?
>     Insomma, la distinzione tra entrance=yes/no e barrier=gate non è
>     estraibile?
>
>
> No, perché un passo carraio può essere un cancello, un garage, ecc.
>

Non ho analizzato i passi carrai in questione, ma normalmente un passo
carraio è un accesso dal privato al pubblico su cui vige
un'autorizzazione e una tassa.
Dei diritti di accesso all'interno delle parti private il comune non si
interessa. Ergo perchè dovrebbero esserci passi carrai all'interno di
edifici?

Alessandro

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist


sent from a phone

> On 1. Nov 2018, at 18:16, Alessandro <[hidden email]> wrote:
>
> Ergo perchè dovrebbero esserci passi carrai all'interno di edifici?


intendevo garage al piano terra/interrato sotto all’edificio (in osm entrance=* per l’accesso), contrario a barrier=gate (se non è un ingresso direttamente ad un edificio)


Ciao, Martin
_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Paolo Monegato
In reply to this post by Andrea Musuruane
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

ciao
Paolo M


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
Ciao,

On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <[hidden email]> wrote:
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Paolo Monegato
Il 06/11/2018 14:52, Andrea Musuruane ha scritto:

On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <[hidden email]> wrote:
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?

Metti che il civico è soppresso perché han murato l'ingresso. Avere un removed:addr:etc ti fa capire cosa c'era in precedenza. Idem se è stato soppresso perché han demolito lo stabile (removed:building)...

ciao
Paolo M


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

dieterdreist
In reply to this post by Andrea Musuruane


sent from a phone

On 6. Nov 2018, at 14:52, Andrea Musuruane <[hidden email]> wrote:

Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

Show Quoted Content
On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <[hidden email]> wrote:
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <[hidden email]> wrote:
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?


metti che la targa del civico ancora c’è. Io ci lascerei il civico finché abbiamo verificato che non ce ne è più traccia. Si può aggiungere un tag per indicare che il civico è stato soppresso, ma senza alterare i tags addr:*

A noi interessa anche un civico che sembra di esistere ma non è più ufficialmente registrato. Se stessi davanti un civico e diresti al tuo amico al telefono la posizione non ti interesserebbe se questo civico avesse valore legale.

Ciao,
Martin 

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by Paolo Monegato
Ciao,

On Tue, Nov 6, 2018 at 3:03 PM Paolo Monegato <[hidden email]> wrote:
Il 06/11/2018 14:52, Andrea Musuruane ha scritto:

On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <[hidden email]> wrote:
Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa si fa?

Elimini i civici perché non esistono più.

Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad esempio) per conservare la storia?

Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?

Metti che il civico è soppresso perché han murato l'ingresso. Avere un removed:addr:etc ti fa capire cosa c'era in precedenza. Idem se è stato soppresso perché han demolito lo stabile (removed:building)...

Ma non abbiamo sempre detto che "Historic objects with no relevance to current state of an object generally do not belong in OpenStreetMap"?

Per esempio, capisco mettere disused:amenity=drinking_water, se la fontanella è rotta e potrebbe essere riparata in futuro. Ma se la fontanella è stata rimossa, che senso ha tenere questa informazione?

Inoltre, tenere informazioni non più attuali complica notevolmente la mappa, anche in considerazione del fatto che abbiamo un layer unico di dati.

Ciao,

Andrea



_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: Import civici Milano - regole di traduzione

Andrea Musuruane
In reply to this post by dieterdreist
Ciao,

On Tue, Nov 6, 2018 at 5:34 PM Martin Koppenhoefer <[hidden email]> wrote:
metti che la targa del civico ancora c’è. Io ci lascerei il civico finché abbiamo verificato che non ce ne è più traccia. Si può aggiungere un tag per indicare che il civico è stato soppresso, ma senza alterare i tags addr:*

A noi interessa anche un civico che sembra di esistere ma non è più ufficialmente registrato. Se stessi davanti un civico e diresti al tuo amico al telefono la posizione non ti interesserebbe se questo civico avesse valore legale.

Perdonami ma stai parlando di cose assolutamente ipotetiche, senza alcuna verifica sul campo.

Per affrontare correttamente la questione, qualcuno deve dimostrare che c'è almeno un civico che risulta soppresso nei database del Comune di Milano e che invece in realtà è ancora presente.

Ciao,

Andrea


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
12