Javier,
I don't think that can be done directly in PROJ. That would somehow
require a "add" operator using coordinates pushed on the stack. Or maybe
some super convoluted trickery abusing some of our existing operators,
but nothing comes to mind.
No magic then: I would probably write custom code that would create a
grid from ETRS89 to the final CRS (the geographic CRS of it), with
roughly the resolution of the grid in TM07, applying "at hand" the 4
steps to compute the shift in the lat/long space for all grid cells
(using PROJ for some of the individual steps and Python to make the
addition).
Even
Le 14/02/2025 à 17:50, Javier Jimenez Shaw a écrit :
Hi Even.
The example in data/sql/transformations_czechia_extra.sql was very useful.
First I am trying to reproduce the transformation with a pipeline, and
later I will make the proper operations and concatenated operations in
the database.
However this Greek transformation is more convoluted than I expected
(initially I misunderstood some steps).
a) First they have a Helmert from ETRS89 (from their realization, but
I do not care) to GGRS87. So far so good (params are not the ones from
EPSG, but no problem)
b) Then they apply the transverse Mercator to "GGRS87 / Greek Grid".
All fine.
c) In parallel they project ETRS89 coordinates into a different
transverse Mercator, called TM07 (not in EPSG; they provide the
params). The grid with the horizontal corrections are in TM07
d) the final projected coordinates in "GGRS87 / Greek Grid" are the
values from b) plus the corrections from the grid in c)
See that the easting-northing coordinates to get the correction from
the grid are not the same as the coordinates from b). To make it
clear, TM07 has a false-northing of -2000 km
How can it be done in a pipeline? (later to be converted into
something in proj.db)
I do not know how to keep the corrections somewhere to be added later
to the projected coordinates.
Thanks
Javier
On Mon, 3 Feb 2025 at 16:54, Even Rouault <even.roua...@spatialys.com>
wrote:
Javier,
you can probably hack around BOUNDCRS in a totally PROJ-specific
way by using the "METHOD["PROJ-based operation method:
{proj_pipeline_here}"
Otherwise having records in the DB will certainly be cleaner.
data/sql/transformations_czechia_extra.sql can probably be used as
an example of quite advanced transformations, including using a
grid referenced in a projected CRS.
Even
Le 03/02/2025 à 16:26, Javier Jimenez Shaw via PROJ a écrit :
Hi
I am trying to make this transformation (that is not in EPGS). I
do not know how far I can go with PROJ.
(Apparently this transformation is needed to go from the
coordinates used by HEPOS.gr, the Greek positioning system, to
the official -I think- CRS in Greece, GGRS87.
The best is that the transformation would be in EPSG. Do you know
anybody in Greece with the proper contacts? I am happy to talk
with them about it, and help if needed)
Until it is in EPSG, I would like to use PROJ to do it.
The accurate transformation from ETRS89 to GGRS87 is something like:
- apply a Helmert transformation
- Project into a transverse Mercator
- Apply a correction grid. Yes, in the projected system.
- (optional) go back from the projected to the geographic crs.
I thought about several options:
- First option: create a WKT2 with a BOUNDCRS that defines the
transformation. Can it be done in a single WKT2?
- Second option: add the transformation to proj.db. Is it doable?
- Third option: Create "my own grid" file (in the geographic
system) combining all the steps. Of course, it will loose some
accuracy due to the new grid interpolation.
Any clue?
Thanks.
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
