[Gfoss] [gdal-dev] EPSG 8.0 Upgrade

FYI

---------- Forwarded message ----------
From: Frank Warmerdam <warmerdam@pobox.com>
Date: Thu, Dec 6, 2012 at 1:18 AM
Subject: [gdal-dev] EPSG 8.0 Upgrade
To: “PROJ.4 and general Projections Discussions” <proj@lists.maptools.org>, GeoTIFF <geotiff@lists.maptools.org>, gdal-dev <gdal-dev@lists.osgeo.org>, “metacrs@lists.osgeo.org” <metacrs@lists.osgeo.org>

Folks,

At the request of Howard Butler, I have upgraded PROJ.4, libgeotiff, and
GDAL to use the EPSG 8.0 database in development “trunk”.

This was accomplished, as usual based on the process described here:

http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

Amoung other things this will result in some datums having new preferred
datum shift solutions. Upgrade with care.

Best regards,

---------------------------------------±-------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush | Geospatial Software Developer


gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Margherita DI LEO

Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

On Thu, Dec 06, 2012 at 11:29:16AM +0100, Margherita Di Leo wrote:

Amoung other things this will result in some datums having new preferred
datum shift solutions. Upgrade with care.

Faccio notare che l'aggiornamento di proj successivo alla 4.7 - poi propagato
in tutto il software come gdal o grass che eredita le tabelle di datum
relative - introduce una differenza significativa nella gestione dei datum: in
ogni versione viene sostanzialmente preferita l'indicazione di una
materializzazione preferenziale rispetto a una indicazione _neutra_ (nodatum).
La scelta del 'preferenziale' può cambiare a seconda della versione di tabella
in base a considerazioni puramente locali (in questo CRS si preferisce in
media X piuttosto di Y e gli estensori delle tabelle se ne rendono conto
successivamente).

Questa cosa è da considerare attentamente nelle applicazioni e motiva la
frase di Frank. In particolare a parità di codice EPSG la materializzazione
può cambiare significativamente a seconda della versione di proj considerata.

IMHO questo approccio è una gran kazaka, ma cosa fatta capo ha...

--
Francesco P. Lovergine

Il 07/12/2012 11:51, Francesco P. Lovergine ha scritto:

IMHO questo approccio è una gran kazaka, ma cosa fatta capo ha...

davvero, sorprendente (con rispetto per i kazaki).
si e' capito cosa l'ha motivata? solo semplicita' d'uso per vari casi?
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

On Fri, Dec 07, 2012 at 12:00:36PM +0100, Paolo Cavallini wrote:

Il 07/12/2012 11:51, Francesco P. Lovergine ha scritto:

> IMHO questo approccio è una gran kazaka, ma cosa fatta capo ha...

davvero, sorprendente (con rispetto per i kazaki).
si e' capito cosa l'ha motivata? solo semplicita' d'uso per vari casi?
saluti.

Esatto, per un uso medio a medio livello di incosapevolezza. Si suppone
che gli esperti siano comunque in grado di gestire la problematica
correttamente, nei casi appropriati.

--
Francesco P. Lovergine