[PROJ] Helmert and coordinate convertion question
Søren Holm
sgh at sgh.dk
Wed Nov 16 23:35:24 PST 2022
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
>
More information about the PROJ
mailing list