[GRASS-dev] [GRASS GIS] #247: m.proj: mind that if input points are XYZ rather than XY, cs2cs will include Z in transfomartion

GRASS GIS trac at osgeo.org
Wed Jul 30 14:32:04 EDT 2008


#247: m.proj: mind that if input points are XYZ rather than XY, cs2cs will
include Z in transfomartion
----------------------+-----------------------------------------------------
 Reporter:  msieczka  |       Owner:  grass-dev at 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>


More information about the grass-dev mailing list