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

[Markus Neteler]

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