INSPIRE: stato dell'arte?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Piergiorgio Cipriano
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


[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 <[hidden email]> 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"?




pg




pg
 
______________________________
Piergiorgio Cipriano
@PgCipriano
 


Il giorno 11 luglio 2013 08:31, gianni siletto <[hidden email]> 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.
_______________________________________________
[hidden email]
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



_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

pcav
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 11/07/2013 14:36, Piergiorgio Cipriano ha scritto:

> 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]

Confermo: proprio stamani mi sono scorso il confine a comune fra due regioni, dai
rispettivi WMS ufficiali, e le discrepanze sono molte; ho trovato una dmax=75 m,
buchi e sovrapposizioni, ed anche abitazioni nella terra di nessuno.
Prima o poi faro' una mia repubblica in queste zone vacanti :)
Saluti.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHep7EACgkQ/NedwLUzIr6yIQCeL0i1HgqJFKLCHwe3ZczOTtyE
fp4AoI1pn1t1Jfg3Zz4MruOT1jk3hYD3
=chlQ
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
In reply to this post by Piergiorgio Cipriano
A me interesava avere rispeota alle mie domande il resto sono chiacchere.

Appunto.

On 11/07/2013 14:36, Piergiorgio Cipriano wrote:
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:


_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: INSPIRE: stato dell'arte?

gianni siletto
In reply to this post by Piergiorgio Cipriano
non posso che essere d'accordo! Il problema è proprio quello che dici: a chi spetta l'organizzazione a scala nazionale? che ruolo hanno i diversi soggetti che in qualche modo si occupano (o usano?) i diversi dataset, ad esempio i limiti amministrativi? (nel tuo elenco di soggetti manca il catasto...!)

Tempo fa abbiamo (Piemonte) cercato con IGM e col catasto di attivare qualcosa, senza riuscirci...
Con ISTAT ci era andata meglio però ai tempi del penultimo censimento (questa volta hanno fatto da soli).

Piergiorgio Cipriano wrote
.........
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?
Per restare sul tema, noi abbiamo deciso di utilizzare il dataset di ISTAT (che sappiamo avere degli errori, ma almeno ha una fonte certa a una certa data), e stiamo pensando di costruire un dataset a partire dai dati catastali esposti da Sigmater...(con tutti i problemi del caso, buchi e sovrapposizioni). Il catasto ci ha già detto che non avrà nessun valore (dal loro punto di vista): non avrà l'"ufficialità" cha sarebbe opportuna, ma dovendo raccordarmi coi Comuni è l'unica cosa che posso fare per avere un dato alla scala necessaria e condiviso tra tutti (ad oggi ogni Comune ha provveduto a trasformarsi in casa il dato catastale, senza preoccuparsi dei vicini)

Piergiorgio Cipriano wrote
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]
Piergiorgio Cipriano wrote
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)
Assolutamente vero (almeno tra Piemonte e Lombardia/Liguria/VdAosta). A volte anche i SR sono diversi...
Piergiorgio Cipriano wrote
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]
Bella domanda! in attesa di risposte certe si può "fare a metà" (ma partendo tutti dallo stesso dato di base (p.es. i catastali). Tra parentesi: il bello del dato di ISTAT è che è già armonizzato (non so come)
Piergiorgio Cipriano wrote
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])
Qui dipende dal modello di infrastruttura che si sceglie (ma anche da chi è il titolare del dato: se fosse ISTAT o Adt dovrebbe essere un unico dataset e un unico servizio...)
<quote author="Piergiorgio Cipriano">
4) catalogare i rispettivi metadati, in cataloghi locali/regionali e nazionali, evitando loop (nel caso di harvesting) e sovrapposizioni
anche qui, bisogna scegliere un modello di infrastruttura!

Piergiorgio Cipriano wrote
... e se si organizzasse un bel webinar a settembre/ottobre (not another conference, please!!) e si iniziasse seriamente a fare la "lista della spesa"?
organizzare la lista della spesa con un webinar? (dal basso ancora una volta?)
Comunque, sì, si può fare! chi organizza? chi invitare?

A presto
gianni
Reply | Threaded
Open this post in threaded view
|

Re: INSPIRE: stato dell'arte?

