release: ReadOSM / spatialite-tools v.3.1.0

[a.furieri]

un po' di novita' sul fronte SpatiaLite:

a) una nuova libreria: ReadOSM
    implementa un parser a supporto dei datasets OSM: entrambi
    i formati (OSM-XML e OSM-probuf) sono supportati indifferentemente,
    consente di leggere i dati OSM in modo totalmnte astratto e
    trasparente:
    https://www.gaia-gis.it/fossil/readosm/index

b) un set di tools a supporto dei datasets OSM completamente rivisto
    (basato su ReadOSM) e' ora incluso nell'ultima spatialite-tools
v.3.1.0:
    https://www.gaia-gis.it/fossil/spatialite-tools/index

c) nuova documentazione Wiki sui tools OSM e sui grafi/routing OSM:
    https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=OSM+tools

Notizie importanti:
- per compilare gli spatialite-tools ora ReadOsm e' una dipendenza
   assolutamente obbligatoria.
- invece usare libspatialite v.3.1.0 non e' un prerequisito: i tools
   funzionano anche usando la precedente v.3.0.1
- gli eseguibili binari pre-compilati dei tools per Windows verranno
   rilasciati immediatamente dopo il rilascio di libspatialite v.3.1.0

buon divertimento,
Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Markus Neteler]

2012/5/5  <[hidden email]>:
> un po' di novita' sul fronte SpatiaLite:
>
> a) una nuova libreria: ReadOSM

...bello, bello!

Se volessi estrarre tutte le strade importante europee da OSM,
diventa facile?

ciao
Markus
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

On Sat, 5 May 2012 22:04:18 +0200, Markus Neteler wrote:
> Se volessi estrarre tutte le strade importante europee da OSM,
> diventa facile?
>

facile sicuramente si ... ma non necessariamente veloce :-)

durante i miei test p.es. ho usato spatialite_osm_net per estrarre
l'intera rete ferroviaria Europea (molto piu'  semplice della rete
stradale, ovviamente): eccoti qua un po' di numeri:

- Input: europe.osm.pbf (geofabrik) 7.72 GB
- Output: europe.sqlite
   ha toccato un picco di oltre 22 GB durante il processo (tavole
   temporanee): dopo il VACUUM finale si e' ridotto a circa 1 GB
- ci ha impiegato circa un paio d'orette ;-)

entrando piu' sul tecnico, il parsing di per se va via veloce:
quello che porta via tempo sono le fasi SQL per la gestione del DB

visto che per andarsi a ricostruire tutte le geometrie occorre
necessariamente fare un sacco di queries relazionali per ripescare
i singoli OSM-Nodes, quando le Ways sono milioni ed i Nodes sono
molte centinaia di milioni naturalmente il tempo necessario per
l'elaborazione non e' esattamente istantaneo :-)

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[geodrinx]

Alessandro,

durante i miei test p.es. ho usato spatialite_osm_net per estrarre
l'intera rete ferroviaria Europea 

Il risultato del caricamento in SpatiaLite è topologico ?

Dalla complessità delle query che descrivi, il risultato sembrerebbe esserlo.

Comunque, complimenti !

Roberto

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

On Sun, 6 May 2012 20:01:48 +0200, Geo DrinX wrote:
> Alessandro,
>
>> durante i miei test ho usato spatialite_osm_net per
>> estrarre l'intera rete ferroviaria Europea 
>
> Il risultato del caricamento in SpatiaLite è topologico ?
>

nel caso di spatialite_osm_net, si, e' topologico
serve proprio per estrarre un grafo (network) navigabile con algoritmi
di routing / shortest path

nel caso di spatialite_osm_map invece il risultato e' una "mappa"
composta dai classici layers non-topologici di tipo Point, Linestring
e/o Polygon

> Dalla complessità delle query che descrivi, il risultato sembrerebbe
> esserlo.
>

vista la struttura dati semi-topologica di OSM delle due la piu'
lunga e brodolosa e' sicuramente l'estrazione dei layers, visto
che occorre un numero ancora piu' elevato di queries, e visto anche
che il numero delle features interessate e' sicuramente molto piu'
elevato.

