#247: m.proj: mind that if input points are XYZ rather than XY, cs2cs will
include Z in transfomartion
----------------------+-----------------------------------------------------
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Keywords: | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Take for example such 3 points (Z is elevation a.s.l. in meters):
{{{
16 52 64
16.00083333 52 63
16.00166667 52 62
}}}
The source CRS is:
+proj=longlat +ellps=krass
+towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84
and target CRS:
+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000
+ellps=GRS80 +units=m
As the datums differ, cs2cs (m.proj) result will differ depending if Z is
included or not in the input, because cs2cs takes the Z coordinate for
ellipsoidal height. Since my Z coordinate is a.s.l., not ellipsoidal, this
will introduce an error.
cs2cs result when Z is there in the input:
{{{
568525.00043548 5761469.34143594 103.09038265
568582.20740863 5761470.12874655 102.08903865
568639.41506476 5761470.91672242 101.08769464
}}}
And without Z:
{{{
568524.99893752 5761469.34103610 39.09043643
568582.20593408 5761470.12835296 39.08909159
568639.41361362 5761470.91633507 39.08774674
}}}
There is a slight difference in XY, which one might argue is neglectable,
yet the bogus Z transformation might get the user into real trouble if he
still treats the data as 3D after transformation.
There was a similar issue in v.proj with 3D data, and it was solved by
adding a switch, but this can't be done for m.proj because there is no way
in cs2cs to prevent it from processing the Z coord in input.
m.proj should propably refuse to process data with more than 2 columns.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/247>
GRASS GIS <http://grass.osgeo.org>