Ciao a tutti,
segnalo la pagina
http://www.regione.toscana.it/-/open-source
la pagina
http://www.regione.toscana.it/-/open-geodata
e la pagina
http://www.dati.toscana.it/group/territorio-ambiente
tutte in continua evoluzione.
Ciao,
Maurizio
Il 04/01/2014 17:35, Maurizio Trevisani ha scritto:
Ciao a tutti,
segnalo la pagina
http://www.regione.toscana.it/-/open-source
questa secondo me deve diventare una best practice di riferimento in Italia
la pagina
http://www.regione.toscana.it/-/open-geodata
e la pagina
http://www.dati.toscana.it/group/territorio-ambiente
tutte in continua evoluzione.
dopo aver sfogliato il catalogo mi faccio una domanda:]
secondo la definizione di open data il WMS
rientra come formato per i dati?
Secondo me no in quanto è più una rappresentazione del
dato che il dato stesso, meglio sarebbe un WFS.
Mi sbaglio?
On 06/01/2014 23:27, Maurizio Napolitano wrote:
dopo aver sfogliato il catalogo mi faccio una domanda:]
secondo la definizione di open data il WMS
rientra come formato per i dati?
Secondo me no in quanto è più una rappresentazione del
dato che il dato stesso, meglio sarebbe un WFS.
Mi sbaglio?
Si.
Ma il punto è che il WMS è un servizio , esattamente come il WFS è un servizio.
Sarebbe fuorviante anche il WFS.
Perche' il dato geografico non è composto solo dal semplice vettoriale.
Se non ci credi pensa ai dati DXF di una ctr non vestita.
E confrontala con il raster (che puoi vedere da un servizio wms) di una CTR vestita.
Vedrai come la seconda è molto piu' leggibile.
Ma non è solo una questione di leggibilita' , ma anche di informazione.
La vestizione è essa stessa una fonte di informazione ulteriore rispetto al dato grezzo.
Per questo molti utenti a fronte dei dati non vestiti preferiscono quelli vestiti.
Da qui si intravede la potenza e la rilevanza del WMS , molto piu' che del WFS.
Onestamente , io penso che il wfs non serva a niente dal punto di vista dello scarico dei dati.
Sembra solo una enorme perdita di tempo.
Se provi a scaricare qualsiasi cosa da un server wfs.
Intendo qualcosa che sia piu' grande di un francobollo, vedi subito che nascono problemi . Devi fare piu' richieste e poi devi pure ingegnarti per convertirle in un formato usabile.
Per cui li diamo subito in shapefile , si fa' prima .
Invece, abbiamo trovato un ottimo ruolo per il WFS quando si è trattato di mettere in piedi dei meccanismi di ricerca.
Ecco uno scopo per il WFS supportare ricerche da remoto.
Li' se la cava bene e da' un senso al suo impiego.
Ma nel download,
per carita'.
ciao,
A.
Onestamente , io penso che il wfs non serva a niente dal punto di vista dello scarico dei dati.
Sembra solo una enorme perdita di tempo.
Anch'io pensavo questo, finché non ho scoperto che WFS è scaricabile anche per finestre (BBOX), come il WMS.
Ancora non ho capito da quale versione minima del servizio WFS esiste questa funzione, ma essa esiste. Usandola, un client può caricarsi dinamicamente i dati vettoriali visibili in finestra, ed eventualmente (con WFS-T) anche modificarli.
Sbaglio ? Nel caso sia così, non prenderei troppo sotto-gamba il WFS... 
Ciao
Roberto
Ciao a tutti,
provo a dire la mia … quindi tutto opinabile
secondo la definizione di open data il WMS rientra come formato per i dati?
Opinione personale no: il WMS non è un “formato dati” semmai un “qualcosa” (protocollo??), che viaggia su chiamate http.
Riporto la definizione ufficiale per come è stabilita da OGC
“The OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases.”
Parlare quindi di formato dati è fuori luogo anche se spesso lo si rtrova citato nei vari geoportali o portali open data, ma secondo me è un errore e no fa che generare confusione.
Sempre a livello personale mi piacerebbe di più sentir parlare di “open service” che può rappresentare tra l’altro un’evoluzione o un livello successivo al concetto di open data (avere dati open, disponibili, raw, ecc … può essere utile a certi scopi, ma avere anche dei servizi standard immediatamente disponibili a volte è comodo e utile …
Discorso analogo lo farei per il WFS.
Su quest’ultimo aprirei una breve parentesi: usare il WFS per il download dei dati o per visualizzare i dati vettoriali, per quanto tecnicamente possibile è un errore concettuale. Può andare bene per dati prototipali (e comunque piccoli), ma ben presto si riscontrano i supoi limiti in questa modalità di utilizzo. Il WFS permette di ottenere il datto vettoriale e fronte di una selezione ma quetso non vuol dire che i criteri di selezione possono essere incontrollati: sarebbe un po come fare una query applicativa alfanumerica su una tabella gestionale di moltissime righe e pretendere di avere risposte immediate. Forse agire applicativamente con ottimizzazioni query, paginazione, ecc … aiuta la fruizione.
Lo stesso per WFS che quindi va utilizzato con le dovute attenzioni e il quel caso diventa utile: si pensi ad esempio a dover evidenziare, in un’applicazione web, le features di un layers offerto da un servizio WMS / WFS: effettuando una richiesta WFS si ottengono le geometrie che poi possono essere evidenziate usando OpenLayers, Leaflet, ecc … che sanno trattare gli elementi vettoriali esposti. Altro caso in cui il WFS si dimostra interessante è nell’utilizzo in processi WPS eseguiti server side.
Ciao
Cesare
···
Cesare Gerbino
http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b
Il giorno 07 gennaio 2014 08:35, Geodrinx <geodrinx@gmail.com> ha scritto:
Onestamente , io penso che il wfs non serva a niente dal punto di vista dello scarico dei dati.
Sembra solo una enorme perdita di tempo.Anch’io pensavo questo, finché non ho scoperto che WFS è scaricabile anche per finestre (BBOX), come il WMS.
Ancora non ho capito da quale versione minima del servizio WFS esiste questa funzione, ma essa esiste. Usandola, un client può caricarsi dinamicamente i dati vettoriali visibili in finestra, ed eventualmente (con WFS-T) anche modificarli.
Sbaglio ? Nel caso sia così, non prenderei troppo sotto-gamba il WFS…Ciao
Roberto
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
Si.
Ma il punto è che il WMS è un servizio , esattamente come il WFS è un
servizio.
Ho letto e riletto la tua email e non mi trovo del tutto concorde.
Non tanto sulla questione WFS, ma proprio sul fatto di dare i dati
*solo* in WMS (che è quello che ho visto sul portale dei dati aperti
della Regione Toscana).
Concordo che il WMS e tutte le vestizioni sono importanti, ma è anche
il modo per dire come il dato viene rappresentato ed utilizzato da chi
lo fornisce.
È un arricchimento non da poco ma deve essere accompagnato anche dai
dati raw.
Un esempio da seguire è quello di Vienna dove i dati geografici
vengono esposti in n formati (in virtù di un geoserver che offre
i dati convertiti in GML, geojson, KML, CSV, Shapefile), le sorgenti
WMS e WFS e come questo dato viene rappresentato nel piano urbanistico.
Ne avevo parlato qui
http://www.slideshare.net/napo/i-dati-geografici-come-punto-di-partenza-per-una-strategia-open-data/23
Secondo me è un ottimo esempio per far veicolare i dati geografici
open data nell'insieme del loro valore.
2014/1/7 cesare gerbino <cesaregerbino@gmail.com>:
effettuando una richiesta WFS si ottengono le geometrie che poi possono
essere evidenziate usando OpenLayers, Leaflet,
WFS "classico", nel senso di richiesta che ritorna GML, è di fatto
inutilizzabile in contesti di questo tipo causa "verbosità". Come dice
andrea, di fatto WFS sembra solo una enorme perdita di tempo per gli
utilizzi più comuni.
Diego Guidi
Il BBOX, è roba risaputa da tempo.
Non è quello che aiuta .
Come dicevo a meno che non si punta ad avere francobolli di territorio.
Ma il discorso si fa' lungo e probabilmente non interessa a nessuno a parte noi.
Per cui se vuoi contattami in privato e ti spiego perche' io lo reputo inutile il WFS anche in presenza del famoso BBOX.
Tra l'altro se guardi nel mio intervento a gfoss di bologna trovi in esso un link che permette di eseguire una ricrca ben piu' sofisticata basata su una intersezione pooligonale (anche se quadrata),
che è piu' potente di un semplice BBOX.
Il BBOX che te usi, di fatto esegue un clip .
Perche' ha il senso di dire "tutto cio' che sta al di fuori di questo box non mi interessa e quindi puoi tagliarlo"
E quindi altera la geometria di richiesta.
Ottenendo quindi l'effetto opposto, ovvero avere dei datasets tagliati.
Il fatto è che se vuoi una porzione di territorio appena piu' ampia di un francobollo, con il WFS diviene un casino .
Chiunque gestisce un sistema WFS serio deve imporre un limite alle features.
Lo' fa' il PCN , lo facciamo anche noi, lo fanno anche all'estero.
Chi non lo fa' , non lo fa' o perche' non si rende ben conto di cosa comporta non lo fare, oppure lo considera un semplice adempimento burocratico che poi se il sistema si pianta , bastera' mettere in piedi sistemi piu' grossi.
L'unico che ha tentato di gestire questo problema in maniera seria e coscienziosa è Furieri, che dietro nostre istruzioni ha messo in piedi un sistemino che funziona.
Ma anche quello funziona solo in casi molto sporadici.
Perhce' usa ilmetodo del paging che è un pagliativo informatico e non risolve un bel niente.
Perche' per avere un VERO download con WFS occorrerebbe effettuare il download sezionato per porzione di territorio.
Ovvero ritagliare lato client il territorio in griglie fitte, e scaricarle una per una, evitando di avere il clip sui bordi, altrimenti si introduce degli arrtotondamenti che
aleterano il dato e farebbero dire che cio' che si scarica non è il vero dataset, ma una sua versione approssimata.
Ma anche ammesso che si riesca a mettere in piedi un sistema di questo genere , cosa di cui dubito fortemente.
Resterebbe intatto i due problemi principali.
Come fare a sapere se il download di una porzione di territorio è completo o e' troncato sul lmite massimo di features e come rimuovere eventuali doppioni che si formeebbero tra porzioni adiacenti di territorio.
Ricevere dati in GML e doverli decodificare e rimuovere i doppioni.
Una cosa difficilissima.
E quindi se si parla di un sistema che deve funzionare davvero , per distribuire i dati in OpenData, molto meglio degli zip con shapefile preconfezionati.
A.
On 07/01/2014 08:35, Geodrinx wrote:
Onestamente , io penso che il wfs non serva a niente dal punto di vista dello scarico dei dati.
Sembra solo una enorme perdita di tempo.Anch'io pensavo questo, finché non ho scoperto che WFS è scaricabile anche per finestre (BBOX), come il WMS.
Ancora non ho capito da quale versione minima del servizio WFS esiste questa funzione, ma essa esiste. Usandola, un client può caricarsi dinamicamente i dati vettoriali visibili in finestra, ed eventualmente (con WFS-T) anche modificarli.
Sbaglio ? Nel caso sia così, non prenderei troppo sotto-gamba il WFS...Ciao
Roberto
Ciao Maurizio, probabilmente a causa dell’ora tarda ho scritto male. Ma ho riletto anche io la mia email e non mi pareva di aver scritto che i dati vanno veicolati SOLO in WMS. Ho caso mai scritto che il WFS non serve a niente. Ma questa è una altra cosa. Te sai che noi abbiam un sito denoinato cartoteca da cui i dati sono scaricabili come zip files ? In esso si puo’ scaricare i dati in vettoriali o raster georef o non. Tutto cio’ che possiamo divulgare li’ si trova. Pero’ mi permetto di farti notare che la normativa Inspire di cui spesso vi riconducete per dare forza ai discorsi. Promuove l’iteroperabilit’a come valore di per se’. Non sta scritto da nessuna parte che i dati se messi sul WMS devono obbligatoriamente essere anche scaricabili con il WFS. Il WMS e il WFS son due servizi differenti. Nati per scopi differenti e per loro natura agiscono pure su dati differenti. Il WFS è nato per l’editing da remoto e su tale base trova un senso di esistere. Proprio perche’ si rivolge all’editing da remoto ecco che ha poco senso in un ambito come quello della PA dove l’acceso ai dati pe rla loro modifica deve essere controllato e gestito molto bene. Invece una cosa che ha veramente senso fare con il WFS (ah se avessi brevettato l’idea invece di raccontarla) è usarlo per la ricerca da remoto. Quella si’ che funziona e parecchio bene. Altro che sistemi webservices e menate assolutamente fuori standards, basate su strutture di dati che tanto mai nessuno userà perche’ troppo costose da gestire. Di solito questi sistemi mnascon sull’onda di finanziamenti europeri e muoiono con il terminare di essi. Tornando all’impiego del WFS come sistema di ricerca: Mi risulta che ad oggi ci siano solo due sistemi che la usano: uno è il nostro portale Tolomeo fatto dal comune di Prato e dall’ ottimo Radaelli (che non a caso è un ingegnere elettronico) e l’altro è mapbox di geosolutions, che non a caso ha collaborato con Radaelli sul fronte geotools per implementargli le funzionalita’ mancanti per far funzionare VERAMENTE il client WFS e rendere possibile l’implementazione della ricerca via WFS. Andrea.
···
On 07/01/2014 09:47, Maurizio Napolitano wrote:
Ho letto e riletto la tua email e non mi trovo del tutto concorde.
Non tanto sulla questione WFS, ma proprio sul fatto di dare i dati
solo in WMS (che è quello che ho visto sul portale dei dati aperti
della Regione Toscana).
Il 07/01/2014 11:40, aperi2007 ha scritto:
On 07/01/2014 09:47, Maurizio Napolitano wrote:
Ho letto e riletto la tua email e non mi trovo del tutto concorde.
Non tanto sulla questione WFS, ma proprio sul fatto di dare i dati
*solo* in WMS (che è quello che ho visto sul portale dei dati aperti
della Regione Toscana).Ciao Maurizio,
probabilmente a causa dell'ora tarda ho scritto male.
Ma ho riletto anche io la mia email e non mi pareva di aver scritto che
i dati vanno veicolati SOLO in WMS.
Scusami, io facevo riferimento qui, dove vedo molti dati ma c'è la sola risorsa WMS
http://www.dati.toscana.it/group/territorio-ambiente
Tutto qui.
Alla luce di quello che dici suppongo che presto ci saranno anche i file .shp delle risorse wms.
ottimo
Ciao e scusami per eventuali incomprensioni.
On Tue, 07 Jan 2014 11:20:12 +0100, aperi2007 wrote:
E quindi se si parla di un sistema che deve funzionare davvero , per
distribuire i dati in OpenData, molto meglio degli zip con shapefile
preconfezionati.
mi permetterei di aggiungere anche qualche considerazione relativa
alle performances complessive delle piattaforme:
- download statico di shapefiles (o qualsiasi altro formato a
piacere: KML, GeoJSON, DXF etc): comunque si tratta di pacchetti
preconfezionati prodotti da qualche processo a monte.
e' ovvio che in questo caso il carico di CPU e' circa nullo
(tutte le eventuali elaborazioni sono gia' state effettuate
off-line in via preliminare una volta per tutte).
ergo: il collo di bottiglia consiste esclusivamente nella
banda passante a disposizione.
giusto in teoria dovremmo prendere in considerazione anche
il throughput reale del filesystem, ma dubito che possa
avere un grosso impatto (almeno su HW recente ben dimensionato)
- download dinamico "on demand": p.es. WMS / WFS
qua invece si impone un carico molto gravoso sulla CPU, visto che
ciascun singolo pacchetto va elaborato "al volo" a seconda delle
specifiche richieste dell'utete.
e potrebbero anche essere necessarie operazioni molto costose in
termini di risorse di calcolo (riproiezioni, tagli di precisione)
regola aurea della computer science: anche la CPU piu' veloce e'
sempre dannatamente troppo lenta 
in effetti, anche alla prova dei fatti, i servizi WMS / WFS
pur essendo splendidamente flessibili non brillano certo
come "cavalli da corsa"
conclusioni: mettere in piedi un server di download basato
su Open Data "statici" non solo e' piu' semplice, ma offre
anche maggiore robustezza ed affidabilita' ed e' in grado
di soddisfare un numero di richieste simultanee decisamente
piu' elevato a parita' di costi.
giusto per reminder: mi pare che il tema fosse stato sollevato
poco tempo fa da Steko per i servizi di download Regione Liguria.
molto spesso chi offre servizi "dinamici" poi si trova costretto
a dovere introdurre meccanismi volti a bilanciare ed ottimizzare
il carico di lavoro.
e spesso questo implica un ambaradan per nulla snello:
- devi essere un utente registrato
- sottoponi la tua richiesta
- che verra' processata in modo differito
- e dopo qualche ora/giorno ti arrivera' una e-mail con la
URL temporanea per il download dei dati esattamente come
li hai richiesti.
IMHO il sistema basato sul download statico di qualche SHP/ZIP
e' sicuramente preferibile anche dal punto di vista utente 
ciao Sandro
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 07/01/2014 12:02, a.furieri@lqt.it ha scritto:
IMHO il sistema basato sul download statico di qualche SHP/ZIP
e' sicuramente preferibile anche dal punto di vista utente
concordo pienamente. confesso che tutta questa storia degli open data mi pare a volte
una grandissima supercazzora[0] che potrebbe essere risolta con un sito di download,
come ai vecchi tempi, con in piu' giusto una licenza semplice e comprensibile.
meno male non sono solo a pensarla cosi'[1]..
saluti.
[0]http://it.wikipedia.org/wiki/Supercazzola
[1]http://blog.cleverelephant.ca/2012/12/whats-so-hard-about-that-download.html
- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlLL4AIACgkQ/NedwLUzIr5nVACgmIEk4DtcZLULdUqj2gZC2zkv
x98Anj59UoBQyYgUd05vl9LbFRXQX8h+
=vIjo
-----END PGP SIGNATURE-----
Condivido anch’io. Un repository “statico”, ben organizzato, per me resta imbattibile.
Le modalità di fruizione poi possono essere le più fantasiose, e anche la gestione a monte del dato “statico” può essere fatta a diversi livelli di complessità. Anche un repo github stile dati di Chicago può andar bene per certi usi (dati partecipati).
Questo non toglie nulla ai servizi tipo WFS. Come ha giustamente sottolineato Paolo Corti, tutto sta nel comprenderne potenzialità e usi opportuni. Un esempio banale è l’highlight geografico dei risultati di una ricerca…
giovanni
···
Il giorno 07 gennaio 2014 12:07, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Il 07/01/2014 12:02, a.furieri@lqt.it ha scritto:
IMHO il sistema basato sul download statico di qualche SHP/ZIP
e’ sicuramente preferibile anche dal punto di vista utenteconcordo pienamente. confesso che tutta questa storia degli open data mi pare a volte
una grandissima supercazzora[0] che potrebbe essere risolta con un sito di download,
come ai vecchi tempi, con in piu’ giusto una licenza semplice e comprensibile.
meno male non sono solo a pensarla cosi’[1]…
saluti.[0]http://it.wikipedia.org/wiki/Supercazzola
[1]http://blog.cleverelephant.ca/2012/12/whats-so-hard-about-that-download.html
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/iEYEARECAAYFAlLL4AIACgkQ/NedwLUzIr5nVACgmIEk4DtcZLULdUqj2gZC2zkv
x98Anj59UoBQyYgUd05vl9LbFRXQX8h+
=vIjo
-----END PGP SIGNATURE-----
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
–
Giovanni Allegri
http://about.me/giovanniallegri
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
L'unico che ha tentato di gestire questo problema in maniera seria e coscienziosa è Furieri, che dietro nostre istruzioni ha messo in piedi un sistemino che funziona.
Giustappunto, stavo vedendo, con il pannello "BLOB explorer" di SpatiaLite ( e con la funzione Sql AsGeoJSON ), che è possibile uscire in questo formato, molto adatto alla programmazione js.
Mi sono sempre domandato: perché non viene dimenticato l'inutilmente complicato XML e non viene adottato il GeoJSON, più efficiente, più leggibile, meno prolisso ?
Scateniamo una discussione in merito. Intanto metto l'elmetto
Ciao
Roberto
Ma anche quello funziona solo in casi molto sporadici.
Perhce' usa ilmetodo del paging che è un pagliativo informatico e non risolve un bel niente.
Perche' per avere un VERO download con WFS occorrerebbe effettuare il download sezionato per porzione di territorio.
Ovvero ritagliare lato client il territorio in griglie fitte, e scaricarle una per una, evitando di avere il clip sui bordi, altrimenti si introduce degli arrtotondamenti che
aleterano il dato e farebbero dire che cio' che si scarica non è il vero dataset, ma una sua versione approssimata.Ma anche ammesso che si riesca a mettere in piedi un sistema di questo genere , cosa di cui dubito fortemente.
Resterebbe intatto i due problemi principali.
Come fare a sapere se il download di una porzione di territorio è completo o e' troncato sul lmite massimo di features e come rimuovere eventuali doppioni che si formeebbero tra porzioni adiacenti di territorio.Ricevere dati in GML e doverli decodificare e rimuovere i doppioni.
Una cosa difficilissima.
E quindi se si parla di un sistema che deve funzionare davvero , per distribuire i dati in OpenData, molto meglio degli zip con shapefile preconfezionati.A.
On 07/01/2014 08:35, Geodrinx wrote:
Onestamente , io penso che il wfs non serva a niente dal punto di vista dello scarico dei dati.
Sembra solo una enorme perdita di tempo.Anch'io pensavo questo, finché non ho scoperto che WFS è scaricabile anche per finestre (BBOX), come il WMS.
Ancora non ho capito da quale versione minima del servizio WFS esiste questa funzione, ma essa esiste. Usandola, un client può caricarsi dinamicamente i dati vettoriali visibili in finestra, ed eventualmente (con WFS-T) anche modificarli.
Sbaglio ? Nel caso sia così, non prenderei troppo sotto-gamba il WFS...Ciao
Roberto
2014/1/7 Geodrinx <geodrinx@gmail.com>:
Mi sono sempre domandato: perché non viene dimenticato l'inutilmente complicato XML e non viene adottato il GeoJSON, più efficiente, più leggibile, meno prolisso ?
mah, geojson ha senso in certi contesti, gml in altri.
IMHO geojson (ma a sto punto meglio ancora topojson) è un ottimo modo
per trasformare una informazione precedentemente elaborata e validata
su una pagina web.
gml è un formato dati vero e proprio invece.
right tool for the right job.
Diego Guidi
On 07/01/2014 12:14, G. Allegri wrote:
Questo non toglie nulla ai servizi tipo WFS. Come ha giustamente sottolineato Paolo Corti, tutto sta nel comprenderne potenzialità e usi opportuni. Un esempio banale è l'highlight geografico dei risultati di una ricerca...
Lo so'.
Anche li' ci sarebbe da scrivere un trattato intero.
Con le distinzioni tra la ricerca e l'highlight in WFS e l'highlight in WMS.
Perche' anche con il WMS si puo' arrivare a ottenere un higlight dell'oggetto, basta sapere come fare.
Nel nostro Tolomeo abbiamo messo in piedi sia l'higlight sui risultati da ricerca su wfs, che l'ighlight da WMS.
Anxhe quest'ultimo da le sue soddisfazioni e ha il suo buon utilizzo per l'utente.
Ma vanno usati con prudenza e attenzione perche' sono radioattivi e possono scoppiare tra le mani...
A.
in INSPIRE (non si parla direttamente di WMS e WMF ma di view services e download services), per quanto mi ricordo (sono un po’ arrugginito e non del tutto aggiornato) ci sono due modalità di download services (che però sono obbligatori, cioè non basta che ci siano dei view services):
···
Ciao Andrea,
On 01/07/2014 11:40 AM, aperi2007 wrote:
Pero’ mi permetto di farti notare che la normativa Inspire di cui spesso vi riconducete per dare forza ai discorsi.
Promuove l’iteroperabilit’a come valore di per se’.Non sta scritto da nessuna parte che i dati se messi sul WMS devono obbligatoriamente essere anche scaricabili con il WFS.
- pre-defined dataset download service(s)
- direct access download service(s)
il primo riguarda dei dataset predefiniti, il secondo la possibilità di query per avere indietro degli spatial object specifici.
Il primo è obbligatorio e può essere implementato o attraverso ATOM o attraverso WFS; il secondo non è obbligatorio ma è da fare “where practicable” (va’ tu a capire quando lo è o no…) e si può fare con WFS (qui tutti i dettagli della Technical Guidance per l’implementazione dei Download Service di INSPIRE: http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf).
Aggiungo che servizi di accesso diretto sono molto utili quando si ha a che fare con dati di serie temporali, o dati di simulazioni che sia temporalmente sia spazialmente hanno range molto elevati. Ovviamente questo è molto più rilevante in caso di dati ambientali e/o di ricerca, rispetto a dati cartografici “classici”, però i casi d’uso sono molti e molto importanti (ad es. set di dati e simulazioni relativi ai cambiamenti climatici o alle condizioni degli oceani).
Per questo il WFS (o WCS) o, ancora meglio quando si tratta di dati da sensori, servizi SOS, sono molto molto importanti.
In vari casi e contesti probabilmente servizi per lo scaricamento di retto dei dati non è che non servano proprio a niente
Ale
--
Alessandro Sarretta
e-mail: [alessandro.sarretta@gmail.com](mailto:alessandro.sarretta@gmail.com)
skype: alesarrett
Web: [http://ilsarrett.wordpress.com](http://ilsarrett.wordpress.com)
Twitter: [https://twitter.com/alesarrett](https://twitter.com/alesarrett)
Google scholar: [http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ](http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ)
ORCID: [http://orcid.org/0000-0002-1475-8686](http://orcid.org/0000-0002-1475-8686)
ResearchGate: [https://www.researchgate.net/profile/Alessandro_Sarretta/](https://www.researchgate.net/profile/Alessandro_Sarretta/)
e l'altro è mapbox di geosolutions
Vuoi dire "MapStore" ...
Ciao
Roberto
On 07/01/2014 13:50, Geodrinx wrote:
e l'altro è mapbox di geosolutions
Vuoi dire "MapStore" ...
Ciao
Roberto
si, giusto.
grazie per la correzione.
A.
Ciao Alessandro,
Hai perfettamente ragione.
Il problema è che come al solito se non si chiariscono le condizioni al contorno, non si riesce mai a dipanare questa complessa equazione.
Ad esempio:
è lecito ritenere che Inspire tra le righe prescriva che un detemrinato dataset sia pubblicabile solo dall'ente che ne ha la titolarita' (o che ha stabilito opportuni e chari accordi con chi ne ha la titolarita, potendone chiundi fare le veci ) ?
Io penso di si', ma molti la pensano all'opposto.
E quindi probabilmente la risposta è negativa.
Ma cosi' viene meno uno dei pilastri portanti e tutta l'impalcatura traballa.
Perche' inspire motiva la nadcita dei suoi portlai per aver ela certezza di dove rintracciare detemrinti datasets, anziche' fare lo slalom tra miriadi di versioni spesso in conflitto tra di loro.
E parlo di dati non solo scaricabili, ma anche wms ovvero consultabili.
Ma su questo fronte di Inspire non è solo questo punto , uno dei punti tutt'ora irrisolti.
Ad esmepio , sarebbe interessante capire quanti tra quelli che dicono che inspire non prescrive l'obbligo che la pubblicazione sia diritoo /dovere di chi è titolare del dato, pensano pero' che solo chi è titolare del dato ha obblighi nei confronti di Inspire.
Oppure, altrettanto interessante sarebbe capire che differenza intercorre tra un "networkservice" di inspire e uno "spatial-data-service" sempre di inspire.
A quello che ho potuto capire dopo lunghe ricerche sono i medesimi servizi, ma proposti in salsa differente.
I network service sono dei servizi con il cosidetto "bollino di alta qualita'".
Che si raggiunge se è multilingua e se garantisce dei livelli di prestazioni superiori alla media. Per intendersi determinati tempi di risposta a fronte di determinate richieste concorrenti.
E qui per i servizi wfs la vedo dura.
Tante' che probabilmente per arrivarci con i normali sistemi wfs stile geoserver gia' citati, probabilnente l'unica strada è alleggerire i dati.
Basta mettere in gioco non i dati veri, ma versioni alleggerite, con meno vertici e meno precisione e i risultati in termkni prestazionali per il wfs si raggiungono.
Ma , correggimi se sbaglio, non è quesot che chiede inspire, non chiede dimettere dati alleggeriti pur di garantire determinate prestazioni.
E qui si ritorna a chi deve pubblicare cosa.
Ha senso che chiunque pubblichi qualiasi cosa, con il rischio di innescare degli equivoci legati al fatto che chi produce un dato ha interesse a mostrarlo nella sua interessa e pesantezza,
mentre chi lo ricicla per fare cartine , ha interesse alla prestazione intesa come massimo numero di utenti servizi , e quindi punta su alleggerimento e semplificazioni ?
E qui si vede come le due grandi questioni "Inspire" da una parte e "OpenData" dall'altra finiscono per danneggiarsi a vicenda,
perche' spinte dal medesimo spirito ,
provocano la nascita di situazioni in conflitto tra di loro.
Chi cerca di soddisfare Inspire cerca di mettere in piedi dei servizi che vadan sulla qualit'a , ma cosi' facendo perde il treno delle performances.
Chi soddisfa OpenData invece porta alla creazione di tanti portali che propongono i medesimi dati, senza alcun vincolo di mantenere la medesima qualita' .
Due mondi che alla fine finiranno per distruggersi a vicenda.
Ciao Andrea,
On 01/07/2014 11:40 AM, aperi2007 wrote:
Pero' mi permetto di farti notare che la normativa Inspire di cui spesso vi riconducete per dare forza ai discorsi.
Promuove l'iteroperabilit'a come valore di per se'.Non sta scritto da nessuna parte che i dati se messi sul WMS devono obbligatoriamente essere anche scaricabili con il WFS.
in INSPIRE (non si parla direttamente di WMS e WMF ma di view services e download services), per quanto mi ricordo (sono un po' arrugginito e non del tutto aggiornato) ci sono due modalità di download services (che però sono obbligatori, cioè non basta che ci siano dei view services):
* pre-defined dataset download service(s)
* direct access download service(s)il primo riguarda dei dataset predefiniti, il secondo la possibilità di query per avere indietro degli spatial object specifici.
Il primo è obbligatorio e può essere implementato o attraverso ATOM o attraverso WFS; il secondo non è obbligatorio ma è da fare "where practicable" (va' tu a capire quando lo è o no...) e si può fare con WFS (qui tutti i dettagli della Technical Guidance per l'implementazione dei Download Service di INSPIRE: http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf).Aggiungo che servizi di accesso diretto sono molto utili quando si ha a che fare con dati di serie temporali, o dati di simulazioni che sia temporalmente sia spazialmente hanno range molto elevati. Ovviamente questo è molto più rilevante in caso di dati ambientali e/o di ricerca, rispetto a dati cartografici "classici", però i casi d'uso sono molti e molto importanti (ad es. set di dati e simulazioni relativi ai cambiamenti climatici o alle condizioni degli oceani).
Per questo il WFS (o WCS) o, ancora meglio quando si tratta di dati da sensori, servizi SOS, sono molto molto importanti.
In vari casi e contesti probabilmente servizi per lo scaricamento di retto dei dati non è che non servano proprio a nienteAle
--
Alessandro Sarrettae-mail:alessandro.sarretta@gmail.com
skype: alesarrett
Web:http://ilsarrett.wordpress.com
Twitter:https://twitter.com/alesarrett
Google scholar:http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID:http://orcid.org/0000-0002-1475-8686
ResearchGate:https://www.researchgate.net/profile/Alessandro_Sarretta/_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013