[Gfoss] R: Re: inspire e mdb?

[Alessandro_Sarretta]

Confermo anch’io che INSPIRE non ha niente a che fare con il tipo o formato di DB usato. Non esiste alcun DB compliant o non compliant con INSPIRE.

Ale

----Messaggio originale----
Da: giohappy@gmail.com
Data: 20/01/2011 16.53
A: "Luca Morandini"luca.morandini1@gmail.com
Cc: "GFOSS.it"gfoss@lists.gfoss.it
Ogg: Re: [Gfoss] inspire e mdb?

Concordo pienamente con Luca.
Proprio in questo periodo sto lavorando su un sistema informativo scientifico (non posso dire di più) dove parte del lavoro consiste nel realizzare dei servizi di interoperabilità tra una serie di .mdb e un database PostGIS, in entrambi i quali sono è stato implementato il draft del modello INSPIRE specifico per quella tematica.
Non sono esperto degli aspetti giuridici di INSPIRE, ma sono piuttosto sicuro che la direttiva non indica niente in tema di implementazione fisica, ma solo i modelli dati e dei servizi di interoperabilità. Ogni stato membro, ente, ecc. che voglia o debba offrire i propri dati all’interno di una infrastruttura INSPIRE, può benissimo farlo a partire da un MDB… Anche perché sennò avrebbe avuto resistenze insormontabili ad essere recepito!

giovanni

Il giorno 20 gennaio 2011 16:37, Luca Morandini <luca.morandini1@gmail.com> ha scritto:

On 01/20/2011 03:37 PM, andrea antonello wrote:

Per quello sto tentando la via dello scalzamento del male alla radice.
L’mdb per dati geografici non ha senso con quello che c’e’ in giro.

Diciamo che ci sono delle alternative migliori… ma occorre anche vedere il contesto: se debbo interfacciare il sistema con sistemi ESRI, l’MDB potrebbe essere una cosa sensata.

Quello che trovo senza senso invece è il riferimento ad INSPIRE: questa iniziativa specifica interfacce, metadati e modelli di dati, non il DBMS da utilizzare, o, peggio, il suo formato dati (come l’MDB o il DBF).

Credo che, al limite, si potrebbe dire che uno specifico software che usa MDB come formato dati sia “compliant” con alcune specifiche di INSPIRE (magari i web services).

Già che ci siamo: a differenza di OGC, non mi risulta che INSPIRE abbia un programma di test e certificazione di prodotti e servizi, per cui è un po’ difficile dire che un prodotto “X” sia “INSPIRE compliant”.

Ciao,

Luca Morandini
http://www.lucamorandini.it

–
Regards,

Luca Morandini
http://www.lucamorandini.it

---

Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
485 iscritti al 20.11.2010

[moovida]

Scusate, sono tornato online solo ora.
Grazie dei molti contributi.

Credo di essermi spiegato male all'inizio.
Sono sicuro che non sia possibile che MDB sia in qualche modo legato
allo standard inspire e che inspire non definisca un database.
Quello che vorrei (e che non sono sicuro di riuscire, per quello
chiedevo link a documentazione) io e' dimostrare l'opposto, cioe' che
mdb non e' compatibile con standard inspire perche' a) non standard b)
non open. Il problema e' che non conosco le direttive abbastanza bene
per sapere dove trovare questa dimostrazione.
Essendo richiesto dal progetto, credo, con i mezzi giusti, di poter
costringere i partner mdb-addicted a cambiare formato.

Mi pare di capire dai vostri contributi che e' una cosa impossibile e
che nel momento in cui loro hanno messo i metadati (etc etc) giusti,
avrebbero anche potuto mettere il tutto su dei fogliettini in una
latta dei pelati. E quindi non ho modo di cambiare le cose.
Giusto?

Grazie,
Andrea

PS: mi e' stato riferito che si tratta di un "esri personal db, però
compatibile solo con arcgis 9.1". Qualcuno ha idea se le gdal lo
leggono?

2011/1/20 alessandro.sarretta@inwind.it <alessandro.sarretta@inwind.it>:

Confermo anch'io che INSPIRE non ha niente a che fare con il tipo o formato
di DB usato. Non esiste alcun DB compliant o non compliant con INSPIRE.

Ale

----Messaggio originale----
Da: giohappy@gmail.com
Data: 20/01/2011 16.53
A: "Luca Morandini"<luca.morandini1@gmail.com>
Cc: "GFOSS.it"<gfoss@lists.gfoss.it>
Ogg: Re: [Gfoss] inspire e mdb?

Concordo pienamente con Luca.
Proprio in questo periodo sto lavorando su un sistema informativo
scientifico (non posso dire di più) dove parte del lavoro consiste nel
realizzare dei servizi di interoperabilità tra una serie di .mdb e un
database PostGIS, in entrambi i quali sono è stato implementato il draft del
modello INSPIRE specifico per quella tematica.
Non sono esperto degli aspetti giuridici di INSPIRE, ma sono piuttosto
sicuro che la direttiva non indica niente in tema di implementazione fisica,
ma solo i modelli dati e dei servizi di interoperabilità. Ogni stato membro,
ente, ecc. che voglia o debba offrire i propri dati all'interno di una
infrastruttura INSPIRE, può benissimo farlo a partire da un MDB... Anche
perché sennò avrebbe avuto resistenze insormontabili ad essere recepito!
giovanni
Il giorno 20 gennaio 2011 16:37, Luca Morandini <luca.morandini1@gmail.com>
ha scritto:

On 01/20/2011 03:37 PM, andrea antonello wrote:

Per quello sto tentando la via dello scalzamento del male alla radice.
L'mdb per dati geografici non ha senso con quello che c'e' in giro.

Diciamo che ci sono delle alternative migliori... ma occorre anche vedere
il contesto: se debbo interfacciare il sistema con sistemi ESRI, l'MDB
potrebbe essere una cosa sensata.

Quello che trovo senza senso invece è il riferimento ad INSPIRE: questa
iniziativa specifica interfacce, metadati e modelli di dati, non il DBMS da
utilizzare, o, peggio, il suo formato dati (come l'MDB o il DBF).

Credo che, al limite, si potrebbe dire che uno specifico software che usa
MDB come formato dati sia "compliant" con alcune specifiche di INSPIRE
(magari i web services).

Già che ci siamo: a differenza di OGC, non mi risulta che INSPIRE abbia un
programma di test e certificazione di prodotti e servizi, per cui è un po'
difficile dire che un prodotto "X" sia "INSPIRE compliant".

Ciao,

Luca Morandini
http://www.lucamorandini.it

--
Regards,

Luca Morandini
http://www.lucamorandini.it
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
485 iscritti al 20.11.2010

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
485 iscritti al 20.11.2010

[Paolo_Corti]

Ciao Andrea

Mi pare di capire dai vostri contributi che e' una cosa impossibile e
che nel momento in cui loro hanno messo i metadati (etc etc) giusti,
avrebbero anche potuto mettere il tutto su dei fogliettini in una
latta dei pelati. E quindi non ho modo di cambiare le cose.
Giusto?

assolutamente si, come hanno spiegato in maniera egregia Luca e gli altri

PS: mi e' stato riferito che si tratta di un "esri personal db, però
compatibile solo con arcgis 9.1". Qualcuno ha idea se le gdal lo
leggono?

GDAL (via OGR), come scritto da Antonio, legge solo il dato.
Ovviamente parliamo sia delle utility che dell'API (e quindi anche
Java nel tuo caso).
Trattasi pero' IMHO di un terreno abbastanza inesplorato
(principalmente perche' gli sviluppatori non possono accedere a
licenze da sviluppatore di Esri, che sono a pagamento), quindi ti
conviene fare qualche verifica pesante prima di prendere cio' come
assodato.

Viceversa se devi scrivere sarai vincolato a sviluppare il tuo
software in .NET o Java e ArcObjects (almeno fino a poco tempo fa era
cosi, sicuramente lo era alla 9.1), ma per farlo ti serve una licenza,
sia per sviluppare sia per distribuire (quella di ArcView ti dovrebbe
bastare).
Discorso diverso per quanto riguarda il file GDB (che comunque mi
sembra ci sia solo dalla 9.3), sempre di Esri (la risposta commerciale
a SpatiaLite ), per il quale e' stata rilasciata un API liberamente
distribuibile (solo da ArcGis 10 in poi) che pero' e' utilizzabile
sono in C++ (da quanto ricordo) e che presenta varie limitazioni
rispetto all'utilizzo degli ArcObjects (ad es non supporta annotation
e topologia).

Per riepilogare: l'API Java di GDAL/OGR fa al tuo caso, tra l'altro la
sto usando in maniera estensiva proprio in questi giorni per un
progetto in Java (in genere uso quella Python, ma e' del tutto
simile), quindi se hai bisogno di qualche consiglio fammi sapere, ma
non penso proprio che avrai difficolta'

Come prima prova ti suggerisco di usare ogr2ogr per esportare il GDB
verso il formato open da te scelto, ad es SpatiaLite lo vedo
benissimo: se l'esportazione ti funziona senza problemi, anche da API
non dovresti avere problemi in quanto lo stesso ogr2ogr si basa sulla
stessa API.
Potresti addirittura usare la versione ogr2ogr che esiste per Java [0]
(principalmente e' stata inserita in SVN a titolo di esempio,
piuttosto che come tool di reale utilizzo, infatti non e' mai
allineata al 100% con il ogr2ogr in C++ che tutti noi abbiamo usato
almeno una volta),: cosi ti fai anche un'idea di come usare l'API

