[Gfoss] alcune indicazioni: ex INSPIRE: stato dell'arte?

Gio 11 Lug 2013 14:36:40 CEST

Ottimo Andrea, si comincia a parlare di cose concrete in termini di
"mapping" e "trasformazione".
Ora, indipendentemente dalle tecnologie usate (script spatiaLite o
procedure analoghe in PostGIS, oppure tool vari di mapping e schema
transformation [vedi anche [1]]) che si useranno per ottenere dati
"Inspire-compliant" (nell'esempio AdministrativeUnit,
AdministrativeBoundary, Condominium e NUTSRegion), bisogna capire come ci
si vuole organizzare per:

0) mappare lo schema "NationalCore" definito per i dbTopografici con gli
applicationSchema INSPIRE, non solo a livello di classi (facile) ma anche
di attributi, codelist e relativi valori [1]

1) armonizzare i dati dal punto di vista topologico (escludo che i dati in
possesso di RT siano perfettamente allineati con quelli di RER, Liguria,
 Lazio, Umbria e Marche)

2) risolvere i problemi al confine (gap, overlap) sia dal punto di vista
tecnico/cartografico che istituzionale (chi decide che un confine passa qui
e non li'?) [2]

3) mettere a disposizione servizi di view e download (facendo un cascading
di WFS distribuiti? o creando una copia centralizzata di tutti i dati, come
stanno facendo le 12 Province olandesi [3])

4) catalogare i rispettivi metadati, in cataloghi locali/regionali e
nazionali, evitando loop (nel caso di harvesting) e sovrapposizioni

[1] Prototype Report for the INSPIRE Schema Transformation Network Service,
2010,
http://inspire.jrc.ec.europa.eu/documents/Network_Services/JRC_INSPIRE-TransformService_ProtoRpt_v3-0.pdf

[2] http://inspire.ec.europa.eu/registry/

[3] in merito a chi-fa-cosa suil tema "AdministrativeUnit" non dobbiamo
dimenticare ... l'AdT

[4] Going Dutch: Provinces Implement INSPIRE Together Lessons Learned From
Annex I & A INSPIRE Compliant Nature SDI, INSPIRE Conference 2013:
"The use of a specific (topographic) type of administrative boundaries are
obligatory in some Dutch information models (i.e. IMRO for spatial
planning, IMNA for nature conservation). The boundaries, at this moment,
differ from the Dutch INSPIRE administrative boundaries: overlaps and holes
do occur along provincial and national boundaries because of these
differences."

pg

p.s. oggi i server JRC sono in manutenzione, quindi i link indicati sopra
non sono accessibili

pg

______________________________
Piergiorgio Cipriano
@PgCipriano

Il giorno 11 luglio 2013 13:19, aperi2007 <aperi2007 a gmail.com> ha scritto:

