[Talk-it] OSMNavigator/API 0.5 e varie

[Niko!]

Salve a tutti,
molti di voi mi avevano contattato per ottenere una copia di OSMNavigator. 
Purtroppo non ho potuto accontentare quasi nessuno in quanto la versione 
alpha che era quasi pronta per il rilascio è stata resa inutilizzabile dalla 
migrazione della api alla versione 0.5. Anche se ciò ha invalidato di colpo 
il lavoro di quasi un anno di sviluppo, poco importa, anzi fosse stato per me 
avrei proposto una "trasformazione" ancora più radicale, in particolare 
diretta verso un modello completamente GIS, con un sistema per implementare 
la topologia ad un livello di astrazione superiore. Tale cosa nonostante 
discussa e ridiscussa innumerevoli volte sulla dev e talk list è sempre stata 
vista con molta riluttanza, nonostante gli innumerevoli benefici che ne 
deriverebbero. Anche con il nuovo modello non è possibile, ad esempio, fare 
query del tipo  "dammi tutte le motorways d'Italia", interrogazione 
pesantissima con l'attuale organizzazione dei dati, e banale con un db gis 
oriented. Una delle caratteristiche di osmnavigator era quella di creare una 
shadow copy dei dati in temporeale con geometrie gis, indicizzate 
spazialmente,  e successivamente impiegate per il rendering dei tiles, cosa 
estremamente vantaggiosa soprattutto a zoom level molto bassi, e vi assicuro 
che la differenza prestazionale è imparagonabile.
L'avversione ai modelli GIS in generale traspare in ogni dibattito, non ultimo 
quello avviato da Niccolo' Rigacci, che saluto cordialmente dopo la sua  
fortunatamente breve assenza da OSM. Anche secondo me il tag is_in è 
completamente inutile, in quanto può essere derivato tranquillamente con un 
operazione di intersezione fra aree e punti, nativa e veloce appunto su 
sistemi gis, e che è intrinsecamente più manutenibile, in quanto 
se "graficamente" il luogo d'interesse ed il confine amministrativo sono 
ben "posizionati" sulla mappa, la relazione di appartenenza è implicita. Cosa 
che non avviene con i tag is_in, la cui modifica ed i cui errori sono 
difficilmente riscontrabili, e legati comunque da relazioni fra stringhe, per 
non parlare dello spreco in termini di storage. Perdonatemi comunque la 
divagazione, torno sul tema che volevo proporre. Devo migrare osmnavigator al 
nuovo modello, e mi rendo conto che il passasggio alla nuova api rivoluziona 
il vecchio concetto di editing. Spariscono i segmenti, i concetti di 
orientamento, switch di direzione, reordering (finalmente!). Voglio dunque 
ridefinire una modalità di "editing" comunque intuitiva orientata in maniera 
estrema al newbie. Con la api 0.4 osmnavigator ci era riuscito 
abbondantemente (instabilità varie a parte). In particolare un grande punto 
di forza era la modalità di costruzione delle way, che poi ho ritrovato 
parzialmente in potlatch. In pratica attivata la modalità di costruzione way 
(un click), bastava clickare su N posizioni per ottenere una way di n-1 
segmenti. Al termine si riclickava sull'ultimo punto (o si premeva esc) e si 
apriva automaticamente un dialog che chiedeva la classificazione della way ed 
altre tag con alcune combobox.
Altra cosa carina era il reoreding in tempo reale dei segmenti della way 
editata in subpath elementari consecutivi, che permettava in modo 
semplicissimo di creare aree con buchi, senza alcuna ulteriore fatica (e 
soprattutto altri click :)  (c'è un esempio in uno screencast su youtube). 
Ora mi ritrovo che una way nel nuovo modello è un elemento molto più 
semplice, in pratica un unica polyline, e quindi per manipolare ad esempio le 
aree con buchi, o sempicemente ways che si diramano devo usare più ways 
multiple ed una relazione fra esse. Non so a questo punto cosa fare del 
vecchio ed intuitivo build mode, ed in particolare se riemularlo nascondendo 
all'utente la generazione automatica di nuove way con autogenerazione delle 
relazioni, o demandare tutto all'utente, lasciando solo la possibilità di 
editing delle way elementari.
Questo è soltanto uno degli punti che devo analizzare prima di passare 
all'implementazione vera e propria. Se a voi fa piacere possiamo effettuare 
un lavoro di analisi assieme in modo da avere una specie di "editor" su 
misura, GPL e svincolato da Java.

Dimenticavo, l'idea della conferenza a Roma è bellissima ma, qualora ci 
dovessero essere problemi organizzativi in tale sede potete contare anche su 
Napoli come sito di backup, dove avremmo sicuramente l'appoggio del Nalug e 
dell'Università Federico II.

ciao

	Niko