[Talk-it] Carta tecnica Comune di Lecce

Lun 30 Giu 2014 15:51:15 UTC

2014-06-30 17:00 GMT+02:00 Francesco Pelullo <f.pelullo at gmail.com>:

> E' chiaro che se la versione si incrementa, il tag potrebbe essere
> invalido. Non soltanto per il tag source, vale per tutti i tag.
>

bo, per me sarebbe un errore, è il compito di chi modifica e carica la
versione aggiornata di assicurarsi che l'oggetto è ancora consistente (e
quindi deve togliere/estendere il tag "source" se ha fatto delle modifiche
che non sono più unicamente basati sulla fonte originale). Se poi l'oggetto
ha come source "survey;bing;local_knowledge;pcn" e l'utente fa una mofica
basata su una di queste fonti, allora non deve fare niente e chi si guarda
lo storico può indovinare quale delle fonti presenti ha usato, oppure se ha
dimenticato di indicare la fonte ;-)

Questo è IMHO un bug grave del database, andrebbe rivisto il
> meccanismo con cui si attribuisce il numero di revisione di ogni
> feature.
>

come vorresti che fosse invece? Altrimenti si dovrebbe scrivere una nuova
versione per ogni relazione che contiene un way che contiene un nodo che
viene spostato...

E' importante capire che l'unico oggetto "geometrico" in osm sono i nodi, e
tutto il resto è solo riferimento e tag.

> E' impensabile che se ho un edificio "quadrato" alla rev. 1 e
> successivamente sposto i nodi per rialliearlo alle ortofoto, l'oggetto
> rimanga rev. 1
>

non, è così ed ha senso per come funziona il sistema.

Giusto, il tag source ha senso soltanto se associato ad un oggetto rev. 1.
> Però credo che sarebbe un compito impossibile analizzare un changeset
> intero, sia per un umano che per uno script, sopratutto poi se si
> tratta di un import di millemila feature.
>

per uno programma niente è impossibile, un umano probabilmente dopo un po'
si stufa, lo credo anch'io.
Se quel import viene fatto con un utente dedicato la cosa è molto facile:
per reperire tutti gli oggetti importati è sufficiente vedere gli edits
dell'utente. finito lì.

Quoto: anche io se possibile non mi faccio tanti problemi.
>

bene :)

>
> Però capitano casi particolari in cui devi impazzire per capire da
> dove è saltata fuori quella informazione. Pensa ad una strada di nuova
> costruzione, visibile sulle ortofoto PCN2012 ma non in quelle di Bing
> o PCN2008. In casi come questo, con il tag source=* associato
> all'oggetto, la verifica richiede un attimo.
>

anche senza tag source, la vedi nel ortofoto 2012, no?

>
> Per tornare OT, secondo me il tag
>
> source=nome_del_layer_della_CTR_da_cui_questa_info_e'_stata_desunta_o_qualcosa_del_genere
> è indispensabile, non solo perchè consente di risalire alla fonte del
> dato, ma perché consente una successiva revisione dell'import.
>

fatto sta, lo dicono per ogni import e non è mai stato fatto. :)
Sai perchè? Perchè appena gli utenti migliorano i dati, splittano i way,
spostano i nodi, diventa impossibile capire nel caso di divergenze qual'è
il dato affidabile (in generale mi fiderei più dei utenti OSM che hanno
applicato delle modifiche a seguito di rilievi che da dati amministrativi,
che hanno applicato modifiche a seguito di non so).

> Ad esempio, in prima battuta si importeranno i manufatti "Cabina
> acquedotto" con tag building=yes perché non esiste un tag più
> specifico.
>

propongo di creare una proposta di tagging per "cabina acquedotto" - ora -
invece di importarlo con "building=yes" ed aspettare il futuro.

Tra qualche tempo, si potranno cercare le features che
> hanno tag source=CTR_layer_34540000 e riclassificarli con
> building:type=service building:type:service=acqueduct
>

al solito non lo puoi fare perché se un mappatore trova un edificio con
"source=CTR_layer_34540000" e lo spezzo in due, quello tag  è uno dei tags
che probabilmente rimangono incomprensibili e quindi probabilmente non lo
modifica / aggiusta ma lo lascia a tutti i due oggetti.

ciao,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20140630/85146859/attachment-0001.html>