[Talk-it] Import civici Milano - regole di traduzione

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 12:23 Uhr schrieb Alessandro Palmas <
alessandro.palmas a wikimedia.it>:

> 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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20181031/92f2fcfa/attachment.html>