On Mon, 7 May 2012 00:59:48 +0200, G. Allegri wrote:
Un pensiero ad alta voce.
ma si dai, ogni tanto anche i pensieri ad alta voce aiutano 
Una delle cose più "bruttine" del modello dati OSM è l'avere
delegato l'interpretazione di una way chiusa come polilinea o area al
significato dei tag associati.
fosse solo per questo, la vita sarebbe un letto di fiori 
il problema ben piu' generale e' che avere scelto una stuttura di tags
molto lasca (e con una stupefacente fantasia d'uso da parte dei mappers)
rende tutte le fasi del parsing molto "ballerine" ed incerte.
in altri termini, gli OSM tools stanno faticosamente raggiungendo la
maturita' piu' che altro a forza di "indovinelli" e di suggerimenti vari
che arrivano in ordine sparso da parte di alcuni utenti volenterosi.
ma siamo pur sempre nel campo delle assunzioni euristiche altamente
opinabili: spesso fai centro, ma altrettanto spesso rischi di padellare
d'altra parte, in assenza di meglio tocca fare di necessita' virtu' 
Per un sw come readOSM questo si
traduce in un confronto testuale, per ogni way, contro l'elenco di tag
da considerare areali, per decidere se trattarla come linestring o
come polygon. Anche questo non aiuta di certo le performance...
vero, giusto.
ma fortunatemente tutti i tags sono elencati direttamente all'interno
della definizione XML di ciascuna singola feature, quindi questo step
e' abbastanza efficiente (ammesso e non sempre concesso che trovi i
tags "giusti" che ti aspetti di trovare).
il vero dramma del formato OSM e' che solo i nodes esponhono le coordinate,
mentre le ways fanno semplicemente riferimento ad un elenco di nodes
tramite ID.
e quindi per ricostruire un linestring di 1000 vertici tocca per forza
andarsi a ricercare pazientemente 1000 nodes, uno alla volta ...
qundo i nodes sono svariate decine di milioni, ti puoi immaginare facilmente
quale sia l'efficienza del processo nel suo complesso
giusto per confronto comparativo, un "vero" formato topologico come
p.es. GML-topo espone direttamente tutta l'intera sequenza di coordinate
del linestring; quindi solo i punti estremi (=nodi topologici)
richiedono di essere gestiti a parte.
mica una differenza da poco in termini di complessita' / numerosita' ...
inoltre i formati "veramente topologici" ragionano in termini di node/edge/face:
e quindi assicurano un mapping coerente che consente di ricostruire
Points, Linestrings e Polygons con assoluta certezza deterministica.
il modello OSM basato su node/way/relation viceversa e' decisamente troppo
lasco ed indeterminato per poter essere considerato veramente topologico.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