diciamo che sotto questo profilo dell'efficienza la struttura dati di
OSM non e' esattamente il massimo auspicabile: altri formati come il
GML v3-topology danno sicuramente un bel po' di filo da torcere, ma
comparativamente molto meno di quanto richieda il formato OSM. ;-)

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

Magnifico Sandro.

Produci più di quanto non riesca a provare! :)

Ma stavolta un po' di testing lo farò sicuramente.

giovanni

Il giorno 06 maggio 2012 21:13, <[hidden email]> ha scritto:

On Sun, 6 May 2012 20:01:48 +0200, Geo DrinX wrote:

Alessandro,

durante i miei test ho usato spatialite_osm_net per

estrarre l'intera rete ferroviaria Europea 

Il risultato del caricamento in SpatiaLite è topologico ?

nel caso di spatialite_osm_net, si, e' topologico
serve proprio per estrarre un grafo (network) navigabile con algoritmi
di routing / shortest path

nel caso di spatialite_osm_map invece il risultato e' una "mappa"
composta dai classici layers non-topologici di tipo Point, Linestring
e/o Polygon

Dalla complessità delle query che descrivi, il risultato sembrerebbe
esserlo.

vista la struttura dati semi-topologica di OSM delle due la piu'
lunga e brodolosa e' sicuramente l'estrazione dei layers, visto
che occorre un numero ancora piu' elevato di queries, e visto anche
che il numero delle features interessate e' sicuramente molto piu'
elevato.

diciamo che sotto questo profilo dell'efficienza la struttura dati di
OSM non e' esattamente il massimo auspicabile: altri formati come il
GML v3-topology danno sicuramente un bel po' di filo da torcere, ma
comparativamente molto meno di quanto richieda il formato OSM. ;-)

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

Un pensiero ad alta voce.

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. 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...

giovanni

Il giorno 06 maggio 2012 23:04, G. Allegri <[hidden email]> ha scritto:

Magnifico Sandro.

Produci più di quanto non riesca a provare! :)

Ma stavolta un po' di testing lo farò sicuramente.

giovanni

Il giorno 06 maggio 2012 21:13, <[hidden email]> ha scritto:

On Sun, 6 May 2012 20:01:48 +0200, Geo DrinX wrote:

Alessandro,

durante i miei test ho usato spatialite_osm_net per

estrarre l'intera rete ferroviaria Europea 

Il risultato del caricamento in SpatiaLite è topologico ?

nel caso di spatialite_osm_net, si, e' topologico
serve proprio per estrarre un grafo (network) navigabile con algoritmi
di routing / shortest path

nel caso di spatialite_osm_map invece il risultato e' una "mappa"
composta dai classici layers non-topologici di tipo Point, Linestring
e/o Polygon

Dalla complessità delle query che descrivi, il risultato sembrerebbe
esserlo.

vista la struttura dati semi-topologica di OSM delle due la piu'
lunga e brodolosa e' sicuramente l'estrazione dei layers, visto
che occorre un numero ancora piu' elevato di queries, e visto anche
che il numero delle features interessate e' sicuramente molto piu'
elevato.

diciamo che sotto questo profilo dell'efficienza la struttura dati di
OSM non e' esattamente il massimo auspicabile: altri formati come il
GML v3-topology danno sicuramente un bel po' di filo da torcere, ma
comparativamente molto meno di quanto richieda il formato OSM. ;-)

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

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.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Markus Neteler]

2012/5/7  <[hidden email]>:
...
> 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.

Volendo, c'è un po' di documentazione in merito:

http://grass.osgeo.org/programming7/vectorlib.html#vlibTopoManagement

ciao
Markus
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Maurizio Napolitano-2]

Il 07/05/2012 00:59, G. Allegri ha scritto:
> Un pensiero ad alta voce.
> 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. 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...

La comunita' dei neogeografi e' sempre un po' pasticciona ma poi sistema
gli errori e migliora le cose.
Ci sono un po' di pensieri su come migliorare il tutto
http://wiki.openstreetmap.org/wiki/API_v0.7
... diamo tempo al tempo ...

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012