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.sile...@regione.piemonte.it
<mailto:gianbartolomeo.sile...@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@lists.gfoss.it <mailto: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.
657 iscritti al 30.5.2013
_______________________________________________
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.
657 iscritti al 30.5.2013
_______________________________________________
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.
657 iscritti al 30.5.2013
