[Gfoss] definizioni EPSG GB 3003 / 3004 e dintorni

[Antonio Falciano]

Il 21/05/2012 11.41, a.furieri a lqt.it ha scritto:
> i sistemi di riferimento spaziale son brutte bestiacce;
> ed IMHO quelli tra di noi con le idee veramente chiare in materia
> sono decisamente pochini, si contano sulle punte delle dita di una mano.
> n.b.: mi auto-escludo dal numero di quelli che "ci capiscono";
> non ho la minima esitazione nel confessare i miei limiti ;-)
>
> credo quindi che sia giusto cercare di aprire un confronto
> quanto piu' ampio possibile; e mi aspetto che persone "serie"
> come Antonio Falciano, Giovanni Allegri, Andrea Peri etc
> vorranno portare il loro contributo sicuramente utile.
>
> mi limito quindi a raccontarvi quale era l'approccio seguito da
> SpatiaLite con le "vecchie" Proj4 v.4.7.0.
> personamente, mi pare ancora la soluzione piu' regionevole.
>
> ------------------------------------------
> srid:3003
> auth_name:epsg
> auth_srid:3003
> ref_sys_name:Monte Mario / Italy zone 1
> proj4text:+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \
> +y_0=0 +ellps=intl +units=m +no_defs
>
> srid:3004
> auth_name:epsg
> auth_srid:3004
> ref_sys_name:Monte Mario / Italy zone 2
> proj4text:+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 \
> +y_0=0 +ellps=intl +units=m +no_defs
> --------------------------------------------
> queste sono le due definizioni canoniche EPSG per il GaussBoaga,
> rispettivamente fuso Ovest e fuso Est.
> e sono le uniche due che mi aspetterei di trovare incluse nel
> file EPSG distribuito da Proj4, GDAL, GeoTiff etc: come dice il
> nome stesso, quest'ultimo dovrebbe contenere *solo* le EPSG
> "purissime", cioe' quelle identificate da valori SRID nel range
> compreso tra 1 e 32766.

ok, lo stesso naturalmente dicasi per le famiglie di sistemi proiettati
UTM ED50, UTM WGS84 e UTM ETRS89. Non dovrebbero contenere parametri
+towgs84.

>
> ------------------------------------------
> srid:40000
> auth_name:gfoss.it
> auth_srid:1

ref_sys_name: Monte Mario / Italy zone 1 / mainland

> proj4text:+proj=tmerc+lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \
> +y_0=0 +ellps=intl +units=m \
> +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +no_defs
>
> srid:40001
> auth_name:gfoss.it
> auth_srid:2

ref_sys_name: Monte Mario / Italy zone 2 / mainland

> proj4text:+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 \
> +y_0=0 +ellps=intl +units=m \
> +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +no_defs
>
> srid:40002
> auth_name:gfoss.it
> auth_srid:3

ref_sys_name: Monte Mario / Italy zone 1 / Sardinia

> proj4text:+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \
> +y_0=0 +ellps=intl +units=m \
> +towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48 +no_defs
>
> srid:40003
> auth_name:gfoss.it
> auth_srid:4

ref_sys_name: Monte Mario / Italy zone 2 / Sicily
proj4text:+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 \

> +y_0=0 +ellps=intl +units=m \
> +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs
> ------------------------------------------
> invece queste qua sono le definizioni "custom" ottimizzate per le varie
> macroregioni italiane.

Benissimo. Cambierei solo la loro denominazione ricalcando quelle
originali EPSG e aggiungendo, come ulteriore specificazione, la zona di
competenza. Inoltre, la Sicilia ricade nel fuso Est e quindi si prende
la definizione di EPSG:3004 piu' i suoi parametri +towgs84 (v. sopra).

> e' doveroso ricordare che provengono da GRASS (il progetto piu' serio
> ed autorevole che abbiamo, nonche' quello con la tradizione piu' lunga) ;-)

...che, a sua volta, immagino le abbia ricavate da EPSG! :)

> note:
> -----
> 1) dato che sono "definizioni custom" (== non standard) devono avere
> valori SRID > 32678; progetti/sw diversi potrebbero anche usare
> legittimamente valori differenti, visto che siamo fuori standard.

ok

> 2) dato che *non* provengono da EPSG, l'auth_name non puo' essere EPSG;
> la scelta di spatialite e' di usare auth_name:gfoss.it, ma potrebbe
> essere altrettanto appropriato usare p.es. auth_name:grass
> l'importante e' che comunque venga indicata un'autorita' che si assume
> la responsabilita' di quella definizione (e ripeto: non puo' e non
> deve essere epsg).

auth_name:gfoss.it mi pare piu' che ragionevole

> 3) off topics (ma non tanto): p.es. il buon Alessandro Frigeri si sta
> divertendo da molti mesi con i suoi SRS "robe dell'altro mondo".
> esistono definizioni Proj4 anche per i vari pianeti e satelliti
> maggiori del sistema solare (Luna, Marte, Venere, Ganimede ...)
> IMHO sarebbe decisamente opportuno incorporare anche gli SRS
> extra-terrestri nella nostra filiera standard.
> e non sarebbe affatto difficile implementarli, sempre usando il
> solito meccanismo auth_name+auth_srid visto sopra.

questi sistemi, a meno di nuove recenti definizioni, dovrebbero gia' far
parte del database IAU2000, dove IAU sta per International Astronomic
Union: http://spatialreference.org/ref/iau2000/

> 4) personalmente non credo che incorporare tutte queste definizioni
> "custom" (extra standard EPSG) direttamente all'interno del file
> EPSG che accompagna GDAL/Proj4 sia una buona idea.
> Se tutte le nazioni del mondo iniziassero a pretendere di vedersi
> supportate le proprie sub-regioni assisteremmo ad una proliferazione
> indiscriminata degli SRS, a tutto danno della chiarezza e della
> semplicita' d'uso.

D'accordissimo. E' bene definire un file a parte (gfossit) seguendo la
struttura di tutti gli altri gia' presenti (epsg, esri, nad27, nad83, ecc.).

> 5) c'e' infine un ultimo problema: l'attuale formato del file EPSG
> non supporta affatto auth_name ed auth_srid.
> e quindi non e' affatto adeguato per supportare le estensioni custom.

Se ti riferisci ai file di definizione di Proj4, all'interno e' anche
possibile inserire dei commenti preceduti da # (v. ad es. il file 'world').
Meglio di niente.

> 6) credo quindi che la via giusta da seguire sia quella di definire
> un banale formato standard (che supporti auth_name/auth_srid, cosa
> che attualmente non e'). dopo di che i vari "pacchettini nazionali"
> potrebbero essere distribuiti a parte (un po' come avviene per i
> plugins): chi e' interessato se li carica, eventualmente scegliendo
> solo quelli di suo diretto interesse.
> evidentemente i vari progetti dovrebbero supportare un meccanismo
> che consenta l'estensione delle definizioni custom; ma pare compito
> veramente triviale e facilissimo.
>
> ciao Sandro
>

ciao
Antonio

-- 
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano