[Talk-it] OSMNavigator/API 0.5 e varie

f.pelullo at libero.it f.pelullo at libero.it
Sat Oct 13 08:38:47 BST 2007


Niko! ha scritto:
>> Mi spiace, capisco perfettamente quanto impegno hai posto nello sviluppo
>> di OSMNavigator. Mi sa proprio che alla convention ti offriremo da bere.
>> ;-)
>>     
>
> Non vi conviene :) su questo vado daccordissimo con gli amici d'oltre 
> manica :)
>
> [...]
>
>   
Eh, e che sara' mai? :-)
> In ogni caso se qualcuno vuole collaborare non ci sono assolutamente problemi, 
> su qualsiasi fronte, analsi/test e perchè no anche sviluppo diretto di codice 
> in c++, l'importante è che i sorgenti non vengano diffusi prima del rilascio 
> pubblico.
>
>   
Io declino immediatamente l'offerta, sono troppo infognato e per 
prinicipio se mi devo impegnare a fare qualcosa voglio provare a farla bene.
Se vuoi posssiamo parlarne, nella mailing list o nel wiki.
> Anche questo è vero, anche se pensavo di risolvere il problema diversamente, 
> in quanto in questa fase del progetto, soprattuto in Italia, dove siamo 
> pochini, necessitiamo dell'apporto di tutti e non solo dei "power-users". In 
> In ogni caso, prima o poi, ci sarà il problema di assicurare la qualità dei 
> dati, questo per evitare che una junction sbagliata ad esempio allunghi 
> una "navigata assistita" di qualche decina di chilometri! Pensavo dunque che 
> una volta raggiunto una livello di copertura dati alto per un'area, la stessa 
> dovrebbe essere "lockata" e gli edit permessi solo ad una sorta 
> di "responsabile" di area, se non in tutto almeno sulla parte tipicamente 
> strade/routing. Tutto ciò con meccanismi di protezione "democratica". Non 
> dimentichiamo infatti che scollegando alcuni nodi, o taggandoli in un certo 
> modo è possibile facilitare il passaggio per determinate zone dove il 
> responsabile di area potrebbe avere che so, un albergo, un bar etc. :)
> Tale cosa dovrebbe automaticamente limitare i danni del newbie a regime.
>
>   
:-) Il tuo cognome e' Machiavelli? :-)

>> Non sono un programmatore (non sono mai andato oltre il F77 ;-)) ma
>> ritengo che quello che manca in questo momento e' un buon algoritmo di
>> elaborazione statistica delle tracce grezze, in grado di analizzarle e
>> fonderle (riconoscendo ad esempio dalla velocita' se sto viaggiando
>> sulla statale o sulla complanare, oppure dalla quota se mi trovo sopra o
>> sotto un ponte).
>>     
>
> Potrei proporre il tema come argomento di tesi qui all'Università, solo che 
> prima di andare da un prof. ed inguaiare qualche laureando vorrei essere 
> certo della fattibilità della cosa :) possiamo iniziare a discuterne qui e 
> sulla lista di gfoss?
>   
Certo. Qualcosa di molto vago su Google si trova, prova a cercare GPX +grass

> Abbiamo in ogni caso idea di quanto raccolto in raw/gps non sia stato 
> adeguatamente coperto da un layer OSM? anche questo dato è importante per 
> valutare se vale la pena o meno imbarcarsi in questa avventura!
>
>   
Beh, io ad esempio ho raccolto finora piu' di 150MB di tracce GPX 
(frequenza campionamento 1s, e sono uno che va piano).
Non le ho caricate perche' temo che confonderei le idee a qualcuno 
(moltissime tracce si riferiscono alla stessa strada, loggata all'andata 
ed al ritorno piu' volte).
Pero' ho anche cose carine, tipo Cerignola-Parigi andata e ritorno 
(andata via tunnel Gran S. Bernardo, ritorno via tunnel Monte Bianco). 
Oppure il volo Alitalia Bari - Fiumicino.
>> Con un gis normale (ad esempio GRASS) queste cose si possono fare. Dopo
>> aver creato la geometria, chiunque puo' editare i metadati.
>>     
>
> GRASS già media e vettorializza tracciati GPX? beh questo tema va 
> assolutamente affrontato alla convention di febbraio :)
>
>   
Non sono un esperto di GRASS e quindi non so se e' la procedura piu' 
corretta.
GRASS permette di eseguire un offset a partire da un vettoriale. Ad 
esempio, il mio ricevitore ha una risoluzione media di 4x4 metri, quindi 
posso creare un offset di 2m a sinistra e 2m a destra della traccia.
Ripeto per ogni traccia.Avro' una serie di "fasce" larghe 4m. Alcune di 
queste fasce si sovrappongono. Uso le funzioni di mapcalc per fonderle 
assieme in un vettoriale nuovo. Poi creo la topologia etc.

Lo stesso potrei fare con un raster risoluzione 4x4 (avendo un hardware 
adeguato), considerando la traccia grezza come un insieme di punti. 
Dalla somma di tutte le tracce grezze potrei ricavare un raster che 
contiene delle celle che "esprimono" con un valore intero quante volte 
quella cella e' stata "accesa". Il raster si puo' analizzare 
statisticamente, "assottigliare" (r.thin) e trasformare facilmente in 
vettoriale. Creo la topologia ed esporto nel formato che voglio.


> Non conosco bene QGIS, può darsi che mi sbagli, ma vedo delle difficoltà. Un 
> plugin che prenda dati GIS e li salvi in osm per un upload la vedo una cosa 
> fattibile, ma l'editing di un area preesistente chissà.
>   
Quindi la prima cosa che farei io sarebbe quella di implementare un 
algoritmo di conversione dal formato OSM ad altro formato (ad esempio 
shapefile) gestito bene da QGIS e viceversa, senza perdere nulla.
Una volta che ho importato in QGIS posso usare le sue funzioni di editing.
Anzi, una volta convertito in shapefile, posso lavorarci su da GRASS.
> Scaricare un bounding box in formato osm, convertirlo in un formato interno 
> manipolabile da QGIS, modificarlo e riconvertirlo in formato osm, cercando di 
> non perdere alcuna sua caratteristica "semitopologica", parlo di nd ref, id 
> etc, tag di relazioni fra ways semplici etc. è fattibile? dovremmo avere 
> qualche dettaglio sull'architettura di QGIS, o cosa molto + semplice 
> rivolegere la domanda direttamente a loro :)
>   
L'idea di chiedere a loro e' buona.

Ciao
niubii





More information about the Talk-it mailing list