ciao
P

[0] http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogr2ogr.java

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @paolo_corti

[giohappy]

Non so come è formalizzato il contratto col tuo cliente, comunque prossimamente dovrò lavorare su un GDB di un mio cliente (per una utility in C#), e in questo caso ho espressamente chiesto che il cliente mi permettesse di poter sviluppare utilizzando la sua licenza ArcMap (gli ArcObjects, se non erro, vengono distribuiti anche con ArcView), non per sviluppare tramite l’SDK Esri ma per poter compilare le GDAL 1.8 lincandole agli ArcObjects [1]. Non so da quando è stata aggiunta questa opzione nella configurazione, io me ne sono accorto solo poco tempo fa.

giovanni

[1] http://trac.osgeo.org/gdal/browser/trunk/gdal/nmake.opt#L375

Il giorno 20 gennaio 2011 18:30, Paolo Corti <pcorti@gmail.com> ha scritto:

Ciao Andrea

Mi pare di capire dai vostri contributi che e’ una cosa impossibile e
che nel momento in cui loro hanno messo i metadati (etc etc) giusti,
avrebbero anche potuto mettere il tutto su dei fogliettini in una
latta dei pelati. E quindi non ho modo di cambiare le cose.
Giusto?

assolutamente si, come hanno spiegato in maniera egregia Luca e gli altri

PS: mi e’ stato riferito che si tratta di un “esri personal db, però
compatibile solo con arcgis 9.1”. Qualcuno ha idea se le gdal lo
leggono?

GDAL (via OGR), come scritto da Antonio, legge solo il dato.
Ovviamente parliamo sia delle utility che dell’API (e quindi anche
Java nel tuo caso).
Trattasi pero’ IMHO di un terreno abbastanza inesplorato
(principalmente perche’ gli sviluppatori non possono accedere a
licenze da sviluppatore di Esri, che sono a pagamento), quindi ti
conviene fare qualche verifica pesante prima di prendere cio’ come
assodato.

Viceversa se devi scrivere sarai vincolato a sviluppare il tuo
software in .NET o Java e ArcObjects (almeno fino a poco tempo fa era
cosi, sicuramente lo era alla 9.1), ma per farlo ti serve una licenza,
sia per sviluppare sia per distribuire (quella di ArcView ti dovrebbe
bastare).
Discorso diverso per quanto riguarda il file GDB (che comunque mi
sembra ci sia solo dalla 9.3), sempre di Esri (la risposta commerciale
a SpatiaLite ), per il quale e’ stata rilasciata un API liberamente
distribuibile (solo da ArcGis 10 in poi) che pero’ e’ utilizzabile
sono in C++ (da quanto ricordo) e che presenta varie limitazioni
rispetto all’utilizzo degli ArcObjects (ad es non supporta annotation
e topologia).

Per riepilogare: l’API Java di GDAL/OGR fa al tuo caso, tra l’altro la
sto usando in maniera estensiva proprio in questi giorni per un
progetto in Java (in genere uso quella Python, ma e’ del tutto
simile), quindi se hai bisogno di qualche consiglio fammi sapere, ma
non penso proprio che avrai difficolta’

Come prima prova ti suggerisco di usare ogr2ogr per esportare il GDB
verso il formato open da te scelto, ad es SpatiaLite lo vedo
benissimo: se l’esportazione ti funziona senza problemi, anche da API
non dovresti avere problemi in quanto lo stesso ogr2ogr si basa sulla
stessa API.
Potresti addirittura usare la versione ogr2ogr che esiste per Java [0]
(principalmente e’ stata inserita in SVN a titolo di esempio,
piuttosto che come tool di reale utilizzo, infatti non e’ mai
allineata al 100% con il ogr2ogr in C++ che tutti noi abbiamo usato
almeno una volta),: cosi ti fai anche un’idea di come usare l’API

ciao
P

[0] http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogr2ogr.java

–
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @paolo_corti

---

Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
485 iscritti al 20.11.2010

[moovida]

Paolo, che dire... outstanding!
Grazie dell'ottimo riassunto.

Ciao
Andrea

2011/1/20 Paolo Corti <pcorti@gmail.com>:

Ciao Andrea

Mi pare di capire dai vostri contributi che e' una cosa impossibile e
che nel momento in cui loro hanno messo i metadati (etc etc) giusti,
avrebbero anche potuto mettere il tutto su dei fogliettini in una
latta dei pelati. E quindi non ho modo di cambiare le cose.
Giusto?

assolutamente si, come hanno spiegato in maniera egregia Luca e gli altri

PS: mi e' stato riferito che si tratta di un "esri personal db, però
compatibile solo con arcgis 9.1". Qualcuno ha idea se le gdal lo
leggono?

GDAL (via OGR), come scritto da Antonio, legge solo il dato.
Ovviamente parliamo sia delle utility che dell'API (e quindi anche
Java nel tuo caso).
Trattasi pero' IMHO di un terreno abbastanza inesplorato
(principalmente perche' gli sviluppatori non possono accedere a
licenze da sviluppatore di Esri, che sono a pagamento), quindi ti
conviene fare qualche verifica pesante prima di prendere cio' come
assodato.