Antonio Rotundo
In reply to this post by Piergiorgio Cipriano
Grazie Piergiorgio, è così. Non mi riferivo al file excel richiesto per il monitoring & reporting che tutte le Regioni hanno diligentemente trasmesso, ma, come dicevo, non avendo indicazioni sui dataset e i servizi di interesse per INSPIRE e, quindi, sui relativi responsabili (l'elenco di cui parlavo, richiesto in base alla Decisione citata e che l'Italia, a livello di coordinamento nazionale, non ha ancora predisposto), sono stati inseriti nel file excel tutti i dataset e i servizi disponibili presso le varie Amministrazioni (quando dicevo "di tutto di più" mi riferivo a questo).
Saluti,
Antonio Rotundo
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Piergiorgio Cipriano
In reply to this post by Andrea Peri
E le tue domande riguardavano il mapping tra le specifiche dbTopo RT e Inspire?
Ovvero "corrispondenza con le 4 stratificazioni di Inspire."?
In tal caso direi proprio di si, le corrispondenze dovrebbero essere quelle.
Ma non puoi pensare di fermarti con il mapping a livello di classe: il bello arriva dopo, a livello di attributi, codelist e valori.
E li' non ci sono automatismi (o almeno non solo quelli) ma occorre conoscere e bene i dati.

pg



pg
 
______________________________
Piergiorgio Cipriano
@PgCipriano
 


Il giorno 11 luglio 2013 14:51, aperi2007 <[hidden email]> ha scritto:
A me interesava avere rispeota alle mie domande il resto sono chiacchere.

Appunto.


On 11/07/2013 14:36, Piergiorgio Cipriano wrote:
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:



_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
In reply to this post by pcav
On 11/07/2013 14:40, Paolo Cavallini wrote:
> Confermo: proprio stamani mi sono scorso il confine a comune fra due regioni, dai
> rispettivi WMS ufficiali, e le discrepanze sono molte; ho trovato una dmax=75 m,
> buchi e sovrapposizioni, ed anche abitazioni nella terra di nessuno.
> Prima o poi faro' una mia repubblica in queste zone vacanti:)

75 metri sono molti. Oserei dire troppi.

Ad esempio spesso succede che utenti ci contattano dicendoci che i
nostri dati sbagliano di anche 50 metri,
Ma quando troviamo il tempo d confrontarci , alla fine va a finire che a
parte errori locali, sono sempre gli utenti che settavano male i loro
sistemi. Niente di male, si spiega , ci ringraziano e finisce li'.
Ma quando poi le cose si lanciano sulle ML diventa una cosa che poi
difficilmente è possibile correggere.

Questo ad esempio succedeva spesso con il nostro vecchio geoscopio_wms.

Per il quale esponevamo due servizi, uno adatto solo per il GB e l'altro
adatto per tutti gli altri sistemi di riferimento.
Purtroppo tutti gli utenti erano usi non leggersi mai la documentazione
e piuttosto preferivano fare cooia/incolla da improbabili istruzionii
scritte chissa' da chi su internet.
E poi ci chiamavano lamentandosi che vi erano 50 metri di errore.
Nel 100% dei casi a cui rispondevo io  erano sempre utenti che usavano
il servizio errato .

Anche ora che usiamoun nuovo sistema con addiittura i grigliati IGM a
supportare un ottimo livello di trasformazione di coordinate.
Ancora vi è qualcuno che ci chiama.
In questo caso l'errore tipico è l'utente che sbaglia a settare sul suo
client gis il sistemadi rifeirimento, facendo fare la trasformazione al
suo client anziche' al server wms e quindi provocando lui l'errore di 50
metri.

Andrea.

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

pcav
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 11/07/2013 15:22, aperi2007 ha scritto:

> 75 metri sono molti. Oserei dire troppi.

Non sono errori legati alle proiezioni, sono proprio due confini diversi,
evidentemente nati da processi diversi, separati ed indipendenti.

Saluti.

- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHesnIACgkQ/NedwLUzIr7wewCeNDRooHD4LnoXjrcBpqM8iErd
A/oAnAyuJF6viWG9OlBoC1SdgfD7Rl2D
=gNDR
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
On 11/07/2013 15:26, Paolo Cavallini wrote:
> Non sono errori legati alle proiezioni, sono proprio due confini diversi,
> evidentemente nati da processi diversi, separati ed indipendenti.

E allora perche' lo descrivi come un difetto ?

Sta a chi usa i dati discernere, per questo si dice sempre che serve
competenza, discernere se usarli o no'.

