SRID 900914 postgis

[Andrea Peri]

>n Mon, Nov 15, 2010 at 04:20:00PM +0100, iacopo wrote:
>
>> Resta il fatto che esportando da grass mi sono trovato con questo strano srid
>
>Che c'e' di strano ?
>E' solo un identificativo "interno" al tuo database.

>Probabilmente chi ha fatto l'import ha preferito inserire
>un record nuovo in spatial_ref_sys anziche' cercarne uno
>equivalente (ammettendo che ci fosse).
>
>--strk; 

Nel primo thread avevo letto che era epsg:3003.

>In postgis mi trovo con un layer che ha srid 900914 e che deriva da 
>un'esportazione da grass di un layer in GB (srid 3003). Mi sapete spiegare di 
>che si tratta dato che uno srid 900914 non ho idea a cosa corrisponda.

>Se poi riproietto usando SELECT ST_Transform(the_geom,3003) la riproiezione 
>viene fata, ma i dati finiscono nel posto sbagliato.

Nel thread avevi detto che era una esportazione di un codice epsg:3003,


Ma ora invece credo di capire che in realta' era un nuovo codice "equivalente" nei valori a quello dell epsg:3003

Se e' cosi', il caso e' emblematico e va compreso bene.

Infatti e' molto interessante questo effetto che se un utente importa un archivio e gli ridefinisce il sistema di riferimento,

poi si porta dietro questa nuova definizione come un "peccato originale".

Provo a ipotizzare quello che potrebbe essere successo, anche perche' e' interessante comprendere come mai sia accaduto e cosi' stare piu' attenti in futuro.


Infatti io sospetto che la colpa sia da addossare al software di importazione usato per portare in postgres il dato di partenza.

Se in tale ipotetico software non si era indicato il suo reale sistema di riferimento con il codice epsg, ma piuttosto si era indicato

i vari parametri, il software potrebbe avere importato il dato e per questo definito un nuovo codice usando il primo disponibile (900914).
Con la conseguenza che da questo momento in avanti il dato era classificato come 

"da abbinare a 900914".

Puo' darsi che sia avvenuto questo ?


Andrea.

--
-----------------
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.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[Iacopo Zetti-2]

Non so se può essere utile a chiarire per chi è più addentro del sottoscritto,
ma ciò che ho fatto è di esportare un layer vettoriale da grass direttamente
nel database postgres, ovvero:
v.out.ogr input=layervettoriale@iacopo type=area layer=1 format=PostgreSQL
seguito naturalmente da nometabella, nomdatabase ecc.
I dati in grass sono in GB. Incollo il contenuto del file proj_info:
name: Universe Transverse Mercator
datum: rome40
towgs84: -104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
proj: utm
ellps: international
a: 6378388.0000000000
es: 0.0067226700
f: 297.0000000000
zone: 32

Finita l'esportazione in postgres trovo come srid nella tabella
geometry_columns 900914
Se visualizzo i dati con qgis, senza riproiezione al volo, sono esattamente
dove devono stare.

Per quanto mi riguarda ho risolto, ma se la cosa può interessare chi è più
competente di me sul funzionamento del software (e ci vuol poco)...

Iacopo

_______________________________________________
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.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010

[a.furieri]

On Mon, 15 Nov 2010 19:02:32 +0100, iacopo wrote

> I dati in grass sono in GB. Incollo il contenuto del file proj_info:
> name: Universe Transverse Mercator
> datum: rome40
> towgs84: -104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
> proj: utm
> ellps: international
> a: 6378388.0000000000
> es: 0.0067226700
> f: 297.0000000000
> zone: 32
>

Ok, ora è tutto abbastanza più chiaro.
cerco di riassumere brevemente:

a) la GB 3003 non definisce affatto i parametri
   "di correzione locale" [+togws84]
b) questo significa concretamente che quando
   converti da/per Lat/Long, tipicamente ti trovi
   con errori di approssimazione anche superiori
   ai 100 / 150m (come dicevo stamattina)
c) per ridurre l'approssimazione, occorre definire
   opportunamente la stringa +towgs84
   ma questo deve essere fatto separatamente per
   ciascuna singola località (almeno in teoria ..),
   visto che si tratta appunto di "correzioni locali"

per mitigare la situazione, QGIS e SpatiaLite (ma
credo proprio anche Grass) supportano ulteriori GB-like
"medi-per-macro-regione", che comunque garantiscono errori
max. di 5m (decisamente accettabili), e sono esattamente
i seguenti:

srid=40000 Italy mainland zone 1 GB Roma40
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

srid=40001 Italy mainland zone 2 GB Roma40
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

srid=40002 Italy Sardinia GB Roma40
+towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48

srid=40003 Italy Sicily GB Roma40
+towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08

---
nel tuo caso sembra corrispondere esattamente ad
"Italy mainland Zone 1", (che p.es. funziona
ottimamente in toscana).

evidentemente PostGIS non supporta queste definizioni
extra, e quindi Grass quando esporta su PostGis deve
poi "inventarsi" un codice di default

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.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
474 iscritti al 18.9.2010