Viceversa se devi scrivere sarai vincolato a sviluppare il tuo
software in .NET o Java e ArcObjects (almeno fino a poco tempo fa era
cosi, sicuramente lo era alla 9.1), ma per farlo ti serve una licenza,
sia per sviluppare sia per distribuire (quella di ArcView ti dovrebbe
bastare).
Discorso diverso per quanto riguarda il file GDB (che comunque mi
sembra ci sia solo dalla 9.3), sempre di Esri (la risposta commerciale
a SpatiaLite ), per il quale e' stata rilasciata un API liberamente
distribuibile (solo da ArcGis 10 in poi) che pero' e' utilizzabile
sono in C++ (da quanto ricordo) e che presenta varie limitazioni
rispetto all'utilizzo degli ArcObjects (ad es non supporta annotation
e topologia).

Per riepilogare: l'API Java di GDAL/OGR fa al tuo caso, tra l'altro la
sto usando in maniera estensiva proprio in questi giorni per un
progetto in Java (in genere uso quella Python, ma e' del tutto
simile), quindi se hai bisogno di qualche consiglio fammi sapere, ma
non penso proprio che avrai difficolta'

Come prima prova ti suggerisco di usare ogr2ogr per esportare il GDB
verso il formato open da te scelto, ad es SpatiaLite lo vedo
benissimo: se l'esportazione ti funziona senza problemi, anche da API
non dovresti avere problemi in quanto lo stesso ogr2ogr si basa sulla
stessa API.
Potresti addirittura usare la versione ogr2ogr che esiste per Java [0]
(principalmente e' stata inserita in SVN a titolo di esempio,
piuttosto che come tool di reale utilizzo, infatti non e' mai
allineata al 100% con il ogr2ogr in C++ che tutti noi abbiamo usato
almeno una volta),: cosi ti fai anche un'idea di come usare l'API

ciao
P

[0] http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/ogr2ogr.java

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @paolo_corti

[Paolo_Corti]

Ciao Giovanni

Non so come è formalizzato il contratto col tuo cliente, comunque
prossimamente dovrò lavorare su un GDB di un mio cliente (per una utility in
C#), e in questo caso ho espressamente chiesto che il cliente mi permettesse
di poter sviluppare utilizzando la sua licenza ArcMap (gli ArcObjects, se
non erro, vengono distribuiti anche con ArcView), non per sviluppare tramite
l'SDK Esri ma per poter compilare le GDAL 1.8 lincandole agli ArcObjects
[1]. Non so da quando è stata aggiunta questa opzione nella configurazione,
io me ne sono accorto solo poco tempo fa.

non sto seguendo progetti con ArcGis/ArcObjects al momento, mi
riferivo in realta' agli sviluppatori di GDAL, che molto spesso non
hanno accesso alle ultime versioni di ArcGis (anche la licenza da
sviluppatore va acquistata).
Per quanto riguarda il driver ArcObjects, per me e' una novita'
assoluta e credo sia stato inserito da poco su GDAL. In effetti come
fai notare richiede la licenza ArcObjects anche solo per compilare
GDAL per avere il supporto di questo driver.
Io in realta' mi riferivo al driver PGEO [0], che esiste in GDAL da
diversi anni, e che puo' essere utilizzato anche senza avere una
licenza ArcObjects.
Il driver ArcObjects sembra supportare Personal ed enterprise GDB e
file GDB (anche qui in sola lettura), ed alcune feature del modello
GDB (topologia, annotazioni ecc....). Sarebbe interessante sentire il
parere di qualcuno che l'ha gia' utilizzato.
Il PGEO viceversa e' utilizzabile solo per Personal GDB, in sola
lettura, e da accesso alle sole peculiarita' del Simple Feature Access
di OGC (quindi no topologia, annotazioni ecc...).
Credo che per la maggior parte degli use case, PGEO faccia bene il suo
compito, ad ogni modo dipende dal tipo di GDB che Andrea deve trattare
la scelta dell'uno o dell'altro.

ciao
P

[0] http://www.gdal.org/ogr/drv_pgeo.html

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @paolo_corti