E anche per questo che serve la metainformazione.

Servono schede di metainformazione fatte bene , con una parte "lineage"
dettagliata che descriva i processi produttivi.
In modo che utenti skilled possano leggersele e comprendere se un dato
va bene al suo scopo oppure no.

I dati GIS sono difficli da trattare e anche da usare.
Pretendere che tutto sia armonizzato è come pretendere che le strade
siano dritte per non dover imparare a usare il volante.

I dati non potranno mai essere veramente armonizzati tra loro perhce'
derivano sempre da processi differenti.
Diffrnti perche originati da esigenze differenti.

Faccio notare che un campo obbligatorio nella metainformazione è il
campo "scope" dove ci si aspetterebbe che chi produce il dato ci scriva
lo scopo che si prefiggeva nella produzione del dato.

Un buon campo "scope" aiuterebbe a capire se il dato dei comuni che
guardi è utile per il tuo scopo.
Altrimenti uno lo us e poi si lamenta perche' non è come lui se lo vorrebbe.

Andrea,

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Alessandro Sarretta
Andrea, non è solo un discorso di metainformazione,
le data specifications hanno anche requirements (mandatory) e
recommendations (opzionali) sui dati.
Ad esempio per Administrative Units a pag. 21 delle Technical Guidelines
c'è un requirement e delle recommendations sulla consistenza topologica:

Requirement 8
Instances of the spatial object type AdministrativeBoundary shall
correspond to the
edges in the topological structure of the complete (including all
levels) boundary graph.

Recommendation 3
The following geometric and topological constraints are recommendations
for this
data specification:
Adjacent administrative units should not overlap, i.e. their boundaries
should not intersect with each
other.
There should be no gaps between adjacent administrative units.
Unintended gaps between administrative units due to geometrical
inconsistencies are in principle not
allowed. Boundaries of neighboring administrative units shall have the
same set of coordinates,
within the specified resolution.
The border line that limits the administrative units shall correspond to
the geometries representing
the boundaries of this administrative unit.
The boundaries must not have dangles, boundaries always divide different
administrative units.

Se fosse sempre e solo un problema si scope sarebbe più semplice, ma non
sempre è così :-)
Ale

On 07/11/2013 03:58 PM, aperi2007 wrote:

> On 11/07/2013 15:26, Paolo Cavallini wrote:
>> Non sono errori legati alle proiezioni, sono proprio due confini
>> diversi,
>> evidentemente nati da processi diversi, separati ed indipendenti.
>
> E allora perche' lo descrivi come un difetto ?
>
> Sta a chi usa i dati discernere, per questo si dice sempre che serve
> competenza, discernere se usarli o no'.
>
> E anche per questo che serve la metainformazione.
>
> Servono schede di metainformazione fatte bene , con una parte
> "lineage" dettagliata che descriva i processi produttivi.
> In modo che utenti skilled possano leggersele e comprendere se un dato
> va bene al suo scopo oppure no.
>
> I dati GIS sono difficli da trattare e anche da usare.
> Pretendere che tutto sia armonizzato è come pretendere che le strade
> siano dritte per non dover imparare a usare il volante.
>
> I dati non potranno mai essere veramente armonizzati tra loro perhce'
> derivano sempre da processi differenti.
> Diffrnti perche originati da esigenze differenti.
>
> Faccio notare che un campo obbligatorio nella metainformazione è il
> campo "scope" dove ci si aspetterebbe che chi produce il dato ci
> scriva lo scopo che si prefiggeva nella produzione del dato.
>
> Un buon campo "scope" aiuterebbe a capire se il dato dei comuni che
> guardi è utile per il tuo scopo.
> Altrimenti uno lo us e poi si lamenta perche' non è come lui se lo
> vorrebbe.
>
> Andrea,
>
> _______________________________________________
> [hidden email]
> 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


--
Alessandro Sarretta

e-mail: [hidden email]
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID: http://orcid.org/0000-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
Ciao Alessandro.

Ammetto che comincio a durare fatica in questi discorsi .
Ogni volta serve un saltologico.

Mi pareva scontato che se si confronta un dato a scala 25K con un dato a
scala 10K si vedono dei buchi e delle sovrapposizioni .
Non ti torna ?

Questo  non centra ienta con la consistenza topologica.
Inspire chiede che un archivio sia topologicamente consistente.
Al massimo chiede che piu' archivi destinati a essere parte di una
medesima serie devono esere consistenti topoloficmanete.

Ma due cose che csono come capra e cavoli nessuno puo' immaginarsi che
debbano essere consistenti topologicamente.

Poi fate un po come credete meglio .
1+1 di solito fa 2, a volte fa 0, con qualche sforzo puo' arrivare a fare 1,
ma 3 non lo fara' mai. :)

Ciao,

Andrea.

On 11/07/2013 16:31, Alessandro Sarretta wrote:

> Andrea, non è solo un discorso di metainformazione,
> le data specifications hanno anche requirements (mandatory) e
> recommendations (opzionali) sui dati.
> Ad esempio per Administrative Units a pag. 21 delle Technical
> Guidelines c'è un requirement e delle recommendations sulla
> consistenza topologica:
>
> Requirement 8
> Instances of the spatial object type AdministrativeBoundary shall
> correspond to the
> edges in the topological structure of the complete (including all
> levels) boundary graph.
>
> Recommendation 3
> The following geometric and topological constraints are
> recommendations for this
> data specification:
> Adjacent administrative units should not overlap, i.e. their
> boundaries should not intersect with each
> other.
> There should be no gaps between adjacent administrative units.
> Unintended gaps between administrative units due to geometrical
> inconsistencies are in principle not
> allowed. Boundaries of neighboring administrative units shall have the
> same set of coordinates,
> within the specified resolution.
> The border line that limits the administrative units shall correspond
> to the geometries representing
> the boundaries of this administrative unit.
> The boundaries must not have dangles, boundaries always divide
> different administrative units.
>
> Se fosse sempre e solo un problema si scope sarebbe più semplice, ma
> non sempre è così :-)
> Ale
>
> On 07/11/2013 03:58 PM, aperi2007 wrote:
>> On 11/07/2013 15:26, Paolo Cavallini wrote:
>>> Non sono errori legati alle proiezioni, sono proprio due confini
>>> diversi,
>>> evidentemente nati da processi diversi, separati ed indipendenti.
>>
>> E allora perche' lo descrivi come un difetto ?
>>
>> Sta a chi usa i dati discernere, per questo si dice sempre che serve
>> competenza, discernere se usarli o no'.
>>
>> E anche per questo che serve la metainformazione.
>>
>> Servono schede di metainformazione fatte bene , con una parte
>> "lineage" dettagliata che descriva i processi produttivi.
>> In modo che utenti skilled possano leggersele e comprendere se un
>> dato va bene al suo scopo oppure no.
>>
>> I dati GIS sono difficli da trattare e anche da usare.
>> Pretendere che tutto sia armonizzato è come pretendere che le strade
>> siano dritte per non dover imparare a usare il volante.
>>
>> I dati non potranno mai essere veramente armonizzati tra loro perhce'
>> derivano sempre da processi differenti.
>> Diffrnti perche originati da esigenze differenti.
>>
>> Faccio notare che un campo obbligatorio nella metainformazione è il
>> campo "scope" dove ci si aspetterebbe che chi produce il dato ci
>> scriva lo scopo che si prefiggeva nella produzione del dato.
>>
>> Un buon campo "scope" aiuterebbe a capire se il dato dei comuni che
>> guardi è utile per il tuo scopo.
>> Altrimenti uno lo us e poi si lamenta perche' non è come lui se lo
>> vorrebbe.
>>
>> Andrea,
>>
>> _______________________________________________
>> [hidden email]
>> 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
>
>

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Sandro Santilli
In reply to this post by Piergiorgio Cipriano
Ottimo thread, grazie a tutti i partecipanti, e spero questa ML
possa servire a migliorare il processo di armonizzazione.

Mi sembra di capire che non ci sia oggi un'autorita' che manutenga un
set _ufficiale_ di administrative boundary. Va da se che una
regione puo' essere manutentore ufficiale di confini tra province
diverse della stessa regione ma NON puo' da solo essere responsabile
dei bundary e nodi "di confine" con altre regioni. La responsabilita'
deve necessariamente essere associata a elementi primitivi della topologia.

