[GRASS-dev] v.proj transforming z co-ordinates

Paul Kelly paul-grass at stjohnspoint.co.uk
Wed Aug 30 11:27:38 EDT 2006


OK I have committed the change now.

In the longer term I think this is an area we could start to think about 
vertical datum support for. Helena has mentioned it on the list before but 
I could never see an easy way to associate a particular property of a 
raster or vector map with it being elevation data. But it could certainly 
be done on a per-map basis for 3-D vectors.
Just a vague thought for the future.

Paul

On Wed, 30 Aug 2006, Martin Landa wrote:

> Hi,
>
> me too... would be committed to CVS?
>
> Martin
>
> 2006/8/27, David Finlayson <david.p.finlayson at gmail.com>:
>> I agree with your proposal.
>> 
>> 
>> On 8/26/06, Paul Kelly <paul-grass at stjohnspoint.co.uk> wrote:
>> >
>> I suspected v.proj was doing this for years (since the introduction of the
>> new vector format) but never got round to verifying the behaviour until
>> yesterday. When re-projecting a 3-D vector file, if datum transformation
>> parameters are specified using towgs84= notation (rather than nadgrids=),
>> v.proj will assume the z co-ordinates are ellipsoidal heights and
>> transform them accordingly.
>> 
>> I think there are probably very few circumstances in which this behaviour
>> would be desirable. It is much more common for height data to be specified
>> relative to a vertical datum, e.g. mean sea level, than relative to the
>> ellipsoid (which is normally only used for horizontal distances).
>> 
>> GPS data is more likely to include ellipsoidal height, but again it is
>> (IMHO) of questionable usefulness to transform it to another ellipsoid:
>> the geoid models that exist to transform GPS data to the local vertical
>> datum in regular use (OSGM02 for Great Britain and Northern Ireland is the
>> one I'm familiar with) convert directly from WGS84 ellipsoidal height data
>> to height above mean sea level.
>> 
>> I propose the attached patch to add a specific flag to v.proj to enable
>> the current behaviour, otherwise the z co-ordinates are always left
>> untouched. I thought it was worth explaining and discussing properly
>> because it changes the current behaviour and will give different results
>> in certain circumstances, but IMHO the current behaviour is wrong.
>> 
>> Any comments?
>> 
>> Paul
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>> 
>> 
>> 
>> 
>> 
>> --
>> David Finlayson
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>> 
>> 
>
>
> -- 
> Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
>




More information about the grass-dev mailing list