[Talk-it] OSMNavigator/API 0.5 e varie

[Niko!]

On Thursday 11 October 2007 13:43:08 f.pelullo at libero.it wrote:

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

[...]

> Il punto e' che (se ho ben capito) lavori soltanto tu al progetto.
> Pensa che cosa succederebbe se, prima che tu finisca di aggiornare il
> tuo (ho visto gli screencast e devo dire ottimo) lavoro, le api si
> evolvono di nuovo.

Penso che una volta "aperto" qualcuno inizierà a partecipare allo 
sviluppo/manutenzione, o nel momento in cui non possa dedicarci tempo 
personalmente avverrà un cambio di mantainer (vedi Josm).
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.

> >  L'idea del plugin QGIS non è affatto male, ma potrebbe
> > essere vista come un progetto parallelo, in quanto non credo sia adatta
> > al newbie.
>
> IMHO proprio per noi newbees occorrerebbe distinguere quello che e'
> l'editing grafico/geometrico (che puo' essere automatizzato)
> dall'editing dei metadati (toponomastica, classificazione elementi etc.)
> che deve essere eseguito "a mano".
> Qualsiasi newbee e' in grado di cliccare su un elemento e compilare la
> maschera che compare.
> Pochi invece saprebbero "disegnare" correttamente un segmento/arco/nodo.

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.

> 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?
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!

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

> Ad esempio, propongo di implementare nel client una "palette" contenente
> le icone dei tipi di strade standard  (autostrada, statale due corsie
> etc.) e di una "bacchetta magica" per "copiare il formato" su un
> elemento grezzo.
> Questo aiuterebbe molto e, al tempo stesso, renderebbe "uniformi" i
> metadati associati ad ogni elemento.

Ottima idea!

> > L'obiettivo e tirare fuori un setup.exe o un rpm/deb etc.
> > dall'istallazione semplice ed utilizzo intuitivo.
> >
> > 	Niko
>
> Proprio per non "impazzire" (scusa)  :-) dietro a queste cose, potresti
> utilizzare un altro editor opensource gia' ampiamente diffuso e
> supportato come QGIS e concentrarti sul cuore del problema.

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à.
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 :)

Ciao

	Niko