Vi prego di non far scadere la discussione nella polemica (ne ho sentito
l'odore) perche' e' una discussione MOLTO interessante :)

--strk;

On Thu, Jul 11, 2013 at 03:21:03PM +0200, Piergiorgio Cipriano wrote:

> E le tue domande riguardavano il mapping tra le specifiche dbTopo RT e
> Inspire?
> Ovvero "corrispondenza con le 4 stratificazioni di Inspire."?
> In tal caso direi proprio di si, le corrispondenze dovrebbero essere quelle.
> Ma non puoi pensare di fermarti con il mapping a livello di classe: il
> bello arriva dopo, a livello di attributi, codelist e valori.
> E li' non ci sono automatismi (o almeno non solo quelli) ma occorre
> conoscere e bene i dati.
>
> pg
>
>
>
> pg
>
> ______________________________
> Piergiorgio Cipriano
> @PgCipriano
>
>
>
> Il giorno 11 luglio 2013 14:51, aperi2007 <[hidden email]> ha scritto:
>
> >  A me interesava avere rispeota alle mie domande il resto sono chiacchere.
> >
> > Appunto.
> >
> >
> > On 11/07/2013 14:36, Piergiorgio Cipriano wrote:
> >
> > 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:
> >
> >
> >
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

stefano campus
Administrator
nella vicenda dei confini amministrativi, l'unica cosa certa è che il responsabile del confine di stato è igm.
dunque, teoricamente un comune di frontiera dovrebbe avere almeno la parte di perimetro esposto alle invasioni di galli e celti vari armonizzato, ma non credo proprio non credo che sia così :-)

il fatto è che gli attori sono:
- istat dice giustamente la propria in quanto autorità che esegue il censimento generale della popolazione
- agenzia delle entrate o catasto che dir si voglia
- igm per la parte di confine nazionale
- i comuni
- le regioni

non credo di avere dimenticato nessuno, ma sono comunque sufficienti.

proprio l'altro giorno, un comune piemontese che sta realizzando il dbtopografico si è accorto che nel dataset non generalizzato istat dei confini amministrativi pubblicato alla fine del 2011 che il confine comunale passa in mezzo alla piazza centrale del paese.
ovviamente lo correggeranno, ma esiste una procedura, un flusso che faccia sì che questo palese erore materiale sia recepito e corretto in tutti i dataset?

torniamo ad inspire e al principio del dataset di riferimento che deve essere mantenuto nel posto più appropriato: dunque in capo al comune?

bohhhh...
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Sandro Santilli
On Fri, Jul 12, 2013 at 02:58:54AM -0700, stefano campus wrote:

> nella vicenda dei confini amministrativi, l'unica cosa certa è che il
> responsabile del confine di stato è igm.
> dunque, teoricamente un comune di frontiera dovrebbe avere almeno la parte
> di perimetro esposto alle invasioni di galli e celti vari armonizzato, ma
> non credo proprio non credo che sia così :-)
>
> il fatto è che gli attori sono:
> - istat dice giustamente la propria in quanto autorità che esegue il
> censimento generale della popolazione
> - agenzia delle entrate o catasto che dir si voglia
> - igm per la parte di confine nazionale
> - i comuni
> - le regioni
>
> non credo di avere dimenticato nessuno, ma sono comunque sufficienti.
>
> proprio l'altro giorno, un comune piemontese che sta realizzando il
> dbtopografico si è accorto che nel dataset non generalizzato istat dei
> confini amministrativi pubblicato alla fine del 2011 che il confine comunale
> passa in mezzo alla piazza centrale del paese.
> ovviamente lo correggeranno, ma esiste una procedura, un flusso che faccia
> sì che questo palese erore materiale sia recepito e corretto in tutti i
> dataset?
>
> torniamo ad inspire e al principio del dataset di riferimento che deve
> essere mantenuto nel posto più appropriato: dunque in capo al comune?

In questo caso, trattandosi di confine, il responsabile diretto non
puo' essere il singolo comune (a meno che costiero), ma eventualmente
entrambi i comuni confinanti, con la registrazione/certificazione finale
dell'ente superiore (regione?).

--strk;
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Flavio Rigolon
> In questo caso, trattandosi di confine, il responsabile diretto non
> puo' essere il singolo comune (a meno che costiero), ma eventualmente
> entrambi i comuni confinanti, con la registrazione/certificazione finale
> dell'ente superiore (regione?).

