[Gfoss] gestione di sensi (unici) di strade

[Bud P. Bruegger]

> Mooooolto interessante, stavamo giusto discutendo di fare una cosa
> simile per GeoServer :-).

Mi ha sempre piaciuto REST, ma anche python, e guando si vede come e'
minimo feature server, no si puo non inamorarsi ;-)

> Diciamo che ci sono due strade su cui le persone si stanno muovendo.
> Una è aggiungere funzionalità come routing e geocoding a WFS come
> sotred procedure or something like it, l'altro approccio è di mettere
> un bel WPS
> su per fare le operazioni in modo da non " incasinare" la divisione in
> tier proprio dei servizi OGC (WFS data management, WPS business loigc
> aka processing).

Ho scoperto oggi che per WPS esiste un fratello di featureserver che
sembra ugualmente elegante e REST:  Guardati la demo:

http://crschmidt.net/mapping/wpserverdemo/

Certo che wps e' meglio che fare una cosa monolitico in stored
procedures...  Ma piccolo e elegante in REST mi sembra piu' addatto per
uso interno che la stessa cosa molto piu' pesante..

> Noi in questo momenti stiamo lavorando un pochino su WPS con
> l'obiettivo di integrarli in una architettura enterprise con workflow
> management. Ci sono alcuni progetti interessanti da usare e riusare,
> stiamo valutando se integrare qualcosa in geoserver o meno. Stiamo poi
> guardando a udig perche' esiste un plugin per accedere a WPS piu'
> svariati tools basati su eclipse RCP per fare workflow management.

So di udig ma fin ora mi sono orientato molto piu' verso qGIS.  Sara'
perche C/python mi e' molto piu' simpatico che Java...

> Mio modestissimo parere. Qualcuno piu' noto e bravo di me ha detto
> "l'ottimizzazione precoce è la radice di tutti i mali" e concordo,
> ma cmq il punto è che si deve tenere conto a livello architetturale
> dei problemi di performance e lasciare spazio alle soluzioni
> altrimenti poi son guai!

Si, sono d'accordo che l'architettura limita fortemente la scalabilita'
e che non si cambia al volo in un secondo passo.  Detto questo, non
penso che noi per usi interni abbiamo bisogno di una architettura
"enterprise" (come in J2EE con EJB e tutto cio') e il time to market e'
molto piu' importante ;-)

> > Verso il fuori (cittadini, potenzialmente tanti), la situazione e'
> > certamente molto diverso--ma anche il fabbisogno di creare e modificare
> > geometrie (la maggiore ragione per quale vorrei vector tramite web) e'
> > molto limitato (a mettere qualche punto con annotazione su qualche
> > piano oppure in casi eccezionali un poligono...).
> >
> 
> Hai pensato a gestire la sicurezza con un approccio RBAC? Ci sono
> cosine interessanti da tenere conto in fase di progetto anche se
> magari le si implementa poi.

Si, per tutti servizi tramite web, noi usiamo RBAC.  E' molto usato da
noi; ad esempio per i scedolini dei impiegati e par le forze
dell'ordine che accedono a alcuni dei nostri dati dall'esterno.  Per
tutto questo richiediamo smartcards per autenticazione (incluso la CIE
che emettiamo noi).  A proposito, sono io l'architetto della nostra
soluzione e ho implementato la prima versione dell'apache handler che
fa l'autenticazione.  Piccolo, semplice, e sicuro ;-)

La cosa bella del REST e' che lostesso sistema funziona anche qui ;-)

Detto questo, attualmente al interno usiamo qGIS che accede a postgres
tramite username/password.  Ma internamente, la sicurezza e' diverso
che sul internet ostile ed i rischi non sono tanto alti (al meno se
inizio fare backups ;-).

Ma siccome mi piace semplicita', provo di semplificare il problema di
controllo di accessi al massimo:  avere quanto possibile dati sotto una
licenza aperta (ancora da raggiungere ;-)

saluti
-b