id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,cpu,platform 247,"m.proj: mind that if input points are XYZ rather than XY, cs2cs will include Z in transfomartion",msieczka,grass-dev@…,"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. ",defect,new,normal,6.4.6,Projections/Datums,svn-develbranch6,,m.proj,,All,All