[PROJ] Helmert and coordinate convertion question
Kristian Evers
kreve at sdfi.dk
Thu Nov 17 00:09:22 PST 2022
Yes, I don't see any issues with that. Pull Requests are welcome.
I'm not sure an extension to noop is the best idea, it's probably
better to create new operation with a good descriptive name.
/Kristian
> -----Original Message-----
> From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Søren Holm
> Sent: 17. november 2022 08:35
> To: Kristian Evers <kristianevers at gmail.com>
> Cc: proj <PROJ at lists.osgeo.org>
> Subject: Re: [PROJ] Helmert and coordinate convertion question
>
> Kristian
>
> Thanks for the clafications. I will do the two-step approach but he
> noop-thing type convertion would be nice though. Is that something you
> believe could be merged if implemente properly?
>
> Den 17.11.2022 kl. 08.12 skrev Kristian Evers:
> >
> >> So what you are saying is that some of the operations by design are not
> supposed to be mixed - even if the number of outputs/inputs and unit (in
> this case meter) match....
> >>
> >
> > Correct. It’s not the number of coordinate components that matter, it’s the
> nature of them.
> > PROJ will complain if input and output types are mismatching between
> pipeline steps.
> >
> >> Anyway - the concrete case is this:
> >>
> >> We have an application utilizing proj to provide projected coordinates in
> DKTM, SWEREF, UTM and others. This is usualy fine but some of our user are
> used to be able to put a helmer on top of those transformations. I do no
> realy know why but overall it can be because they have some local origo or
> maybe they want one of the axises to align with a fence - It can be anything!
> >>
> >> They usualy formulate this as a transform (typically helmert 3D) of the
> projected coordinates. We can very well do this in an additional proj run but I
> woul rather have it in a single pass.
> >>
> >> I hope it makes sense.
> >>
> >
> > It doesn’t really. I understand what’s done but I’m not sure it’s a
> particularly smart way to
> > do things. Oh well, there might be a particular use case where a flow like
> that makes sense.
> >
> > We don’t have a good mechanism to do what you want in one go. A
> possible solution could
> > be a two-step approach that chains to transformations together:
> >
> >> echo 12 55 0 0 | cct +proj=utm +zone=32 | cct +proj=helmert +x=234
> +y=232 +z=234 +convention=coordinate_frame
> > 692109.6321 6099139.8250 234.0000 0.0000
> >
> > Effectively creating a pipeline buy bypassing PROJs in-build unit checks.
> Adjust the above accordingly.
> >
> > I guess we could implement a mechanism that does nothing but change the
> internal coordinate types
> > to what the user species. The above could then be redone like
> >
> >> echo 12 55 0 0 | cct +proj=pipeline +proj=utm +zone=32 +step
> +proj=noop +in_type=projected +out_type=cartesian +proj=helmert +x=234
> +y=232 +z=234 +convention=coordinate_frame
> > 692109.6321 6099139.8250 234.0000 0.0000
> >
> > It offers plenty of opportunity for users to shoot themselves in the foot but
> in the right hands it
> > could be useful I guess.
> >
> > /Kristian
> >
> >>
> >> Den 16.11.2022 kl. 16.32 skrev Kristian Evers:
> >>> Søren,
> >>> What you are proposing is borderline non-sensical. Maybe try to explain
> what you want
> >>> to achieve and we can try to find a good way to get you there.
> >>> PROJ has three types of coordinates:
> >>> 1. Geodetic coordinates
> >>> 2. Projected coordinates
> >>> 3. Cartesian coordinates
> >>> 1. is the classical latitude/longitude pair, 2 is any coordinate that is
> projected onto the plane
> >>> and 3 is a geocentric, cartesian representation of 1. Generally speaking 1
> and 2 are 2-dimensional
> >>> and 3 is 3-dimensional. There’s a bit more to if you want to include
> heights but let’s leave that out
> >>> for now.
> >>> Different kinds of operation expect different types of coordinates and
> can spit out coordinates in
> >>> another type. E.g. a projection expects a geodetic coordinate (i.e. a
> latitude/longitude pair) and
> >>> spits out a projected coordinate. Another example is the Helmert
> transformation which works
> >>> on cartesian coordinates (except in the 2D case) and therefore expects
> cartesian input and
> >>> outputs cartesian coordinates.
> >>> The Helmert operation has two general modes: 2D and 3D. The 2D mode
> is meant for direct
> >>> adjustment of grid coordinates, i.e. projected coordinates. This could be
> useful on a local engineering
> >>> CRS for instance. The 3D mode is a bit more generic and the main usage
> of the Helmert transformation.
> >>> It allows you to do geodetic transformations over a larger area and in a
> more complicated way. When
> >>> transforming coordinates from a global reference frame (e.g.
> WGS84/ITRF2014) to a regional frame
> >>> (e.g. ETRS89) we use a time-dependant 3D Helmert transformation.
> >>> The above explains why you can successfully feed projected coordinates
> into the 2D version of the
> >>> Helmert but not the 3D.
> >>> /Kristian
> >>>> On 16 Nov 2022, at 14.25, Søren Holm <sgh at sgh.dk> wrote:
> >>>>
> >>>> Thanks for the answer Kristian
> >>>>
> >>>> It does make sense, however I do not think it is what I want.
> >>>>
> >>>> I imagined something like this: WGS84 -> ETMERC -> HELMERT
> >>>>
> >>>> Funny thing is that a 2D helmert works just fine:
> >>>>
> >>>> +proj=etmerc .... +step +proj=helmert +convention=coordinate_frame
> ... +theta=12345
> >>>>
> >>>> A 3D helmert does not work - it just complains that the units are
> mismatching.
> >>>>
> >>>> Why do 2D helmert work when 3D helmert fails? - they both require
> cartesian coordinates. Etmerc outputs projected coordinates which makes it
> even more strange. The documentation does not say much about projected
> coordinates and why they are different from cartesian.
> >>>>
> >>>> Den 16.11.2022 kl. 12.56 skrev Kristian Evers:
> >>>>> Søren,
> >>>>> You simply add a step with the cart operation:
> >>>>> +proj=pipeline
> >>>>> +step +proj=etmerc +ellps=GRS80 +lat_0=0 +lon_0=20.25 +k=1
> +x_0=150000 +y_0=0 +inv
> >>>>> +step +proj=cart +ellps=GRS80
> >>>>> +step +proj=helmert +convention=coordinate_frame +...
> >>>>> I've removed superfluous parameters in the etmerc step and added a
> "+inv". The last bit
> >>>>> ensures that correct direction of the etmerc step. You wan't to go
> from projected
> >>>>> coordinates to geodetic coordinates. The cart step then converts the
> geodetic coordinates
> >>>>> to cartesian coordinates which can be consumes by the helmert
> operation.
> >>>>> You probably want to add more steps to bring your coordinates to a
> more usuable format
> >>>>> than cartesian, e.g.
> >>>>> +step +proj=cart +ellps=GRS80 +inv
> >>>>> +step +proj=....
> >>>>> Hope that clears things up.
> >>>>> /Kristian
> >>>>>> -----Original Message-----
> >>>>>> From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Søren
> Holm
> >>>>>> Sent: 15. november 2022 16:00
> >>>>>> To: proj <PROJ at lists.osgeo.org>
> >>>>>> Subject: [PROJ] Helmert and coordinate convertion question
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> I'm scratching my head here.
> >>>>>>
> >>>>>> How do I convert the projected coordinates from the etmerc step
> into
> >>>>>> cartessian coordinates for the helmert step ?
> >>>>>>
> >>>>>> cct +proj=pipeline +step +proj=etmerc +ellps=GRS80 +lat_0=0
> +lon_0=20.25
> >>>>>> +k=1 +x_0=150000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0
> +units=m
> >>>>>> +no_defs +step +proj=cart +ellps=GRS80 +step +proj=helmert
> >>>>>> +convention=coordinate_frame
> >>>>>>
> >>>>>>
> >>>>>> Thanks in advance.
> >>>>>>
> >>>>>> /Søren Holm
> >>>>>> _______________________________________________
> >>>>>> PROJ mailing list
> >>>>>> PROJ at lists.osgeo.org
> >>>>>> https://lists.osgeo.org/mailman/listinfo/proj
> >>>> _______________________________________________
> >>>> PROJ mailing list
> >>>> PROJ at lists.osgeo.org
> >>>> https://lists.osgeo.org/mailman/listinfo/proj
> >
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
More information about the PROJ
mailing list