[PROJ] geoid model from a geographic 2D

[Javier Jimenez Shaw]

I have already asked the SLA in Singapore. Let's see what happens.

If I identified it as "PROJ:SVY21_3D", and later they update EPSG with,
let's say, "EPSG:100"
is there a way to say to proj.db that they ("PROJ:SVY21_3D" and "EPSG:100")
are the same thing, and that my added one "PROJ:SVY21_3D" can be replaced
by the new "EPSG:100"?
I don't know if the table "alias_name" is for that purpose, or only to
updated names.

(the question is not only for the geographic 3D in Singapore. I am thinking
on other missing CRSs in EPSG, like vertical reference systems)

Thanks.

On Wed, 27 Mar 2024 at 17:14, Javier Jimenez Shaw <j1 at jimenezshaw.com>
wrote:

> Thanks Even.
>
> Until I move this with the SLA, the workaround of a new entry in
> geodetic_crs works fine (and the corresponding in usage)
>
> On Tue, 26 Mar 2024 at 15:43, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Javier,
>> > I am trying to add a geoid model for Singapore to my proj.db.
>> > The problem is that the "source crs", SVY21 (EPSG:4757), is only
>> > defined as Geographic 2D in EPSG
>> > https://spatialreference.org/ref/?search=SVY21
>> >
>> > If I add something like this (copied from other cases in
>> > grid_transformation_custom.sql)
>> >
>> > INSERT INTO "grid_transformation" VALUES(
>> >     'PROJ','EPSG_4757_TO_EPSG_6916','SVY21 to SHD height',
>> >     NULL,
>> >     'EPSG','9665','Geographic3D to GravityRelatedHeight (gtx)',
>> >     'EPSG','4757', -- source CRS (SVY21)
>> >     'EPSG','6916', -- target CRS (SHD height)
>> >     NULL,
>> >     'EPSG','8666','Geoid (height correction) model file','SGeoid09.tif',
>> >     NULL,NULL,NULL,NULL,NULL,NULL,NULL,0);
>> >
>> > I get an error:
>> > One grid_transformation with Geographic3D to GravityRelatedHeight or
>> > Geog3D to Geog2D+XXX has not its source_crs in geodetic_crs table with
>> > type = 'geographic 3D'
>> >
>> > I am using the method 9665 ... just because I am used to it. I could
>> > use a different one. But I see that all available methods are
>> > expecting a geographic 3D as source... that will trigger the same error.
>> Geoid models make only sense between a Geographic 3D CRS  and a Vertical
>> CRS or Geog 2D CRS + Vertical CRS, so the check here is relevant. You
>> need an ellipsoidal height at the source end. You could try to remove
>> the check, but I don't think that's a good idea. I'm pretty sure there's
>> logic in different places of the code that expect a Geographic 3D CRS in
>> that situation.
>> >
>> > Is there any way to workaround this condition?
>> >
>> > Asking SLA to add a 3D system to EPSG is one way... but I would like
>> > to have a solution earlier (or in case they just don't do it).
>>
>> Would be the preferred solution, and also a record for their geoid model
>>
>> Your workaround pending that is to add an entry in the geodetic_crs
>> table (under the PROJ authority for now) to create a Geographic 3D CRS
>> companion to EPSG:4757.
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240404/5419a386/attachment.htm>