Re: Proposal for a geodetic deformation model format
Chris Crook <[email protected]> Thu, 5 Dec 2019 18:00:30 +0000
| Newsgroups | gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <A87E66F06E86F14B857F2EB047CDF9323148BA31@prdassexch01.ad.linz.govt.nz> |
Hi Martin Thanks for your comments. Who is the intended audience? Short answer is anyone interested! From our (LINZ) point of view our primary motive is to get something going, and having it working in PROJ/GDAL would be a huge step forward. The GeoTIFF format provides us the opportunity to do that, as without that there is not a suitable grid format available to build the general deformation model with. As you rightly say there is also a lot value in a standardisation process with OGC, though of course that is a (much much) longer process. Certainly that is something that elements of this could feed in to. It could end up with something similar to this, in which case it would be great for us, or it may end up with something different, in which case it wouldn't work with the current LINZ deformation model in any case. Either way it is useful for us to have this capability now. So initially the audience is anyone else who thinks they might use it, and particularly anyone who thinks they could use it, but it would need to be just a bit different for it to work for them. Primarily I imagine that would be from geodetic agencies who are using or developing deformation models. I did forwarded the proposal to the IAG working group on time dependent datums. On HDF5 vs GeoTIFF.. As you rightly say apart from some details this proposal is largely format agnostic. I know the ESRI GGXF initiative is now proposing using HDF5, and certainly that could serve as well. Curiously I did propose HDF5 as an option for deformation models a while ago, but at that time there wasn't much appetite for using it as (IIRC) it wasn't so well suited to deploying with online web services, From a PROJ point of view GeoTIFF will already be there. Using HDF5 would add another huge dependency. The choice of multiple/single file implementation was a surprise for me, as I've been wanting to come up with a single file implementation for a long time. But I found as I was developing this proposal that there seemed to be more advantages to a multiple file implementation. Because GeoTIFF provides the nested grid capability the number of files is not excessive (unlike the LINZ publication format as individual grids). One advantage is that different versions of the deformation model will only differ in a few of the component files. Most would be common to the versions, so using a multiple file implementation allows these to be shared. Cheers Chris ________________________________________ From: PROJ [[email protected]] on behalf of Martin Desruisseaux [[email protected]] Sent: Thursday, 5 December 2019 10:52 p.m. To: [email protected] Subject: Re: [PROJ] Proposal for a geodetic deformation model format Hello Chris Thanks for the proposal, I had a quick look on it. The explanation about rational, required metadata, etc. are very nice. My first question would be who is the intended audience. Is it a proposal for the PROJ/GDAL community, or e.g. a starting point for standardization at OGC? The reason why I ask is because in my understanding, the choice of GeoTIFF format for PROJ/GDAL is based on pragmatic reasons specific to that community (close connection between GDAL and GeoTIFF since they are maintained by the same peoples; more familiarity with GeoTIFF than with HDF5 and CF-Conventions). They are valid reasons for PROJ/GDAL, but if the target audience is wider then I would suggest to reconsider since, if it was not for PROJ/GDAL convenience, I think HDF5 + CF-Conventions (i.e. NetCDF 4) would be more appropriate for those kind of data. However a "GeoTIFF versus HDF5" discussion could be left for a separated thread. The vast majority of the proposal document would still apply in both formats, except the discussion about single versus multiple files which would not be needed anymore. Some attributes like "extent_east", "extent_north" would be revisited in a HDF5 format because they overlap (but are not identical) with standard CF-Conventions attributes, but the ideas would still the same. Regards, Martin _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj ________________________________ This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [email protected]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj