[Talk-it] Carta tecnica Comune di Lecce

[Francesco Pelullo]

Il 30 giugno 2014 12:45, Martin Koppenhoefer <dieterdreist at gmail.com>
ha scritto:
>
> 2014-06-30 12:29 GMT+02:00 Francesco Pelullo <f.pelullo at gmail.com>:
>
>
> Quindi mi stai dicendo che il tag "source" non vale per la versione attuale
> ma per quella dove è stato aggiunto il tag? A quel punto non vedo più il
> vantaggio di avere il tag all'oggetto, tanto devo comunque guardarmi lo
> storico.
>

Non capisco.
Per me un tag è valido se e solo se lo consideri associato ad una
certa feature ed ad una certa versione.
E' chiaro che se la versione si incrementa, il tag potrebbe essere
invalido. Non soltanto per il tag source, vale per tutti i tag.

Tanto più, come scrivevo prima, che poi risulta impossibile eliminare
il tag source=* dall'history dell'oggetto modificato, se questa
informazione è scritta nel changeset.
Molto più pratico scriverla per ogni oggetto. Se l'oggetto cambia
"troppo", e source=* non ha più senso, si rimuove facilmente.


> In generale è molto complicato trovare nodi spostati (perché non creano
> versioni nuovi della way, quindi dovresti vedere per ogni nodo quale
> versione aveva nel momento che è stato creato la way e quale versione hanno
> attualmente). Questo problema si deve affrontare in ogni caso (con source
> all'oggetto ed al changeset).
>

Questo è IMHO un bug grave del database, andrebbe rivisto il
meccanismo con cui si attribuisce il numero di revisione di ogni
feature.
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 ha senso, il database contiene oggetti che hanno senso se vengono
considerato con la loro topologia e non si può prescindere dalla
forma.
Ma questo è OT di questo thread.

> In generale lo stato "originale" dovrebbe essere la versione 1 oppure la
> versione 1 degli oggetti accanto (nel caso che si ha diviso oggetti).
> L'unica soluzione "facile" sarebbe guardarsi gli changesets interi di un
> import e paragonare allo stato attuale della mappa per evitare di dover
> verificare a mano ogni singolo oggetto.

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.
Molto più semplice analizzare oggetto per oggetto, a questo punto il
processo potrebbe essere reso automatico facendo girare un bot che
rimuova il tag source=* dagli oggetti troppo "diversi" dalla rev. 1 in
cui fu aggiunto source.


>
> Io ammetto, non mi faccio troppi problemi, a prescindere dei tags source mi
> guardo un oggetto, ed è o ben rappresentato o lo cambio ;-) A cosa serve un
> source=local_knowledge, se l'oggetto è sbagliato? O un source=bing;pcn? O un
> tag source=survey;bing;pcn?
>

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

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.

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


Ciao
/niubii/