[PROJ] Helmert and coordinate convertion question

[Søren Holm]

Kristian,

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....

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.


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
>