<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
scusate se approfitto,<br>
ma proprio perche' questa è una cosa che si dovrà fare,<br>
<br>
non mi dispiacerebbe avere un parere in merito alle
corrispondenze:<br>
Noi abbiamo i nostri confini multiscala organizzati sia su archivi
lineari per ospitare gli attributi a tratti (che come sapete
servono sui confini).<br>
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.<br>
<br>
Per cui alla fine queste sono gli archivi che abbiamo.<br>
Ce ne sarebbero altri , ma direi che gia' questo elenco
rappresenta un buon banco di prova.<br>
<br>
Di seguito riporto l'elenco delle nostre coperture.<br>
(Tutte scaricabili con licenza CC-BY dalla nostra cartoteca.)<br>
E quella che a mio modesto e indegno parere dovrebbe essere la sua
corrispondenza con le 4 stratificazioni di Inspire.<br>
<br>
Mi farebbe piacere avere alcuni pareri in merito.<br>
<br>
confine regionale areale poligoni --> Administrative unit<br>
confine regionale areale aggregato --> Administrative unit<br>
confine regionale lineare --> Administrative Boundary<br>
<br>
confine provinciale areale poligoni --> Administrative unit<br>
confine provinciale areale aggregato --> Administrative unit<br>
confine provinciale lineare --> Administrative Boundary<br>
<br>
confine comunale areale poligoni --> Administrative unit<br>
confine comunale areale aggegato --> Administrative unit<br>
confine comunale lineare --> Administrative Boundary<br>
<br>
confine di circondario areale poligoni -> Administrative unit<br>
confine di circondario areale aggregato -> Administrative unit<br>
confine di circondario lineare -> Administrative Boundary<br>
<br>
confine di area metropolitana areale poligoni -> Administrative
unit<br>
confine di area metropolitana areale aggregato ->
Administrative unit<br>
confine di area metropolitana areale -> Administrative Boundary<br>
<br>
confine di unione di comuni areale poligoni --> Administrative
unit<br>
confine di unione di comuni areale aggregato --> Administrative
unit<br>
confine di unione di comuni lineare --> Administrative Boundary<br>
<br>
Mi farebbe estremamente comodo conoscere altre opinioni n mertio a
come queste coperture si rimappano sulle 4 elencate:<br>
<br>
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.<br>
<br>
Esemplifico descrivendo la procedura di esportazione che il
sottoscritto adotta per esportare il nostro dbtopografico in
shapefiledi oggetti con geometria.<br>
<br>
Il lavoro di conversione verrà effettuato dal sottoscritto
mediante una serie di scripts in spatialite che molto agilmente
riportano da una mappatura all'altra.<br>
<br>
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 <br>
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 <br>
altri livelli.<br>
<br>
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 <br>
e tutte le altre classi sono semplici tabelle che rimandano a tali
classi principali per la parte geometrica.<br>
Ci sono classi con geometria 2D e classi con geometria 3D e classi
in cui la parte 3D è demandata ad attributi del record.<br>
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.<br>
<br>
Il db topografico di tutta la regione toscana multiscala (10k con
zone 2k) occupa complessivamente un db spatialite di circa 18
Gbyte.<br>
<br>
Con una procedura script riusciamo a ricostruire le geometrie
addirittura portando le geometrie a 3D sfruttando le quote sugli
attributi, ricostruendo le geometrie <br>
intere degli oggetti aggregati e tagliando il tutto sulle sezioni
di CTR10K e infine esportando su shapefile.<br>
<br>
Il tutto in automatico.<br>
La procedura per giunta corregge anche le geometrie invalide che
si generano durante le procedure di intersezione o unino tra i
vari oggetti e <br>
snappa il tutto alla seconda cifra decimale (per accontentare i
cartografi).<br>
E infine esporta in tanti shapefile uno per ogni classe e per
ogni sezione.<br>
<br>
La produzione completa del db topografico in shapefile tagliati in
questo modo su sezioni di ctr10k corrisponde sostanzialmente a
produrre circa 730 cartelle<br>
di una ottantina di shapefile ciascuna ogni cartella è una sezione
di ctr10k.<br>
<br>
Il tutto richiede poco piu' di 24 ore.<br>
<br>
Mica malaccio. :)<br>
<br>
<br>
Grazie.<br>
<br>
<br>
<br>
On 11/07/2013 09:14, Piergiorgio Cipriano wrote:<br>
</div>
<blockquote
cite="mid:CAPBH6dT+H766S7DCzz_T8U7XPtC1op6xcLLsmxU5J3rPq8dm-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">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).</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Un esempio facile
facile (?) tanto per andare nel concreto e non parlare sempre
di sesso degli angeli.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">
Il tema "Administrative Units" prevede 4 classi FeatureType
[1]:</div>
<div class="gmail_default"><span
style="font-family:verdana,sans-serif">- </span><font
face="verdana, sans-serif">AdministrativeUnit</font></div>
<div class="gmail_default"><font face="verdana, sans-serif">-
AdministrativeBoundary</font></div>
<div class="gmail_default"><font face="verdana, sans-serif">-
Condominium</font></div>
<div class="gmail_default"><font face="verdana, sans-serif">-
NUTSRegion</font></div>
<div><br>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">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"?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">A ciascuna Regione?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">A ISTAT?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">
A IGM?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Al MinAmbiente?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">A qualche altro
Ministero?</div>
<font face="verdana, sans-serif"><br>
</font></div>
<div>
<div class="gmail_default"><font face="verdana, sans-serif">Nel
primo caso (19 Regioni + 2 Province Autonome) in che modo
mettere dati (armonizzati) e relativi metadati?</font></div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">
<br>
</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">... e se si
organizzasse un bel webinar a settembre/ottobre (not another
conference, please!!) e si iniziasse seriamente a fare la
"lista della spesa"?</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"><font face="verdana, sans-serif">[1] <a
moz-do-not-send="true"
href="http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_v3.0.1.pdf">http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_v3.0.1.pdf</a> Fig.2,
pag. 18</font></div>
<div class="gmail_default"><font face="verdana, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana, sans-serif"><br>
</font></div>
<div class="gmail_default" style=""><font face="verdana,
sans-serif">pg</font></div>
<div class="gmail_default"><font face="verdana, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana, sans-serif"><br>
</font></div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr">
<div><span style="font-family:verdana,sans-serif"><br>
</span></div>
<div><span style="font-family:verdana,sans-serif">pg</span><br>
</div>
<div><font face="verdana, sans-serif"> </font></div>
<div><font face="verdana, sans-serif">______________________________</font></div>
<div><font face="verdana, sans-serif">Piergiorgio Cipriano</font></div>
<div><font face="verdana, sans-serif">@PgCipriano</font></div>
<div><font face="verdana, sans-serif"> </font></div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">Il giorno 11 luglio 2013 08:31, gianni
siletto <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gianbartolomeo.siletto@regione.piemonte.it"
target="_blank">gianbartolomeo.siletto@regione.piemonte.it</a>></span>
ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">rndt wrote<br>
<div class="im">> Ciao Piergiorgio.<br>
> Il problema è proprio che in Italia si stanno
tentando di fare solo<br>
> doppioni (diversi cataloghi che, almeno in base
all'impostazione,<br>
> conterranno le stesse informazioni) e quindi non
avrebbe senso avere tanti<br>
</div>
> cataloghi nazionali registrati al geoportale INSPIRE.
...................<br>
> .........<br>
> Saluti,<br>
> Antonio Rotundo<br>
<br>
Proprio questo è quanto mi è sembrato apparire evidente
nelle comunicazioni<br>
che ho sentito a Firenze, e che mi pare debba essere
evitato. Purtroppo ad<br>
oggi su questi temi non c'è chiarezza, e finalmente almeno
qui se ne parla!!<br>
ciao,<br>
Gianni<br>
<br>
<br>
<br>
--<br>
View this message in context: <a moz-do-not-send="true"
href="http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/INSPIRE-stato-dell-arte-tp7582934p7582971.html"
target="_blank">http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/INSPIRE-stato-dell-arte-tp7582934p7582971.html</a><br>
<div class="HOEnZb">
<div class="h5">Sent from the Gfoss -- Geographic Free and
Open Source Software - Italian mailing list mailing list
archive at Nabble.com.<br>
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a><br>
<a moz-do-not-send="true"
href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss"
target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a
tutti.<br>
I messaggi di questa lista non hanno relazione diretta
con le posizioni dell'Associazione GFOSS.it.<br>
657 iscritti al 30.5.2013</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a>
<a class="moz-txt-link-freetext" href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a>
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</pre>
</blockquote>
<br>
</body>
</html>