[GRASS-dev] v.proj transforming z co-ordinates
Paul Kelly
paul-grass at stjohnspoint.co.uk
Wed Aug 30 12:18:41 EDT 2006
Ha ha I was hoping I wouldn't have to make that decision! Well it does
change functionality (in certain cases), but 6.2 is a major change in
version number so perhaps that is OK. And anyway it is a bugfix. So I
would say yes.
Paul
On Wed, 30 Aug 2006, Markus Neteler wrote:
> Hello Paul,
>
> do you want me to merge that to the 6.2-release branch?
>
> Markus
>
> On Wed, Aug 30, 2006 at 04:27:38PM +0100, Paul Kelly wrote:
>> 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 *
>>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>
> --
> Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
> ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
> MPBA - Predictive Models for Biol. & Environ. Data Analysis
> Via Sommarive, 18 - 38050 Povo (Trento), Italy
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>
More information about the grass-dev
mailing list