Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Howard Butler]

> On May 26, 2021, at 8:33 PM, Nyall Dawson  wrote:
> 
> Can I make the suggestion that a subset of
> https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
> on its own? Specifically the commits which add the underlying API for
> GDAL to handle epochs should be controversy-free and suitable for
> merge outside of the larger/trickier question of patching in support
> to the data formats.

:thumbsup: 

As for the patching of data formats with GDAL application-specific metadata, as 
I said, I don't have a better option, but I'm satisfied if the process of 
writing epochs into metadata is opt-in (some kind of global CRS option? we 
already have magic switches like that).

Howard


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Even Rouault]

Hi,

- merging the underlying API without any format support is I believe of 
little interest. So I'll wait for at least one format (likely 
GeoPackage) to have merged in the master of their specification an 
official way of storing the coordinate epoch. I've also prepared an 
enhancement of the GeoTIFF spec regarding this 
(https://github.com/opengeospatial/geotiff/pull/99) that will likely be 
discussed at the next OGC GeoTIFF SWG meeting.


- I've just chatted with Howard and a good compromise could be that for 
formats that will have an official way of storing the coordinate epoch, 
we store it by default (when it is set), and for formats that we 
unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit 
GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set 
(default would be NO). We might revisit in the future the default value.


- On the vector side of things, things will probably get more 
complicated for some drivers, as it is likely that Spatialite (see 
https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE) or PostGIS 
might have per-geometry coordinate epoch, not at the layer level. But I 
don't think that would invalidate having support for it at the layer 
level (those database already support a per-geometry CRS, but GDAL 
support for that is probably lacking a bit in those drivers), as a 
OGRGeometry can potentially be associated with its own 
OGRSpatialReference object.


Even

Le 27/05/2021 à 15:01, Howard Butler a écrit :



On May 26, 2021, at 8:33 PM, Nyall Dawson  wrote:

Can I make the suggestion that a subset of
https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
on its own? Specifically the commits which add the underlying API for
GDAL to handle epochs should be controversy-free and suitable for
merge outside of the larger/trickier question of patching in support
to the data formats.

:thumbsup:

As for the patching of data formats with GDAL application-specific metadata, as 
I said, I don't have a better option, but I'm satisfied if the process of 
writing epochs into metadata is opt-in (some kind of global CRS option? we 
already have magic switches like that).

Howard



--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Sean Gillies via gdal-dev]

Hi all,

I've got a suggestion about limiting the number of formats.

GeoJSON and KML don't need support for a coordinate epoch. Both of these
are pretty cleared intended for low accuracy data (1-2 meters). KML and
GeoJSON don't support any CRS other than OGC:CRS84, which uses (it has been
pointed out many times) a datum ensemble that RFC 81 does not intend to
address. Right, Even? So let's leave these formats the way they are.

GML, GeoPackage, PostGIS, and the actively used raster formats like GeoTIFF
seem like the important ones to me.

On Thu, May 27, 2021 at 7:40 AM Even Rouault 
wrote:

> Hi,
>
> - merging the underlying API without any format support is I believe of
> little interest. So I'll wait for at least one format (likely
> GeoPackage) to have merged in the master of their specification an
> official way of storing the coordinate epoch. I've also prepared an
> enhancement of the GeoTIFF spec regarding this
> (https://github.com/opengeospatial/geotiff/pull/99) that will likely be
> discussed at the next OGC GeoTIFF SWG meeting.
>
> - I've just chatted with Howard and a good compromise could be that for
> formats that will have an official way of storing the coordinate epoch,
> we store it by default (when it is set), and for formats that we
> unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
> GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
> (default would be NO). We might revisit in the future the default value.
>
> - On the vector side of things, things will probably get more
> complicated for some drivers, as it is likely that Spatialite (see
> https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE) or PostGIS
> might have per-geometry coordinate epoch, not at the layer level. But I
> don't think that would invalidate having support for it at the layer
> level (those database already support a per-geometry CRS, but GDAL
> support for that is probably lacking a bit in those drivers), as a
> OGRGeometry can potentially be associated with its own
> OGRSpatialReference object.
>
> Even
>
> Le 27/05/2021 à 15:01, Howard Butler a écrit :
> >
> >> On May 26, 2021, at 8:33 PM, Nyall Dawson 
> wrote:
> >>
> >> Can I make the suggestion that a subset of
> >> https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
> >> on its own? Specifically the commits which add the underlying API for
> >> GDAL to handle epochs should be controversy-free and suitable for
> >> merge outside of the larger/trickier question of patching in support
> >> to the data formats.
> > :thumbsup:
> >
> > As for the patching of data formats with GDAL application-specific
> metadata, as I said, I don't have a better option, but I'm satisfied if the
> process of writing epochs into metadata is opt-in (some kind of global CRS
> option? we already have magic switches like that).
> >
> > Howard
> >
> >
>


-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Even Rouault]

Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are the 
same thing, except axis order), that's a good and hard question. 
Actually that extends to *any* CRS built on top of them, like all the 
EPSG:32[6|7][01-60] UTM CRS, and that's probably for those later than 
things are the most problematic since there's no EPSG code for a UTM WGS 
84 (G1762) CRS. I guess people would potentially want to attach a 
coordinate epoch to them, and have a (non-encoded-in-the-format) 
convention that they actually mean WGS 84 (G1762) (or possibly an 
earlier realization. The datum ensemble reality of WGS 84 is really due 
to Transit which differs significantly from later realizations, which 
are pretty consistent between them within a few centimers) . So I 
wouldn't forbid such uses (I actually got private feedback that some 
people would even want to store coordinate epoch for CRS that aren't 
considered by EPSG as dynamic CRS, but which, for advanced uses, can 
still have things like deformation models, like NAD83(2011) that is used 
for most people as a static CRS, but is more a snapshot of a dynamic CRS 
with a conventional reference epoch of 2010.0).


