INSPIRE: stato dell'arte?
Locked
12
12
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
 
|
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:
_______________________________________________ [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 |
|
|
-----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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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:
_______________________________________________ [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 |
|
|
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). 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)
Assolutamente vero (almeno tra Piemonte e Lombardia/Liguria/VdAosta). A volte anche i SR sono diversi... 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) 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! 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 |
Re: INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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:
_______________________________________________ [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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
|
|
-----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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
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... |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
> 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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
In reply to this post by Flavio Rigolon
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. In questa maniera è sempre possibile ricostruire i confini in periodi passati. 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:
-- ----------------- 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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
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. |
|
|
-----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 |
Re: alcune indicazioni: ex INSPIRE: stato dell'arte?
|
|
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:
_______________________________________________ [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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |