[gdal-dev] Re: Slovenia vector data reprojection issue
neteler at osgeo.org
Wed Mar 31 13:38:19 EDT 2010
On Wed, Mar 31, 2010 at 6:52 PM, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Markus Neteler wrote:
>> (back to an old problem)
>> On Fri, Jul 24, 2009 at 4:31 PM, Markus Neteler <neteler at osgeo.org> wrote:
>>> I am trying to reproject Slovenian country data from D48 (WKT attached)
>>> and Italian ISTAT national vector data (UTM32/ED50) into a common
>>> While the map "attach" rather well in Latlong/WGS84 using GDAL 1.6.svn,
>>> they don't in EU LAEA (EPSG 3035). This is a bit suprising for me.
>>> Any trick to get this done?
>>> The input SHAPE files have each a .prj file (attached), the target SRS
>>> I request by -t_srs epsg:4326 or -t_srs epsg:3035.
>>> My preferred SRS would be EU LAEA to match the EU CORINE data.
>> It appears to be a bug in GDAL.
>> If I do
>> * SLO -> EU LAEA
>> the result is shifted, apparently the TOWGS84 in epsgD48_3787.prj is
>> not applied.
>> If I do instead:
>> * SLO -> LL -> EU LAEA
>> the result is "perfect".
> The problem is that the eu_etrs89_laea.prj does not have TOWGS84
> parameters for the datum, so if you go directly from D48 to laea
> no datum shifting will be done (since one end is not datum enabled).
Ah - I didn't realize this.
> If you go to WGS84 first, then the D48 datum shift is applied to WGS84.
> No datum shift is applied from WGS84 to the LAEA projection, but ETRS89
> is effectively the same as WGS84 I believe.
Yes, I think so.
> So the key is to mark the ETRS89 datum as equal to WGS84 - likely with a
> TOWGS84[0,0,0] entry in the coordinate system definition.
OK, I'll prepare accordingly my ETRS89 .prj template to avoid this
problem in future
with my current GDAL 1.7.svn installation.
[ I wonder if gdal* could say that the datum shift was omitted to
wake up the user...]
> I see that after my datum overhaul, GDAL is expanding EPSG:4258 to:
> SPHEROID["GRS 1980",6378137,298.257222101,
> which has the TOWGS84 entry, so we can have confidence that this
> family of problem will be reduced as the richer set of datum shifts
> comes out with GDAL 1.8.
> In short, I think this is an understood situation and there is no
> need for a ticket.
Perfect. Thanks for the explanations,
More information about the gdal-dev