<div dir="ltr">I just pointed to them as an example - primarily because the USNA site does.<br><br>I will remove the example from the post as potentially confusing ...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Sept 2022 at 11:03, Even Rouault <<a href="mailto:even.rouault@spatialys.com">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">Paul,<br>
<br>
Great post.<br>
<br>
I've noticed you point to the <a href="https://www.agisoft.com/downloads/geoids/" rel="noreferrer" target="_blank">https://www.agisoft.com/downloads/geoids/</a> <br>
page which mentions they use the PROJ GTG format. A lot of their files <br>
have the same names as the ones provided by <a href="https://cdn.proj.org/" rel="noreferrer" target="_blank">https://cdn.proj.org/</a> , but <br>
they are not exactly the same... Looking at au_ga_AUSGeoid98.tif, it <br>
appears they have reprocessed them to modify the TIFFTAG_COPYRIGHT <br>
(removing the license information) and TIFFTAG_IMAGEDESCRIPTION. Also <br>
adding the nodata value tag (PROJ grids only contain it when they are <br>
actual grid values at the nodata value). And more annoying they have <br>
also modified the GDAL_METADATA tag in a way it is not currently <br>
understood by current GDAL versions (adding the <?xml version="1.0" <br>
encoding="UTF-8"?> marker before the root <GDALMetadata> element, <br>
whereas GDAL expects the string to start directly with <GDALMetadata>), <br>
so the GTG specific metadata is hidden. I'm going to fix the GDAL <br>
GeoTIFF reader to be more robust to that.<br>
<br>
I've also noticed that the dk_sdfe_dvr90.tif file they provide is quite <br>
different from the PROJ CDN: it has not the same extent and spatial <br>
resolution.<br>
<br>
A bit annoying to reuse the same file names as the ones we provide but <br>
with different content.<br>
<br>
Anyway this is rather for any Agisoft employee reading this email....<br>
<br>
Even<br>
<br>
Le 28/09/2022 à 10:06, Paul Harwood a écrit :<br>
> This is not a question but a request.<br>
><br>
> I had to work out an API to convert from GPS coordinates to Height <br>
> above MSL. Having made it work, I wrote a blog post about the <br>
> solution, since I like to document things. I have posted it here for <br>
> three reasons :<br>
><br>
>  1 As a thank you to the team. The simplicity of the actual solution <br>
> shows just how good PROJ is!<br>
><br>
> 2 In case you want a good laugh, and<br>
><br>
> 3 more seriously, given the impressive competence on this list, I <br>
> would like to know if I have made any glaring (or even subtle) mistakes.<br>
><br>
> Thank you<br>
><br>
> <a href="https://medium.com/p/70b723767787" rel="noreferrer" target="_blank">https://medium.com/p/70b723767787</a><br>
><br>
> _______________________________________________<br>
> PROJ mailing list<br>
> <a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><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>