>
> scusate se approfitto,
> ma proprio perche' questa è una cosa che si dovrà fare,
>
> non mi dispiacerebbe avere un parere in merito alle corrispondenze:
> Noi abbiamo i nostri confini multiscala organizzati sia su archivi lineari
> per ospitare gli attributi a tratti (che come sapete servono sui confini).
> Poi ci sono gli archivi poligonali che ospitano i poligoni semplici e poi
> le aggregazioni (regions) che servono per delinera interamente l'area del
> comune a fini di elaborazione spaziale.
>
> Per cui alla fine queste sono gli archivi che abbiamo.
> Ce ne sarebbero altri , ma direi che gia' questo elenco rappresenta un
> buon banco di prova.
>
> Di seguito riporto l'elenco delle nostre coperture.
> (Tutte scaricabili con licenza CC-BY dalla nostra cartoteca.)
> E quella che a mio modesto e indegno parere dovrebbe essere la sua
> corrispondenza con le 4 stratificazioni di Inspire.
>
> Mi farebbe piacere avere alcuni pareri in merito.
>
> confine regionale areale poligoni --> Administrative unit
> confine regionale areale aggregato --> Administrative unit
> confine regionale lineare --> Administrative Boundary
>
> confine provinciale areale poligoni --> Administrative unit
> confine provinciale areale aggregato --> Administrative unit
> confine provinciale lineare --> Administrative Boundary
>
> confine comunale areale poligoni --> Administrative unit
> confine comunale areale aggegato --> Administrative unit
> confine comunale lineare --> Administrative Boundary
>
> confine di circondario areale poligoni -> Administrative unit
> confine di circondario areale aggregato -> Administrative unit
> confine di circondario lineare -> Administrative Boundary
>
> confine di area metropolitana areale poligoni -> Administrative unit
> confine di area metropolitana areale aggregato -> Administrative unit
> confine di area metropolitana areale -> Administrative Boundary
>
> confine di unione di comuni areale poligoni --> Administrative unit
> confine di unione di comuni areale aggregato --> Administrative unit
> confine di unione di comuni lineare --> Administrative Boundary
>
> Mi farebbe estremamente comodo conoscere altre opinioni n mertio a come
> queste coperture si rimappano sulle 4 elencate:
>
> Approfitto per tranquillizzare che come noi sciuramente tutte le regioni
> si stanno attrezzando, ognuna con i propri mezzi per fr fronte alle
> esigenze di esportazione.
>
> Esemplifico descrivendo la procedura di esportazione che il sottoscritto
> adotta per esportare il nostro dbtopografico in shapefiledi oggetti con
> geometria.
>
> Il lavoro di conversione verrà effettuato dal sottoscritto mediante una
> serie di scripts in spatialite che molto agilmente riportano da una
> mappatura all'altra.
>
> Per questo tipo di attività è molto utile spatialite, molto piu' di altri
> strumenti che non sono tarati per grandi moli di dati e quindi funzionano
> bene quando
> si fanno delle presentazioni dove il tutto è tagliato su misura mentre
> funzionano maluccio in contesti dove le casistiche aumentano e le moli di
> dati sono su
> altri livelli.
>
> attualente noi abbiamo un DBT topografico su specifiche nostre interne che
> è assolutamente topologico , ma che proprio per questo ha la geometria
> concentrata su poche classi
> e tutte le altre classi sono semplici tabelle che rimandano a tali classi
> principali per la parte geometrica.
> Ci sono classi con geometria 2D e classi con geometria 3D e classi in cui
> la parte 3D è demandata ad attributi del record.
> E alcune classi hanno attributi multivalori che quindi sono collocati su
> tabelle di appoggio per le quali abbiamo seguito le specifiche fornite
> dalle sperimentazioni del CISIS-CPSG.
>
> Il db topografico di tutta la regione toscana multiscala (10k con zone 2k)
> occupa complessivamente un db spatialite di circa 18 Gbyte.
>
> Con una procedura script riusciamo a ricostruire le geometrie addirittura
> portando le geometrie a 3D sfruttando le quote sugli attributi,
> ricostruendo le geometrie
> intere degli oggetti aggregati e tagliando il tutto sulle sezioni di
> CTR10K e infine esportando su shapefile.
>
> Il tutto in automatico.
> La procedura per giunta corregge anche le geometrie invalide che si
> generano durante le procedure di intersezione o unino tra i vari oggetti e
> snappa il tutto alla seconda cifra decimale (per accontentare i
> cartografi).
> E infine esporta in tanti shapefile uno per ogni classe  e per ogni
> sezione.
>
> La produzione completa del db topografico in shapefile tagliati in questo
> modo su sezioni di ctr10k corrisponde sostanzialmente a produrre circa 730
> cartelle
> di una ottantina di shapefile ciascuna ogni cartella è una sezione di
> ctr10k.
>
> Il tutto richiede poco piu' di 24 ore.
>
> Mica malaccio. :)
>
>
> Grazie.
>
>
>
> On 11/07/2013 09:14, Piergiorgio Cipriano wrote:
>
>  Forse la faccio troppo facile ... ma forse si dovrebbe iniziare a fare
> chiarezza definendo, tema per tema (o meglio featureType per featureType)
> "chi" mette a disposizione i dati "verso" INSPIRE, e di conseguenza con
> quali modalita' (organizzative e tecnologiche).
> Un esempio facile facile (?) tanto per andare nel concreto e non parlare
> sempre di sesso degli angeli.
>  Il tema "Administrative Units" prevede 4 classi FeatureType [1]:
> - AdministrativeUnit
> - AdministrativeBoundary
> - Condominium
> - NUTSRegion
>
>  A chi spetta/era' mettere a disposizione una copertura nazionale
> (armonizzata, e anche dal punto di vista topologico) di queste 4 semplici
> classi, conformi alle data specs Inspire "AU"?
> A ciascuna Regione?
> A ISTAT?
>  A IGM?
> Al MinAmbiente?
> A qualche altro Ministero?
>
>  Nel primo caso (19 Regioni + 2 Province Autonome) in che modo mettere
> dati (armonizzati) e relativi metadati?
>
>   Ora, tornando alla questione metadati, se si decidesse una volta per
> tutte "chi si occupa di cosa" a livello di tema o di singola featureType,
> forse (e sottolineo forse) sarebbe piu' semplice immaginare uno scenario
> concreto anche per metadati e relativi cataloghi.
>
>  ... e se si organizzasse un bel webinar a settembre/ottobre (not another
> conference, please!!) e si iniziasse seriamente a fare la "lista della
> spesa"?
>
>
>  [1]
> http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_v3.0.1.pdf Fig.2,
> pag. 18
>
>
>  pg
>
>
>
>
>  pg
>
> ______________________________
> Piergiorgio Cipriano
> @PgCipriano
>
>
>
> Il giorno 11 luglio 2013 08:31, gianni siletto <
> gianbartolomeo.siletto a regione.piemonte.it> ha scritto:
>
>> rndt wrote
>> > Ciao Piergiorgio.
>> > Il problema è proprio che in Italia si stanno tentando di fare solo
>> > doppioni (diversi cataloghi che, almeno in base all'impostazione,
>> > conterranno le stesse informazioni) e quindi non avrebbe senso avere
>> tanti
>>  > cataloghi nazionali registrati al geoportale INSPIRE.
>> ...................
>> > .........
>> > Saluti,
>> > Antonio Rotundo
>>
>> Proprio questo è quanto mi è sembrato apparire evidente nelle
>> comunicazioni
>> che ho sentito a Firenze, e che mi pare debba essere evitato. Purtroppo ad
>> oggi su questi temi non c'è chiarezza, e finalmente almeno qui se ne
>> parla!!
>> ciao,
>> Gianni
>>
>>
>>
>> --
>> View this message in context:
>> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/INSPIRE-stato-dell-arte-tp7582934p7582971.html
>>  Sent from the Gfoss -- Geographic Free and Open Source Software -
>> Italian mailing list mailing list archive at Nabble.com.
>> _______________________________________________
>> Gfoss a 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.
>> 657 iscritti al 30.5.2013
>>
>
>
>
> _______________________________________________Gfoss a lists.gfoss.ithttp://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.
> 657 iscritti al 30.5.2013
>
>
>
> _______________________________________________
> Gfoss a 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.
> 657 iscritti al 30.5.2013
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130711/bdb1e96b/attachment-0001.html>