That said, I'll probably drop the commit for KML as it is clearly a 
hack, but I think support for GeoJSON, which is cleaner, could still be 
useful at some point as it is widely used as an exchange format. But 
I'll defer for GeoJSON until we see if the /OGC Features/ and 
/Geometries JSON/ SWG comes with something regarding this.


Even

Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :

Hi all,

I've got a suggestion about limiting the number of formats.

GeoJSON and KML don't need support for a coordinate epoch. Both of 
these are pretty cleared intended for low accuracy data (1-2 meters). 
KML and GeoJSON don't support any CRS other than OGC:CRS84, which uses 
(it has been pointed out many times) a datum ensemble that RFC 81 does 
not intend to address. Right, Even? So let's leave these formats the 
way they are.


GML, GeoPackage, PostGIS, and the actively used raster formats like 
GeoTIFF seem like the important ones to me.


On Thu, May 27, 2021 at 7:40 AM Even Rouault 
mailto:even.roua...@spatialys.com>> wrote:


Hi,

- merging the underlying API without any format support is I
believe of
little interest. So I'll wait for at least one format (likely
GeoPackage) to have merged in the master of their specification an
official way of storing the coordinate epoch. I've also prepared an
enhancement of the GeoTIFF spec regarding this
(https://github.com/opengeospatial/geotiff/pull/99
) that will
likely be
discussed at the next OGC GeoTIFF SWG meeting.

- I've just chatted with Howard and a good compromise could be
that for
formats that will have an official way of storing the coordinate
epoch,
we store it by default (when it is set), and for formats that we
unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
(default would be NO). We might revisit in the future the default
value.

- On the vector side of things, things will probably get more
complicated for some drivers, as it is likely that Spatialite (see
https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE
) or
PostGIS
might have per-geometry coordinate epoch, not at the layer level.
But I
don't think that would invalidate having support for it at the layer
level (those database already support a per-geometry CRS, but GDAL
support for that is probably lacking a bit in those drivers), as a
OGRGeometry can potentially be associated with its own
OGRSpatialReference object.

Even

Le 27/05/2021 à 15:01, Howard Butler a écrit :
>
>> On May 26, 2021, at 8:33 PM, Nyall Dawson
mailto:nyall.daw...@gmail.com>> wrote:
>>
>> Can I make the suggestion that a subset of
>> https://github.com/OSGeo/gdal/pull/3827
 could be created and be
merged
>> on its own? Specifically the commits which add the underlying
API for
>> GDAL to handle epochs should be controversy-free and suitable for
>> merge outside of the larger/trickier question of patching in
support
>> to the data formats.
> :thumbsup:
>
> As for the patching of data formats with GDAL
application-specific metadata, as I said, I don't have a better
option, but I'm satisfied if the process of writing epochs into
metadata is opt-in (some kind of global CRS option? we already
have magic switches like that).
>
> Howard
>
>



--
Sean Gillies

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Greg Troxel]

Even Rouault  writes:

> Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are
> the same thing, except axis order), that's a good and hard
> question. Actually that extends to *any* CRS built on top of them,
> like all the EPSG:32[6|7][01-60] UTM CRS, and that's probably for
> those later than things are the most problematic since there's no EPSG
> code for a UTM WGS 84 (G1762) CRS. I guess people would potentially
> want to attach a coordinate epoch to them, and have a
> (non-encoded-in-the-format) convention that they actually mean WGS 84
> (G1762) (or possibly an earlier realization. The datum ensemble

I think the real problem here is that the EPSG authority is not defining
the things that need to be defined, perhaps mostly because of a valid
concern about an exploding list.  (And partly because of the decision to
put datum and projection both in a codepoint, leading to the need for D
x P codes.)

Given the problem, at least until there is a solution to all instances
of it, I think it's far more reasonable to say that "WGS84" means
"WGS84(G1762)" (at the moment) when being read or written and to treat it
that way, placing the fuzz from the almost entirely theoretical
possibility that there is any data in WGS84(TRANSIT) onto the data and
away from the datum, and thus not harming everybody else.

Ideally, all standards that reference WGS84 would be fixed (GPX,
GeoJSON, TMS, geo: URIs) but until that happens it's the best way to
deal that I can think of.  Essentially, it's fixing them from the
outside by declaring that they mean the most recently realization.

So here's a challenge: Does anyone have data stored in a dataset labeled
WGS84 where that data is *actually in WGS84(TRANSIT)*?  Does anyone know
of the existence of such data?  Has anyone even heard a rumor that
someone else has that data?  If so, please describe the expected error
of the data, and how it is used in a proj/gdal/etc. pipeline and what
problems would occur from it being treated as WGS84(G1762) when being read.

Keep in mind that for someone to have such data, it has to be from a
non-differential navigation solution and will thus be subject to SA and
have a 100m expected error.  (I have seen such data from 1992 and it
really is that bad.)

> reality of WGS 84 is really due to Transit which differs significantly
> from later realizations, which are pretty consistent between them
> within a few centimers) . So I wouldn't forbid such uses (I actually
> got private feedback that some people would even want to store
> coordinate epoch for CRS that aren't considered by EPSG as dynamic
> CRS, but which, for advanced uses, can still have things like
> deformation models, like NAD83(2011) that is used for most people as a
> static CRS, but is more a snapshot of a dynamic CRS with a
> conventional reference epoch of 2010.0).

I haven't been saying that that I know of, but indeed NAD83(2011)
appears to me to be no longer a static datum, when looked at closely
enough.

> That said, I'll probably drop the commit for KML as it is clearly a
> hack, but I think support for GeoJSON, which is cleaner, could still
> be useful at some point as it is widely used as an exchange
> format. But I'll defer for GeoJSON until we see if the /OGC Features/
> and /Geometries JSON/ SWG comes with something regarding this.

As I see it, GeoJSON is two different formats.  One is the format GDAL
(and qgis) read and write, which does have an attached CRS.  Then
there's the one standardized by IETF which made the decision to not
include CRS and label it WGS84.   It seems the open geo world has
rejected that IETF decision and been happily reading and writing CRS.

I have been using GeoJSON to write data (that lives in a geopackage) as
NAD83(2011) and also as ITF2014 (as a proxy for WGS84(G1762) to avoid
incorrect null transforms), and that's been working fine, modulo the
WGS84 confusion.  So "GeoJSON is intrinsically low accuracy" is
incorrect.   Perhaps "GeoJSON without an expressed CRS is interpreted as
WGS84 which is a mess at the moment, at least in the open source
world".  But GeoJSON with a CRS does not in my view have any increased
problems compared to other formats.


As for opt in, I don't see the logic, if we have a notion now that a
dynamic CRS without an epoch will omit it and a dynamic CRS with an
explictly-set epoch will include it.  I think it's better for people to
maybe run into an issue that to have it silently dropped.  And, it seems
that the likely handling is for it to be ignored on reading, which is
functionally like omitting it on write.



signature.asc
Description: PGP signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[jratike80]

Hi,

The group description of Features and Geometries JSON SWG
https://www.ogc.org/projects/groups/featgeojsonswg does not mention dynamic
coordinate systems but I can at least try to add the topic into the agenda
in the kick-off on next Tuesday (2021-06-01) even I am just on observer in
the group.

-Jukka Rahkonen-



Even Rouault-2 wrote
> That said, I'll probably drop the commit for KML as it is clearly a 
> hack, but I think support for GeoJSON, which is cleaner, could still be 
> useful at some point as it is widely used as an exchange format. But 
> I'll defer for GeoJSON until we see if the /OGC Features/ and 
> /Geometries JSON/ SWG comes with something regarding this.


