2014/1/7 Geodrinx :
>
> Domanda da ignorante (io): il servizio di edit di OpenStreetMap ( quello che
> utilizza l'editor integrato ID , per intenderci ), utilizza un WFS-T ?
>
> Oppure, come è realizzato ?
>
sono delle API, ci sono diversi strumenti per interrogarle...
consiglio overpass-api e
Ad essere sinceri la segnalazione dei WMS (n.b. non sono segnalati i
WFS che per certi aspetti sono piu' interessanti in quanto possono
essere utilizzati come DB remoti su cui operare query per alimentare
list-box o per fare ricerche e potenzialmente strategici per favorire
interoperabilita' tra ar
strk,
grazie della segnalazione.
Non me lo sarei mai aspettato.
Il giorno 07 gennaio 2014 19:52, Sandro Santilli ha
scritto:
> On Sat, Jan 04, 2014 at 05:35:24PM +0100, Maurizio Trevisani wrote:
>
> > segnalo la pagina
> > http://www.regione.toscana.it/-/open-source
>
> Ciao Maurizio, ottima
On Sat, Jan 04, 2014 at 05:35:24PM +0100, Maurizio Trevisani wrote:
> segnalo la pagina
> http://www.regione.toscana.it/-/open-source
Ciao Maurizio, ottima iniziativa !
Mi permetto di segnalare che il sito ufficiale del progetto
PostGIS e' ora http://postgis.net, non piu' postgis.org.
Grazie
--
>
>
> Domanda da ignorante (io): il servizio di edit di OpenStreetMap ( quello
> che utilizza l'editor integrato ID , per intenderci ), utilizza un WFS-T ?
>
> Oppure, come è realizzato ?
>
OT: iD va a scrivere tramite le API di OSM (attualmente v 0.6):
http://wiki.openstreetmap.org/wiki/API_v0.6
L'editing è una storia diversa.
DI per se l'editing non è necessariamente cosi' pesante.
Dipende dal dietro le quinte, ma da quello che leggo indirettamente,
ovvero del fatto che in OSM ci possono essere parecchie fetures errate e
le FK non sempre tornano, direi che il sistema di editing è del t
> per arrivarci con i normali sistemi wfs stile geoserver gia' citati,
> probabilnente l'unica strada è alleggerire i dati.
Dico un'eresia: ma non é che il problema di cui parliamo ( inefficienza?
Altro? ) dipende invece magari da qualche scelta progettuale o tecnologica ?
Non parlo ovviame
> determinati tempi di risposta a fronte di determinate richieste concorrenti.
> E qui per i servizi wfs la vedo dura.
Caspita. Sei scottato dai servizi WFS :)
Domanda da ignorante (io): il servizio di edit di OpenStreetMap ( quello che
utilizza l'editor integrato ID , per intenderci ), utiliz
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
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.
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una
> e l'altro è mapbox di geosolutions
Vuoi dire "MapStore" ...
:)
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 hann
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
obb
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
2014/1/7 Geodrinx :
> 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
>
> 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 è
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ò anda
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 07/01/2014 12:02, a.furi...@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
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 c
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
d
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,
pr
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 i
2014/1/7 cesare gerbino :
> 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
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
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
> 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 mini
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?
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.toscan
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
___
Gfoss@lis
28 matches
Mail list logo
