<div dir="ltr"><div>I have already asked the SLA in Singapore. Let's see what happens.</div><div><br></div><div>If I identified it as "PROJ:SVY21_3D", and later they update EPSG with, let's say, "EPSG:100"<br></div><div>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"?</div><div>I don't know if the table "alias_name" is for that purpose, or only to updated names.</div><div><br></div><div>(the question is not only for the geographic 3D in Singapore. I am thinking on other missing CRSs in EPSG, like vertical reference systems)<br></div><div><br></div><div>Thanks.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Mar 2024 at 17:14, Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com">j1@jimenezshaw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Even.</div><div><br></div><div>Until I move this with the SLA, the workaround of a new entry in geodetic_crs works fine (and the corresponding in usage)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2024 at 15:43, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Javier,<br>
> I am trying to add a geoid model for Singapore to my proj.db.<br>
> The problem is that the "source crs", SVY21 (EPSG:4757), is only <br>
> defined as Geographic 2D in EPSG<br>
> <a href="https://spatialreference.org/ref/?search=SVY21" rel="noreferrer" target="_blank">https://spatialreference.org/ref/?search=SVY21</a><br>
><br>
> If I add something like this (copied from other cases in <br>
> grid_transformation_custom.sql)<br>
><br>
> INSERT INTO "grid_transformation" VALUES(<br>
>     'PROJ','EPSG_4757_TO_EPSG_6916','SVY21 to SHD height',<br>
>     NULL,<br>
>     'EPSG','9665','Geographic3D to GravityRelatedHeight (gtx)',<br>
>     'EPSG','4757', -- source CRS (SVY21)<br>
>     'EPSG','6916', -- target CRS (SHD height)<br>
>     NULL,<br>
>     'EPSG','8666','Geoid (height correction) model file','SGeoid09.tif',<br>
>     NULL,NULL,NULL,NULL,NULL,NULL,NULL,0);<br>
><br>
> I get an error:<br>
> One grid_transformation with Geographic3D to GravityRelatedHeight or <br>
> Geog3D to Geog2D+XXX has not its source_crs in geodetic_crs table with <br>
> type = 'geographic 3D'<br>
><br>
> I am using the method 9665 ... just because I am used to it. I could <br>
> use a different one. But I see that all available methods are <br>
> expecting a geographic 3D as source... that will trigger the same error.<br>
Geoid models make only sense between a Geographic 3D CRS  and a Vertical <br>
CRS or Geog 2D CRS + Vertical CRS, so the check here is relevant. You <br>
need an ellipsoidal height at the source end. You could try to remove <br>
the check, but I don't think that's a good idea. I'm pretty sure there's <br>
logic in different places of the code that expect a Geographic 3D CRS in <br>
that situation.<br>
><br>
> Is there any way to workaround this condition?<br>
><br>
> Asking SLA to add a 3D system to EPSG is one way... but I would like <br>
> to have a solution earlier (or in case they just don't do it).<br>
<br>
Would be the preferred solution, and also a record for their geoid model<br>
<br>
Your workaround pending that is to add an entry in the geodetic_crs <br>
table (under the PROJ authority for now) to create a Geographic 3D CRS <br>
companion to EPSG:4757.<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>
</blockquote></div>