si, durante la fase di redazione del PAT (Piano di Assetto del
Territorio), almeno qui in Veneto, il Comune è chiamato a
confermare/correggere il limite amministrativo che la regione propone.
Il controllo viene fatto inseguendo tutto il confine e contattando i
comuni contermini (ognuno per il tratto di propria competenza) con i
quali viene poi siglato un documento di concertazione. Il dato così
condiviso (SHP) viene poi ritornato alla regione che lo registra.
ciao
flaivo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
In reply to this post by Andrea Peri

Anche in toscana funziona allo stesso modo.
Quando possibile si muovono per particelle catastali. Ovvero i due comuni deliberano che una part. Cat passa da un comune all'altro. Poi la. Regione recepisce e aggiorna la copertura dei confini comunali. Per aiutare chi ci lavora nel settore pianificazione, accanto alla usuale copertura poligonale forniamo anche anche quella lineare in cui negli attributi al tratto vi é il decreto che istituisce quel pezzo di confine. In questo modo é possibile ricostruire i confini a una determinata data.



Send from padfone2

stefano campus <[hidden email]> ha scritto:

>nella vicenda dei confini amministrativi, l'unica cosa certa è che il
>responsabile del confine di stato è igm.
>dunque, teoricamente un comune di frontiera dovrebbe avere almeno la parte
>di perimetro esposto alle invasioni di galli e celti vari armonizzato, ma
>non credo proprio non credo che sia così :-)
>
>il fatto è che gli attori sono:
>- istat dice giustamente la propria in quanto autorità che esegue il
>censimento generale della popolazione
>- agenzia delle entrate o catasto che dir si voglia
>- igm per la parte di confine nazionale
>- i comuni
>- le regioni
>
>non credo di avere dimenticato nessuno, ma sono comunque sufficienti.
>
>proprio l'altro giorno, un comune piemontese che sta realizzando il
>dbtopografico si è accorto che nel dataset non generalizzato istat dei
>confini amministrativi pubblicato alla fine del 2011 che il confine comunale
>passa in mezzo alla piazza centrale del paese.
>ovviamente lo correggeranno, ma esiste una procedura, un flusso che faccia
>sì che questo palese erore materiale sia recepito e corretto in tutti i
>dataset?
>
>torniamo ad inspire e al principio del dataset di riferimento che deve
>essere mantenuto nel posto più appropriato: dunque in capo al comune?
>
>bohhhh...
>
>
>
>--
>View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/INSPIRE-stato-dell-arte-tp7582934p7583004.html
>Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
>_______________________________________________
>[hidden email]
>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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Andrea Peri
In reply to this post by Flavio Rigolon

Anche in RT funziona cosi'.

Dopo che i rispettivi consigli dei due comuni confinanti hanno deliberato sul tratto conteso, se possibile deliberano appoggiandosi sulle particelle catastali stabilendo che una o piu' particelle passano da un comune all'altro. Non sempre è possibile e allora ricorrono a elementi della CTR 2k o 10k.
Se poi niente altro è disponibile, anche alle ortofoto. Ma solo quanto proprio non vi è niente altro di meglio.

In Toscana alla fine la copertura dei confini comumali è multisorgente, perche' i tratti derivano da tante fonti, proprio perche' non vi era una copertura completa da parte di una medesima fonte.

Poi la regione recepisce e aggiorna la copertura dei confini comunali.
Per aiutare chi lavora usualmente con la pianificazione mettiamo a disposizione, oltre alla usuale copertura poligonale, anche una copertura lineare sulla quale, negli attributi al tratto viene riportato anche la delibera che ha normato quello specifico tratto.
In questa maniera è sempre possibile ricostruire i confini in periodi passati.

A certe categorie di utenze non interessa tanto sapere che confine vi è oggi, ma magari interessa sapere che confine vi era ad esempio il 12/06/2005.
Perche' magari in quella data è stato approvata una variante a un regolamento comunale. Variante tutt'ora vigente e quindi per interpretarla per bene serve conoscere il confine a tale data oltre che il confine a oggi.

A.


Il giorno 12 luglio 2013 12:40, flavio rigolon <[hidden email]> ha scritto:
> In questo caso, trattandosi di confine, il responsabile diretto non
> puo' essere il singolo comune (a meno che costiero), ma eventualmente
> entrambi i comuni confinanti, con la registrazione/certificazione finale
> dell'ente superiore (regione?).

si, durante la fase di redazione del PAT (Piano di Assetto del
Territorio), almeno qui in Veneto, il Comune è chiamato a
confermare/correggere il limite amministrativo che la regione propone.
Il controllo viene fatto inseguendo tutto il confine e contattando i
comuni contermini (ognuno per il tratto di propria competenza) con i
quali viene poi siglato un documento di concertazione. Il dato così
condiviso (SHP) viene poi ritornato alla regione che lo registra.
ciao
flaivo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
_______________________________________________
[hidden email]
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



--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

stefano campus
Administrator
In reply to this post by Flavio Rigolon
così era stato fatto anche qua in piemonte in occasione del censimento del 2001 attraverso la regione.
ora questo lavoro per il censimento del 2011 è stato fatto direttamente da istat che ha contattato i comuni e "concordato" i confini, ovviamente solo con chi ha risposto.
non c'è stato poi nessun passaggio ufficiale da istat a regione o da comune a regione.

l'unica novità è stata l'esposizione di questi poligoni non generalizzati dal sito istat, peraltro nel sistema di riferimento ED_1950_UTM Zona 32, con buona pace di chi è in zona 33.
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

pcav
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 12/07/2013 16:31, stefano campus ha scritto:
> così era stato fatto anche qua in piemonte in occasione del censimento del
> 2001 attraverso la regione.

Infatti, il problema si riscontra ai confini fra regioni contigue.
Saluti.

- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHgE9kACgkQ/NedwLUzIr4b1QCdErfLeP2KJ19oUbqqE+7W8Eod
yMEAoKI8vke4USE2ldGLj+s8PCj034QT
=gCmD
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: alcune indicazioni: ex INSPIRE: stato dell'arte?

Piergiorgio Cipriano
In reply to this post by Andrea Peri
Ciao,
riprendo il thread per segnalare due interessanti presentazioni fatte a Firenze recentemente (INSPIRE conf).
La prima [1] e' un esempio interessante di come definire la "lista della spesa" (a livello di sub-type) per capire chi "si occupa di quali dati" (vedi esempio slide 11).
La seconda [2] riguarda i costi (in mesi uomo) spesi per implementare il geoportale nazionale polacco (slide 23..25)

pg






pg
 
______________________________
Piergiorgio Cipriano
@PgCipriano
 


Il giorno 12 luglio 2013 13:31, Andrea Peri <[hidden email]> ha scritto:

Anche in toscana funziona allo stesso modo.
Quando possibile si muovono per particelle catastali. Ovvero i due comuni deliberano che una part. Cat passa da un comune all'altro. Poi la. Regione recepisce e aggiorna la copertura dei confini comunali. Per aiutare chi ci lavora nel settore pianificazione, accanto alla usuale copertura poligonale forniamo anche anche quella lineare in cui negli attributi al tratto vi é il decreto che istituisce quel pezzo di confine. In questo modo é possibile ricostruire i confini a una determinata data.



Send from padfone2

stefano campus <[hidden email]> ha scritto:

>nella vicenda dei confini amministrativi, l'unica cosa certa è che il
>responsabile del confine di stato è igm.
>dunque, teoricamente un comune di frontiera dovrebbe avere almeno la parte
>di perimetro esposto alle invasioni di galli e celti vari armonizzato, ma
>non credo proprio non credo che sia così :-)
>
>il fatto è che gli attori sono:
>- istat dice giustamente la propria in quanto autorità che esegue il
>censimento generale della popolazione
>- agenzia delle entrate o catasto che dir si voglia
>- igm per la parte di confine nazionale
>- i comuni
>- le regioni
>
>non credo di avere dimenticato nessuno, ma sono comunque sufficienti.
>
>proprio l'altro giorno, un comune piemontese che sta realizzando il
>dbtopografico si è accorto che nel dataset non generalizzato istat dei
>confini amministrativi pubblicato alla fine del 2011 che il confine comunale
>passa in mezzo alla piazza centrale del paese.
>ovviamente lo correggeranno, ma esiste una procedura, un flusso che faccia
>sì che questo palese erore materiale sia recepito e corretto in tutti i
>dataset?
>
>torniamo ad inspire e al principio del dataset di riferimento che deve
>essere mantenuto nel posto più appropriato: dunque in capo al comune?
>
>bohhhh...
>
>
>
>--
>View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/INSPIRE-stato-dell-arte-tp7582934p7583004.html
>Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
>_______________________________________________
>[hidden email]
>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
_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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
12