definizioni EPSG GB 3003 / 3004 e dintorni

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

definizioni EPSG GB 3003 / 3004 e dintorni

a.furieri
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.


------------------------------------------
srid:40000
auth_name:gfoss.it
auth_srid:1
ref_sys_name:Italy mainland zone 1 GB Roma40
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:Italy mainland zone 2 GB Roma40
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:Italy Sardinia GB Roma40
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:Italy Sicily GB Roma40
proj4text:+proj=tmerc +lat_0=0 +lon_0=9  +k=0.9996 +x_0=1500000 \
     +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.
e' doveroso ricordare che provengono da GRASS (il progetto piu' serio
ed autorevole che abbiamo, nonche' quello con la tradizione piu' lunga)
;-)

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.

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).

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.

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.

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.

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

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[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.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: definizioni EPSG GB 3003 / 3004 e dintorni

Antonio Falciano
Il 21/05/2012 11.41, [hidden email] 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
_______________________________________________
[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.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: definizioni EPSG GB 3003 / 3004 e dintorni

a.furieri
On Mon, 21 May 2012 13:25:27 +0200, Antonio Falciano wrote:

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

eccellente: personalmente lo ignoravo.
Antonio, grazie per avercelo segnalato: te lo dicevo che io sono
assolutamente 'gnurante ;-)


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

per un operatore "umano", concordo.
ma se ipotizziamo un tool/funzione che faccia parsing automatico tirare
ad
indovinare in base ai commenti non e' proprio il top ;-)
introdurre colonne apposite e' sicuramente una soluzione piu' robusta.

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[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.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: definizioni EPSG GB 3003 / 3004 e dintorni

giohappy
Concordo pienamente riguardo l'utilità d'avere un campo per
l'autorità, almeno, e uno con il codice interno del CRS.
Magari avrebbe aiutato anche a discernere se 900913 fosse un codice
ufficiale EPSG (e che di fatto non lo è mai stato).

Non so che impatto avrebbe sul codice delle Proj, ma immagino che non
sarebbe particolarmente impattante.

giovanni

Il 21 maggio 2012 13:36,  <[hidden email]> ha scritto:

> On Mon, 21 May 2012 13:25:27 +0200, Antonio Falciano wrote:
>>>
>>> 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/
>>
>
> eccellente: personalmente lo ignoravo.
> Antonio, grazie per avercelo segnalato: te lo dicevo che io sono
> assolutamente 'gnurante ;-)
>
>
>
>>> 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.
>>
>
> per un operatore "umano", concordo.
> ma se ipotizziamo un tool/funzione che faccia parsing automatico tirare ad
> indovinare in base ai commenti non e' proprio il top ;-)
> introdurre colonne apposite e' sicuramente una soluzione piu' robusta.
>
>
> ciao Sandro
>
> --
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
>
> _______________________________________________
> [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.
> 584 iscritti al 7.4.2012
_______________________________________________
[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.
584 iscritti al 7.4.2012