Even Rouault-2 wrote
> Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are the 
> same thing, except axis order), that's a good and hard question. 
> Actually that extends to *any* CRS built on top of them, like all the 
> EPSG:32[6|7][01-60] UTM CRS, and that's probably for those later than 
> things are the most problematic since there's no EPSG code for a UTM WGS 
> 84 (G1762) CRS. I guess people would potentially want to attach a 
> coordinate epoch to them, and have a (non-encoded-in-the-format) 
> convention that they actually mean WGS 84 (G1762) (or possibly an 
> earlier realization. The datum ensemble reality of WGS 84 is really due 
> to Transit which differs significantly from later realizations, which 
> are pretty consistent between them within a few centimers) . So I 
> wouldn't forbid such uses (I actually got private feedback that some 
> people would even want to store coordinate epoch for CRS that aren't 
> considered by EPSG as dynamic CRS, but which, for advanced uses, can 
> still have things like deformation models, like NAD83(2011) that is used 
> for most people as a static CRS, but is more a snapshot of a dynamic CRS 
> with a conventional reference epoch of 2010.0).
> 
> That said, I'll probably drop the commit for KML as it is clearly a 
> hack, but I think support for GeoJSON, which is cleaner, could still be 
> useful at some point as it is widely used as an exchange format. But 
> I'll defer for GeoJSON until we see if the /OGC Features/ and 
> /Geometries JSON/ SWG comes with something regarding this.
> 
> Even
> 
> Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :
>> Hi all,
>>
>> I've got a suggestion about limiting the number of formats.
>>
>> GeoJSON and KML don't need support for a coordinate epoch. Both of 
>> these are pretty cleared intended for low accuracy data (1-2 meters). 
>> KML and GeoJSON don't support any CRS other than OGC:CRS84, which uses 
>> (it has been pointed out many times) a datum ensemble that RFC 81 does 
>> not intend to address. Right, Even? So let's leave these formats the 
>> way they are.
>>
>> GML, GeoPackage, PostGIS, and the actively used raster formats like 
>> GeoTIFF seem like the important ones to me.
>>
>> On Thu, May 27, 2021 at 7:40 AM Even Rouault 
>> <

> even.rouault@

>   even.rouault@

> >> wrote:
>>
>> Hi,
>>
>> - merging the underlying API without any format support is I
>> believe of
>> little interest. So I'll wait for at least one format (likely
>> GeoPackage) to have merged in the master of their specification an
>> official way of storing the coordinate epoch. I've also prepared an
>> enhancement of the GeoTIFF spec regarding this
>> (https://github.com/opengeospatial/geotiff/pull/99
>> ;) that will
>> likely be
>> discussed at the next OGC GeoTIFF SWG meeting.
>>
>> - I've just chatted with Howard and a good compromise could be
>> that for
>> formats that will have an official way of storing the coordinate
>> epoch,
>> we store it by default (when it is set), and for formats that we
>> unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
>> GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
>> (default would be NO). We might revisit in the future the default
>> value.
>>
>> - On the vector side of things, things will probably get more
>> complicated for some drivers, as it is likely that Spatialite (see
>> https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE
>> ;)
>> or
>> PostGIS
>> might have per-geometry coordinate epoch, not at the layer level.
>> But I
>> don't think that would invalidate having support for it at the layer
>> level (those database already support a per-geometry CRS, but GDAL
>> support for that is probably lacking a bit in those drivers), as a
>> OGRGeometry can potentially be associated with its own
>> OGRSpatialReference object.
>>
>> Even
>>
>> Le 27/05/2021 à 15:01, Howard Butler a écrit :
>> >
>> >> On May 26, 2021, at 8:33 PM, Nyall Dawson
>> <

> nyall.dawson@

>   nyall.dawson@

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Nyall Dawson]

On Thu, 27 May 2021 at 23:40, Even Rouault  wrote:
>
> Hi,
>
> - merging the underlying API without any format support is I believe of
> little interest.

Well.. it would give users the command line tools to do static <->
dynamic transformation of data with the epoch specified in the command
line arguments. That's a quite compelling feature on its own, as it
could be used to transform data if the user has knowledge of the epoch
from other sources (e.g. in some pdf doc provided with the data, or if
they collected it themselves and know the correct epoch). I'm unaware
of any other tool (commercial or open source) which currently allows
this type of transformation.

Nyall
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev