derby dell'appennino

[francesco marucci-2]

gentile lista,
ho notato che tra i WMS esposti dalla Regione Emilia-Romagna e dalla Regione Toscana in WGS84 (sia geografiche che piane) c'e' uno scostamento di circa 78 metri (soprattutto sulle y).

in particolare sto testando le seguenti URL:

RER:
http://servizigis.regione.emilia-romagna.it/wms/dbtr2008?LAYER=2

RT:
http://web.rete.toscana.it:80/sgrwms/com.rt.wms.RTmap/_rt_wms_wgs84?layer=idcomuni
http://web.rete.toscana.it:80/sgrwms/com.rt.wms.RTmap/_rt_wms_wgs84?layer=otf10k10

giusto qualche screenshot:
http://www.tecnograph-group.com/public/derby_appennino1.jpg
http://www.tecnograph-group.com/public/derby_appennino2.jpg
http://www.tecnograph-group.com/public/derby_appennino3.jpg


lo scostamento sembra costante lungo tutto il confine regionale (effettivamente ho controllato, solamente la parte nord della Toscana), e' da qualche giorno che l'ho notato (almeno un paio di settimane) e aggiungo, ma prometto che non si tratta di "campanilismo", che confrontando i WMS RT con OpenStreetMap/Google Maps, sembra che sia un problema di GeoScopio (derby_appennino1.jpg).

chi vince ?
e' un problema noto ?
a chi potrei rivolgermi per segnalarlo ?


cordiali saluti,
francesco

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[a.furieri]

On Tue, 4 Oct 2011 10:58:38 +0200, francesco marucci wrote
> gentile lista,
> ho notato che tra i WMS esposti dalla Regione Emilia-Romagna e
> dalla Regione Toscana in WGS84 (sia geografiche che piane) c'e'
> uno scostamento di circa 78 metri (soprattutto sulle y).
>

Francesco,

pare il più classico dei problemi derivanti da errori di
approssimazione quando si passa da GaussBoaga a WGS84:
in genere si presenta proprio con queste modalità

dire a priori chi dei due ha ragione tra toscana ed emilia
ovviamente non è possibile: servirebbe una verifica puntuale

magari qualcuno di RT interessato a rispondere ci sta leggendo,
e potrebbe darci utili lumi ;-)

comunque, en passant, ecco un buon argomento che
dimostra perchè la libera circolazione dell'informazione
geografica è cosa buona e giusta.
perchè più occhi spulciano e più problemi saltano
fuori: con sicuro miglioramento della qualità per
tutti indistintamente :-D

ciao Sandro


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[giohappy]

Intanto si potrebbero fare dei controlli relativamente ai vertici geodetici dell'IGM http://www.igmi.org/geodetica/

giovanni

Il giorno 04 ottobre 2011 13:08, <[hidden email]> ha scritto:

On Tue, 4 Oct 2011 10:58:38 +0200, francesco marucci wrote
> gentile lista,
> ho notato che tra i WMS esposti dalla Regione Emilia-Romagna e
> dalla Regione Toscana in WGS84 (sia geografiche che piane) c'e'
> uno scostamento di circa 78 metri (soprattutto sulle y).
>

Francesco,

pare il più classico dei problemi derivanti da errori di
approssimazione quando si passa da GaussBoaga a WGS84:
in genere si presenta proprio con queste modalità

dire a priori chi dei due ha ragione tra toscana ed emilia
ovviamente non è possibile: servirebbe una verifica puntuale

magari qualcuno di RT interessato a rispondere ci sta leggendo,
e potrebbe darci utili lumi ;-)

comunque, en passant, ecco un buon argomento che
dimostra perchè la libera circolazione dell'informazione
geografica è cosa buona e giusta.
perchè più occhi spulciano e più problemi saltano
fuori: con sicuro miglioramento della qualità per
tutti indistintamente :-D

ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Andrea Peri]

Si, certo, google.
Ci sara' un motivo se e' anche il verso del tacchino :)

Scherzi a parte.
se la fonte che usi per fare i confronti e' shiftata, allora non depone a tuo favore essere preciso con tale fonte.
Ma forse anche geoscopio e' preciso con google e questo non deporrebbe a suo favore.

Per cui vediamo di fare qualche prova piu' consona.

per questo io metterei da parte le geografiche, che vediamo dopo se serve, e mi concentrerei sulle proiettate e nello specifico su EPSG:3003,
tra poco sara' chiaro perche':

Alcun dei dati di gesocopio_wms sono scaricabili da geoscopio_web.

E nello specifico lo sono i confini comunali.
Senza licenza, ma in questo caso la cosa non ci interessa perche' stiamo a discutere di precisione dei dati.

Per cui:

ci si collega a Geoscopio WEB e si scarica lo shapefile dei confini comunali ,

poi si mette tale shapefile dei confini comunali (che e' in epsg:3003) su qgis,
e contemporaneamente si crea uno strato wms e ci si collega a Geoscopio_wms
con lo strato "idcomuni" chiamandolo in epsg:3003.

lo strato che vedete su geoscopio_wms non e' una copia di quello scaricabile E' ESATTAMENTE LUI !
Un apposito sistema crea al volo lo shapefile prendendolo da quello in utilizzo da geoscopio_wms, per cui non esistono dubbi che i due dati devono collimare esattamente.

E va usato EPSG:3003 perche' tale e' il suo sistema di riferimento.
Per cui si e' perfettamente in grado di verificare se i due sistemi si sovrappongono.

Nel fare questo si cerca di evitare che il software gis che si sta' utilizzando ci mette del suo a incasinare le cose facendo una conversione al volo che in questo caso e' assolutamente inutile e serve solo a peggiorere i dati.

Mi accingo a fare questa prova, vi faccio sapere.

Saluti,

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


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[giohappy]

google?

Se clicchi sui capisaldi ti si apre la scheda con ROMA 40 e ETRF2000: http://87.30.244.175/ware/schedalive.php?id=13681

Il giorno 04 ottobre 2011 17:27, Andrea Peri <[hidden email]> ha scritto:

Si, certo, google.
Ci sara' un motivo se e' anche il verso del tacchino :)

Scherzi a parte.
se la fonte che usi per fare i confronti e' shiftata, allora non depone a tuo favore essere preciso con tale fonte.
Ma forse anche geoscopio e' preciso con google e questo non deporrebbe a suo favore.

Per cui vediamo di fare qualche prova piu' consona.

per questo io metterei da parte le geografiche, che vediamo dopo se serve, e mi concentrerei sulle proiettate e nello specifico su EPSG:3003,
tra poco sara' chiaro perche':

Alcun dei dati di gesocopio_wms sono scaricabili da geoscopio_web.

E nello specifico lo sono i confini comunali.
Senza licenza, ma in questo caso la cosa non ci interessa perche' stiamo a discutere di precisione dei dati.

Per cui:

ci si collega a Geoscopio WEB e si scarica lo shapefile dei confini comunali ,

poi si mette tale shapefile dei confini comunali (che e' in epsg:3003) su qgis,
e contemporaneamente si crea uno strato wms e ci si collega a Geoscopio_wms
con lo strato "idcomuni" chiamandolo in epsg:3003.

lo strato che vedete su geoscopio_wms non e' una copia di quello scaricabile E' ESATTAMENTE LUI !
Un apposito sistema crea al volo lo shapefile prendendolo da quello in utilizzo da geoscopio_wms, per cui non esistono dubbi che i due dati devono collimare esattamente.

E va usato EPSG:3003 perche' tale e' il suo sistema di riferimento.
Per cui si e' perfettamente in grado di verificare se i due sistemi si sovrappongono.

Nel fare questo si cerca di evitare che il software gis che si sta' utilizzando ci mette del suo a incasinare le cose facendo una conversione al volo che in questo caso e' assolutamente inutile e serve solo a peggiorere i dati.

Mi accingo a fare questa prova, vi faccio sapere.

Saluti,

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


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Andrea Peri]

Coe dicevo i dati della sorgente "sembrano" shiftati.
Avevo gia' analizzato la cosa qualche anno fa' e pero' poteva darsi che ora fosse differente.

Pe sicurezza ho ricontrollato.

E infatti sono tornato nei soliti luoghi e ho potuto constatare che lo sono sempre.

Per intendersi:

si vede una strada che si incunea in collina, poi si sfuma mentre una altra shiftata di qualche metro (circa 15-20 metri) ne compare un'altra che prende il suo posto e prosegue quella.

Questo giochetto compare ogni tanto, certo nelle zone molto distanti dai grandi centri, ma il punto e' che non si sa' bene quale sia quella su coordinate buone, se mai ce ne fosse una su coordinate buone.

Del resto e' comprensibile che possano non avere coordinate buone, il loro compito non e' fornire e coordinate, ma solo fornire una carta consultabile e per questo serve la coerenza complessiva del sistema, e non tanto l'aderenza o meno alla realta' metrica.
E non sarei neanche stupito se leggessi che e' uno shift fatto di proposito,
e' logico che se metto dei dati su internet dati che acquisto , se li metto shiftati mi costano meno e ottengo il medesimo scopo.

Ma questo punto non ci interessa, ci interessa invece capire che se i dati di G posson essere shiftati , non possono essere usati per stabilire la precisione degli altri dati.
Anzi e' proprio l'opposto se sono precisi con Google, probabilmente son shiftati pure essi :)

Infatti si assiste all'assurdo che vista la popolarita' di Google, in alcuni casi si possa essere tentanti di piegare i propri dati a Google, proprio perche'
lui stabilisce cosa e' la realta'.
Per cui se il re dice che 1+1 = 3 allora e' legge. !

ps:
non allego l'immagine perche' non sono sicuro che con la licenza di google tale immagine sia realmente ridistribuibile.
E' un vero peccato , ma cosi' e'...

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


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Andrea Peri]

ho trovato come recuperare il links:

ecco un esempio dello shift di cui parlavo e che rende le immagini sostanzialmente spostate.

http://maps.google.it/?ll=43.588116,11.662561&spn=0.002584,0.005681&t=k&z=18&vpsrc=6

E a questo un altro esempio:

http://maps.google.it/?ll=43.580546,11.583838&spn=0.005168,0.011362&t=k&vpsrc=6&z=17

Come dicevo questo non toglie niente alla utilita' dei dati di Google, basta usarli nel modo giusto e
per le cose giuste.

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


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[a.furieri]

posso sicuramente confermare che "big G" è
poco affidabile sul posizionamento di precisione
delle ortofoto.

quando qualche anno addietro lavoravo per
l'Osservatorio Trasporti di R.Toscana era
emerso dalle prime prove con GoogleTransit
che in qualche modo c'era una "situazione
a mosaico".
mi spiego meglio: p.es. a Pisa e Siena i
percorsi degli autobus cadevano esattamente
nella sede stradale su ortofoto.
invece ad Firenze e Livorno si notavano
dei grossi disallineamenti.
la cosa era particolarmente evidente su
Firenze città, visto che tutti i bus
"guadavano" l'arno preciso a metà tra
due ponti :-D

dopo che segnalammo il problema a "big G"
firenze andò magicamente a posto: ma Grosseto,
Arezzo etc rimasero disallineate come prima.

e questo testimonia come certamente lavorano
"a scacchiera", e ciascun quadratino ha le proprie
regole locali di riproiezione.

quindi non stupisce affatto scoprire che (come
mostrano le figure di Andrea) esistono dei margini
di contatto in cui la sovrapposizione va liberamente
a spasso.

considerazione finale: avevo capito che il problema
riguardava i sistemi delle Regioni Toscana ed
Emilia Romagna.
che c'entra Google Maps ?
mi sono perso un passaggio ?

ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Paolo Corti]

2011/10/4  <[hidden email]>:
> posso sicuramente confermare che "big G" è
> poco affidabile sul posizionamento di precisione
> delle ortofoto.

ciao

sicuramente fraintendo sia te che Andrea: ma stiamo parlando di
imprecisioni dovute al fatto di sovrapporre nostri dati locali (o
presi da altri servizi) con le immagini di Google (ma anche
OpenStreetMap/Bing/Yahoo ecc), o di discrepanze tra gauss boaga ed
utm?

Perche', nel primo caso credo che questo sia dovuto al fatto che
questi servizi, per ovvi motivi (devono rappresentare l'intero globo
terrestre), proiettano tali immagini su un sistema sferico (mercatore)
[0].
A quel punto il proiettare i nostri dati sull'immagine in 900913 - la
proiezione usata da Google et al, 900913 in 1337 speak [1] -, o il
riproiettare l'immagine da 900913 al sistema sul quale abbiamo i dati,
genera per forza di cose delle imperfezioni.

Nel secondo caso invece, non essendoci una formula esatta che converte
da utm a gauss boaga e viceversa, l'unico modo di avere risultati
quasi perfetti e' quello di applicare le costanti di transito piu'
prossime all'area che stiamo rappresentando.

Ma probabilmente ho solo perso il filo della discussione oppure e' ora
di andare a casa :)

P

[0] http://docs.openlayers.org/library/spherical_mercator.html
[1] http://crschmidt.net/blog/archives/243/google-projection-900913/

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Markus Neteler]

2011/10/4  <[hidden email]>:
> posso sicuramente confermare che "big G" è
> poco affidabile sul posizionamento di precisione
> delle ortofoto.

La prima domanda da fare sarebbe: Google sta veramente
usando un algoritmo di ortorettificazione satellitare?
(che è ben diverso della ortorettificazione di foto aereo)
In terreno montagnoso fa una differenza.

ciao
Markus
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[a.furieri]

On Tue, 4 Oct 2011 20:26:24 +0200, Markus Neteler wrote
> La prima domanda da fare sarebbe: Google sta veramente
> usando un algoritmo di ortorettificazione satellitare?
>

io credo che il problema sia di origine differente,
molto più terra terra:
Google in pratica usa un "mosaico" di materiali diversi
ed anche abbastanza poco omogenei.
in qualche zona c'è una copertura ad alta risoluzione,
qualche altra zona ha una copertura a bassa risoluzione etc.

a certe scale (ma non ad altre) si notano dei vistosi
margini e/o tasselli con improvvisi salti di colore;
evidentemente, sono proprio le zone in cui avviene
una sovrapposizione tra due materiali di differente
origine.

e presumibilmente, ogni tassello ha i suoi propri
parametri di posizionamento: che spesso "saltano"
in modo assurdo anche nel giro di pochi Km.

se volete un ottimo esempio:
- posizionatevi su perugia / attivate le ortofoto
- seguite la superstrada SS3 verso Spoleto

sia a perugia che a spoleto la sovrapposizione
tra grafo stradale ed ortofoto è buona.
invece a foligno e spello (a metà percorso) si riscontra
a colpo d'occhio un disallineamento grossolano e
generalizzato.

ergo, credo proprio che si possa escludere qualsiasi
ipotesi sugli algoritmi etc: evidentemente è un
problema di posizionamento dei singoli tasselli
per piccole zone.
ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Francesco P. Lovergine]

On Tue, Oct 04, 2011 at 08:54:09PM +0200, [hidden email] wrote:

> io credo che il problema sia di origine differente,
> molto più terra terra:
> Google in pratica usa un "mosaico" di materiali diversi
> ed anche abbastanza poco omogenei.
> in qualche zona c'è una copertura ad alta risoluzione,
> qualche altra zona ha una copertura a bassa risoluzione etc.
>
> a certe scale (ma non ad altre) si notano dei vistosi
> margini e/o tasselli con improvvisi salti di colore;
> evidentemente, sono proprio le zone in cui avviene
> una sovrapposizione tra due materiali di differente
> origine.
>
> e presumibilmente, ogni tassello ha i suoi propri
> parametri di posizionamento: che spesso "saltano"
> in modo assurdo anche nel giro di pochi Km.
>
> se volete un ottimo esempio:
> - posizionatevi su perugia / attivate le ortofoto
> - seguite la superstrada SS3 verso Spoleto
>
> sia a perugia che a spoleto la sovrapposizione
> tra grafo stradale ed ortofoto è buona.
> invece a foligno e spello (a metà percorso) si riscontra
> a colpo d'occhio un disallineamento grossolano e
> generalizzato.
>
> ergo, credo proprio che si possa escludere qualsiasi
> ipotesi sugli algoritmi etc: evidentemente è un
> problema di posizionamento dei singoli tasselli
> per piccole zone.

Personalmente mi sento di confermare, a parte il fatto
che non si tratta di ortofoto, ma di immagini satellitari
(quindi con geometria di acquisizione parecchio diversa).
In realta' tutti i vendor forniscono tra i propri prodotti
immagini ortorettificate con DEM medio e non credo che
il signor G si sogni di usare qualcosa di diverso da
tale prodotto pre-processato. Questo perché poi gli
tocca fare comunque un bel lavoro pesante di mosaicatura
e registrazione delle immagini - operazioni che non sempre
vanno per la quale, soprattutto quando si deve passare
per diverse risoluzioni. I DEM a precisione spinta necessari
alla ortorettifica di precisione non sono sempre disponibili,
quindi si accontentano di 'stirare' e registrare fra loro
le immagini usando dei GCP semi-automatici. Il risultato è
che a seconda delle zone appunto il risultato ha qualità
piuttosto variabile. Salvo aggiustamenti on-demand e nei
limiti di quel che si riesce a fare.

Cheers

--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011