[Proj] Understanding 2D Helmert

[Andre Joost]

Kristian,

if you register to the website I mentioned earlier, you get those plain 
text files, 385 kB uncompressed for both directions. For use in PROJ you 
would need an official grant to redistribute them. Looking into the 
files, it looks like a 6-parms affine transformation instead of simple 
Helmert 2D with 4 parameters.

The main difference to current ntv2-like horizontal grids is that this 
method transforms from projected coordinates to projected coordinates, 
instead of reprojecting to degrees, transforming, and reprojecting to a 
new projected CRS. So you have to code something new anyhow.

Would be a nice idea for GSOC, if someone is interested to dive into it.

Greetings,
Andre Joost

Am 29.10.18 um 08:36 schrieb Kristian Evers:
> Even,
>
> I wasn't suggesting that this was something you should take on. Your
> comment just peaked my interest as I have been pondering this problem
> before.
>
> A gridded solution would definitely be the easiest to implement, but not
> necessarily the most satisfactory. I for one would always prefer a solution
> as close to the original transformation definition as possible.
>
> It would probably also be possible to invent a simple text based file format
> for storing the triangles and their related parameters. This would be sort
> of equivalent to a grid file that can be linked to in the database. Is the
> current setup geared for something like that, or is it strictly reserved for
> grid files?
>
> /Kristian
>
> -----Oprindelig meddelelse-----
> Fra: Even Rouault <even.rouault at spatialys.com>
> Sendt: 28. oktober 2018 17:46
> Til: proj at lists.maptools.org
> Cc: Kristian Evers <kreve at sdfe.dk>; Andre Joost <andre+joost at nurfuerspam.de>
> Emne: Re: [Proj] Understanding 2D Helmert
>
> On dimanche 28 octobre 2018 15:02:05 CET Kristian Evers wrote:
>> Why is that? To me it seems somewhat similar to polynomial mappings
>> (Horner), in the way that many coefficients are likely to be stored for a
>> given transformation. Given a clever way of defining the triangles and
>> their corresponding Helmet parameters I think it should be possible to make
>> these transformations work. At least as PROJ strings.
>
> You would need to store hundreds of triangles and their parameters, and have
> PROJ figure out in which triangle a point it. Certainly doable, but not
> directly in the scope of my current work.  And avoid the database to grow too
> big with very particular transforms. That said, 600 triangles with 6 double
> parameters each + the x,y coordinates is just 38.4 KB if you store that as a
> compact binary blob. Some balance to know if it is something acceptable in-db
> (EPSG style transformations have at most 18 parameters each) or out-db
> (grids). The suggestion for the grid approach was to make it more immediatly
> usable.
>