[Gfoss] release: ReadOSM / spatialite-tools v.3.1.0

[a.furieri a lqt.it]

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 :-D
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' :-P


> 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 :-D

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.