[PROJ] Helmert and coordinate convertion question
Søren Holm
sgh at sgh.dk
Thu Nov 17 00:32:20 PST 2022
ok, excellent.
Den 17.11.2022 kl. 09.09 skrev Kristian Evers:
> 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