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

[Even Rouault]

Hi,

I declare this motion passed with +1 from JukkaR and myself, -0 from 
HowardB and +0 from KurtS


I've issued a revision of my original pull request in 
https://github.com/OSGeo/gdal/pull/4011 that leaves out support for GML, 
KML, GeoJSON, Shapefile and GMLJP2 (JPEG2000 can still benefit from 
coordinate epoch through GeoJP2). So support is implemented for 
GeoPackage (the GeoPackage SWG adopted yesterday the proposed change), 
GeoTIFF (my proposal received good support so will eventually be added 
in the GeoTIFF 1.2 spec), FlatGeoBuf, VRT, PAM .aux.xml and the MEM drivers.


The OGR_CT_USE_SRS_COORDINATE_EPOCH config option can be set to NO to 
ignore the coordinate epoch coming from source or target CRS during 
coordinate transformations.


Even

Le 13/05/2021 à 11:44, Even Rouault a écrit :

Hi,

Motion:

adopt RFC 81: support for coordinate epochs in geospatial formats ( 
https://github.com/OSGeo/gdal/pull/3827 )


Starting with my +1

Even


--
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]

Even,

Sounds good. Until there is consensus on what coordinate epoch means for
OGC:CRS84 GeoJSON, the official and most widely used kind, I think it would
be better if GDAL didn't extend the format. For now, applications that need
more precision can and should use another format.

On Thu, May 27, 2021 at 12:19 PM Even Rouault 
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 
> 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

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

[jratike80]

Hi,

I guess that by "data" you mean datasets like GeoJSON file or GeoTIFF image. 
For individual coordinates folks in the Finnish Geospatial Institute (FGI)
do conversions like in this cs2cs example 

echo 2258573.56109 1010806.43899 5859099.49087 2021.26 | cs2cs -d 4 --area
finland EPSG:7789 EPSG:4936

where "2021.26" after the x, y, and z coordinates is the epoch and it gets
used with this operation:

projinfo -s EPSG:7789 -t EPSG:4936 -o PROJ --area Finland
-
Operation No. 1:
NKG:ITRF2014_TO_FI, ITRF2014 to ETRS89 (EUREF-FIN), 0.01 m, Finland -
onshore and offshore.
PROJ string:
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0
+drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=1989
+convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0 +grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935 +rx=-0.00312861
+ry=-0.00378935 +rz=0.00403512 +s=0.00529 +convention=position_vector +step
+proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif

The same thing with Python:

transformer = pyproj.Transformer.from_pipeline("""
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0
+dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0
+t_epoch=1989 +convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0
+grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935
+rx=-0.00312861 +ry=-0.00378935 +rz=0.00403512 +s=0.00529
+convention=position_vector
+step +proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif""")
coord = transformer.transform(x_wgs84, y_wgs84, z_wgs84, year)

-Jukka Rahkonen-


Nyall Dawson wrote
> On Thu, 27 May 2021 at 23:40, Even Rouault 

> 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@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
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

[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

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@

>  mailto:

> 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
>> 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
>> 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@

>  mailto:

> nyall.dawson@

> > 

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

[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

[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]

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

[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

[Nyall Dawson]

On Tue, 25 May 2021 at 23:58, Even Rouault  wrote:
>
>
> Le 25/05/2021 à 15:30, Howard Butler a écrit :
> >
> >> On May 24, 2021, at 5:39 PM, Sean Gillies  wrote:
> >>
> >> Howard, are you suggesting that there should be a configuration option to 
> >> opt in to this new feature?
> > Yes, I think it should be explicitly opt-in, not silently opt-out for the 
> > time being.
> >
> >
> >> On May 24, 2021, at 6:15 PM, Even Rouault  
> >> wrote:
> >>
> >> The mere introduction of this new capability isn't going to change any 
> >> behavior. It is only going to change behavior if people do add a 
> >> coordinate epoch in their datasets, and in that case, one can expect them 
> >> to want more accurate coordinate transformations. That said adding a 
> >> config option in the OGRProjCT class to ignore the coordinate epoch is 
> >> trivial...
> >>
> >
> > I'm glad you are getting traction with the various format groups on the 
> > topic, but that process is going to take a very long time to matriculate, 
> > and in many cases official blessing won't ever be pronounced. Let's make 
> > the behavior for applying the transformations *and* writing the metadata an 
> > explicit opt-in.
>
> Do you mean you would also want a per-driver option,
> WRITE_COORDINATE_EPOCH=YES, in addition to having attached a coordinate
> epoch to the CRS ? It seems to me that we are making the life of users
> harder, whereas we should make it easier to get it right. If people have
> already taken the step of attaching the coordinate epoch to the CRS, we
> can assume they want it to be preserved as much as possible. When people
> write a GeoTIFF with a CRS with a TOWGS84 override, we write the
> GeogTOWGS84GeoKey extension key without asking them.
>
> Is your worry about non-GDAL implementations ? At worse, they will
> ignore the coordinate epoch. You can't currently expect software
> implementations with different coordinate transformation engines to give
> the same result for the "simple" standard static CRS to static CRS
> situation.

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.

Nyall


>
> --
> 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
___
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]

Le 25/05/2021 à 15:30, Howard Butler a écrit :



On May 24, 2021, at 5:39 PM, Sean Gillies  wrote:

Howard, are you suggesting that there should be a configuration option to opt 
in to this new feature?

Yes, I think it should be explicitly opt-in, not silently opt-out for the time 
being.



On May 24, 2021, at 6:15 PM, Even Rouault  wrote:

The mere introduction of this new capability isn't going to change any 
behavior. It is only going to change behavior if people do add a coordinate 
epoch in their datasets, and in that case, one can expect them to want more 
accurate coordinate transformations. That said adding a config option in the 
OGRProjCT class to ignore the coordinate epoch is trivial...



I'm glad you are getting traction with the various format groups on the topic, 
but that process is going to take a very long time to matriculate, and in many 
cases official blessing won't ever be pronounced. Let's make the behavior for 
applying the transformations *and* writing the metadata an explicit opt-in.


Do you mean you would also want a per-driver option, 
WRITE_COORDINATE_EPOCH=YES, in addition to having attached a coordinate 
epoch to the CRS ? It seems to me that we are making the life of users 
harder, whereas we should make it easier to get it right. If people have 
already taken the step of attaching the coordinate epoch to the CRS, we 
can assume they want it to be preserved as much as possible. When people 
write a GeoTIFF with a CRS with a TOWGS84 override, we write the 
GeogTOWGS84GeoKey extension key without asking them.


Is your worry about non-GDAL implementations ? At worse, they will 
ignore the coordinate epoch. You can't currently expect software 
implementations with different coordinate transformation engines to give 
the same result for the "simple" standard static CRS to static CRS 
situation.


--
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

[Howard Butler]

> On May 24, 2021, at 5:39 PM, Sean Gillies  wrote:
> 
> Howard, are you suggesting that there should be a configuration option to opt 
> in to this new feature?

Yes, I think it should be explicitly opt-in, not silently opt-out for the time 
being.


> On May 24, 2021, at 6:15 PM, Even Rouault  wrote:
> 
> The mere introduction of this new capability isn't going to change any 
> behavior. It is only going to change behavior if people do add a coordinate 
> epoch in their datasets, and in that case, one can expect them to want more 
> accurate coordinate transformations. That said adding a config option in the 
> OGRProjCT class to ignore the coordinate epoch is trivial...
> 


I'm glad you are getting traction with the various format groups on the topic, 
but that process is going to take a very long time to matriculate, and in many 
cases official blessing won't ever be pronounced. Let's make the behavior for 
applying the transformations *and* writing the metadata an explicit opt-in.

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 Sean,

Hi Even, Howard:

I'm inclined to approve, but I feel like there should be more 
discussion, not just among PROJ developers and developers of cutting 
edge formats. We should work to draw a wider group in on this.
Various OGC standard working groups are aware of that topic since this 
was raised I think in a plenary meeting more than one year ago. I see 
that in Testbed 17 the working group on the "OGC Features and Geometry 
JSON" (the "extension" of GeoJSON) is aware of that, but has not 
proposed any solution. I've just pointed them to my proposal.


Howard, are you suggesting that there should be a configuration option 
to opt in to this new feature?


A surprise 1-2 meter shift is going to break builds and applications, 
I agree. I think a lot of us are tolerating inaccuracy due to using 
time-varying CRS but are going to be caught out by changes in the 
actual numbers.
The mere introduction of this new capability isn't going to change any 
behavior. It is only going to change behavior if people do add a 
coordinate epoch in their datasets, and in that case, one can expect 
them to want more accurate coordinate transformations. That said adding 
a config option in the OGRProjCT class to ignore the coordinate epoch is 
trivial...


Now that I think about it, I think the RFC should say more about what 
it will do for the ensemble OGC:CRS84.
I'm not sure what kind of transformations will be possible when 
operating on the WGS 84 ensemble. Within what is available strictly 
speaking in EPSG, probably none. But we have had repeated discussions on 
the PROJ mailing list regarding this, and potentially one option could 
be to consider that a "recent" coordinate epoch on WGS 84 would mean 
that people actually use the latest WGS 84 realization, WGS 84 (G1762) 
currently, and so use transformations available from/to that 
realization. But nothing regarding this has been implemented yet. To get 
a time-dependent transformation, you need to specify a non-ensemble datum.


To me, it seems that the parameterization or description of coordinate 
epochs in OGC 19-005r4 is a bit sketchy.

Could you precise ?


Even, are you saying that coordinate shifts in PROJ are entirely 
functions of the datetime delta since the coordinate epoch?


Currently what is available in PROJ for transformations between a 
dynamic CRS and a static CRS is mostly through using 15-parameter 
Helmert transformation: 
https://proj.org/operations/transformations/helmert.html (*). Those 
Helmert transformations can have non-time dependent components (the 
"classic" 7-parameter transformtion, ala TOWGS84) + a time-dependant 
component that is generally a rotation in spherical coordinates w.r.t 
Earth centre and of an amplitude proportional to (coordinate_epoch - 
central_epoch) where central_epoch is a constant of the transformation 
(e.g the GDA2020 to ITRF2014 transformation uses central_epoch=2020.0). 
But they are not "entirely functions of the datetime delta", since the 
value of the longitude, latitude, ellipsoidal height of the coordinate 
has also an influence on the result (not completely sure to understand 
your question).


To be complete on the topic, there are a few esoteric cases where 
https://proj.org/operations/transformations/deformation.html grids are 
used, and the amplitude of the correction is also proportional to 
(coordinate_epoch - central_epoch), but this is specific to a NKG 
(Nordic countries) CRS code


And there's the very particular case of transformations between ITRF96 
and NZGD2000 (New Zealand) which uses a more complex deformation model 
(https://proj.org/operations/transformations/defmodel.html), where the 
time parameter can decide if corrections related to earthquakes are 
applied depending on the location and if you're before or after the date 
of the earthquake.


Even

--

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

[Kurt Schwehr]

I've tried pinging David Sandwell at Scripps, geodesy / rtk / surveying
folks at UNH CCOM, and Paul Wessel / Dietmar Muller of GMT about a week ago
and haven't gotten any useful response.

I'm +0 and feeling like Sean that we really could use some feedback from
other communities.

Having epoch info is great, but I feel like I have no clue about what is a
sufficient solution.

-kurt

On Mon, May 24, 2021 at 3:40 PM Sean Gillies via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi Even, Howard:
>
> I'm inclined to approve, but I feel like there should be more discussion,
> not just among PROJ developers and developers of cutting edge formats. We
> should work to draw a wider group in on this.
>
> On Thu, May 13, 2021 at 10:01 AM Even Rouault 
> wrote:
>
>> Howard,
>> > It is magical
>> > ---
>> >
>> > If you have GDAL-extended versions of a few select data formats and you
>> have the correct chain of PROJ and GDAL, the behavior of your coordinates
>> is going to change for various transformations. This could be confusing and
>> challenging to track down in debugging scenarios. The discrepancies between
>> doing the same transformations in different softwares will be especially
>> noticeable.
>> Having different results in coordinate transformations due to have will
>> not be much different than using different PROJ versions using different
>> versions of the EPSG database, possibly with different set of grids
>> installed.
>>
>
> Howard, are you suggesting that there should be a configuration option to
> opt in to this new feature?
>
> A surprise 1-2 meter shift is going to break builds and applications, I
> agree. I think a lot of us are tolerating inaccuracy due to using
> time-varying CRS but are going to be caught out by changes in the actual
> numbers.
>
>
>> >
>> > It extends existing formats in GDAL's own way
>> > ---
>> >
>> > Are there many other cases where GDAL augments and extends behavior of
>> formats by bolting on metadata bits? I can think of some GeoTIFF tags where
>> GDAL has done this in the past. Some of them have been adopted
>> industry-wide, but most have not. We definitely haven't done that to a long
>> list of formats like this RFC proposes to do.
>> We are not going to invent a new raster or vector format just to add a
>> coordinate epoch into it, right ? So this proposal does minor and
>> backward compatible enhancements to popular existing formats.
>> >
>>
>
> For GeoJSON, at least, I think proposing a "coordinate_epoch" property is
> pragmatic. This doesn't do anything for GeoJSON feature sequences, though.
> And it doesn't do anything about data that's already out there that will
> never be re-processed.
>
> Now that I think about it, I think the RFC should say more about what it
> will do for the ensemble OGC:CRS84.
>
>
>> > No corresponding socializing activity
>> > -
>> >
>> > Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf,
>> GML, JPEG2000, KML, and Shapefile communities and advocate for these
>> improvements? It would be a lot of time and effort to go back after the
>> fact and officially augment all of these formats with epoch metadata.  Many
>> of these are never going to have new versions either, so there isn't much
>> hope of a new format version coming along with support for coordinate
>> epochs.
>> Well, this is a public RFC for everybody awareness, and there will be a
>> page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage
>> OGC github repos pointing to it. I don't necessarily expect much follow
>> up from them though, but at least we'll have tried to make advance the
>> topic a bit.
>> >
>> > Is the format of epoch standardized?
>> > -
>> >
>> > The proposed epoch format, such as 2021.3, *looks* like a floating
>> point number, but it isn't really, is it? Do you ever need more precision
>> than a year and a day? *shrug* It seems like it's own special time format.
>> Is there a standard time format that could instead be used here?
>>
>> This format is a floating point number and is the accepted way of
>> encoding coordinate epochs. The after decimal point part represents the
>> fraction of the year. It is referenced in "OGC Abstract Specification
>> Topic 2: Referencing by coordinates"
>> (https://docs.opengeospatial.org/as/18-005r4/18-005r4.html). In table 4:
>> coordinateEpoch: "date at which coordinates are referenced to a dynamic
>> coordinate reference system, expressed as a decimal year in the
>> Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is
>> epoch 2017.23."
>>
>> (31+28+25) / 365. = 0.23...
>>
>> Two digits after the decimal point should be enough in practice. For
>> 'slow' and continuous phenomenons like plate drift motion, an error of a
>> couple days will not change the result by more than a fraction of
>> millimetre. If 

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

[Sean Gillies via gdal-dev]

Hi Even, Howard:

I'm inclined to approve, but I feel like there should be more discussion,
not just among PROJ developers and developers of cutting edge formats. We
should work to draw a wider group in on this.

On Thu, May 13, 2021 at 10:01 AM Even Rouault 
wrote:

> Howard,
> > It is magical
> > ---
> >
> > If you have GDAL-extended versions of a few select data formats and you
> have the correct chain of PROJ and GDAL, the behavior of your coordinates
> is going to change for various transformations. This could be confusing and
> challenging to track down in debugging scenarios. The discrepancies between
> doing the same transformations in different softwares will be especially
> noticeable.
> Having different results in coordinate transformations due to have will
> not be much different than using different PROJ versions using different
> versions of the EPSG database, possibly with different set of grids
> installed.
>

Howard, are you suggesting that there should be a configuration option to
opt in to this new feature?

A surprise 1-2 meter shift is going to break builds and applications, I
agree. I think a lot of us are tolerating inaccuracy due to using
time-varying CRS but are going to be caught out by changes in the actual
numbers.


> >
> > It extends existing formats in GDAL's own way
> > ---
> >
> > Are there many other cases where GDAL augments and extends behavior of
> formats by bolting on metadata bits? I can think of some GeoTIFF tags where
> GDAL has done this in the past. Some of them have been adopted
> industry-wide, but most have not. We definitely haven't done that to a long
> list of formats like this RFC proposes to do.
> We are not going to invent a new raster or vector format just to add a
> coordinate epoch into it, right ? So this proposal does minor and
> backward compatible enhancements to popular existing formats.
> >
>

For GeoJSON, at least, I think proposing a "coordinate_epoch" property is
pragmatic. This doesn't do anything for GeoJSON feature sequences, though.
And it doesn't do anything about data that's already out there that will
never be re-processed.

Now that I think about it, I think the RFC should say more about what it
will do for the ensemble OGC:CRS84.


> > No corresponding socializing activity
> > -
> >
> > Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf,
> GML, JPEG2000, KML, and Shapefile communities and advocate for these
> improvements? It would be a lot of time and effort to go back after the
> fact and officially augment all of these formats with epoch metadata.  Many
> of these are never going to have new versions either, so there isn't much
> hope of a new format version coming along with support for coordinate
> epochs.
> Well, this is a public RFC for everybody awareness, and there will be a
> page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage
> OGC github repos pointing to it. I don't necessarily expect much follow
> up from them though, but at least we'll have tried to make advance the
> topic a bit.
> >
> > Is the format of epoch standardized?
> > -
> >
> > The proposed epoch format, such as 2021.3, *looks* like a floating point
> number, but it isn't really, is it? Do you ever need more precision than a
> year and a day? *shrug* It seems like it's own special time format. Is
> there a standard time format that could instead be used here?
>
> This format is a floating point number and is the accepted way of
> encoding coordinate epochs. The after decimal point part represents the
> fraction of the year. It is referenced in "OGC Abstract Specification
> Topic 2: Referencing by coordinates"
> (https://docs.opengeospatial.org/as/18-005r4/18-005r4.html). In table 4:
> coordinateEpoch: "date at which coordinates are referenced to a dynamic
> coordinate reference system, expressed as a decimal year in the
> Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is
> epoch 2017.23."
>
> (31+28+25) / 365. = 0.23...
>
> Two digits after the decimal point should be enough in practice. For
> 'slow' and continuous phenomenons like plate drift motion, an error of a
> couple days will not change the result by more than a fraction of
> millimetre. If you use a deformation model that takes into account
> earthquakes however, you could perhaps need to add a 3rd digit to
> identify precisely the day.
>
> Even
>

To me, it seems that the parameterization or description of coordinate
epochs in OGC 19-005r4 is a bit sketchy.

Even, are you saying that coordinate shifts in PROJ are entirely functions
of the datetime delta since the coordinate epoch?

-- 
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]

Hi,

small update regarding GeoPackage. There's now a proposed update of the 
GeoPackage specification to store the coordinate epoch as the value of 
the |epoch| column of the |gpkg_spatial_ref_sys| table (see 
opengeospatial/geopackage#599 
 and 
opengeospatial/geopackage#600 
). I've updated 
the implementation PR accordingly.


Even

--
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

[Even Rouault]

Personally I like that data and metadata are kept in the same file. But if
it feels bad, could it be an option to use a sidecar file ".aux.xml" for the
single file / single layer formats like GeoJSON?


On the raster side, drivers that derive from GDALPamDataset, that is 
most (in particular JPEG, PNG), etc will automatically benefit from the 
added serialization of the coordinateEpoch in the SRS element of the 
.aux.xml file.


On the vector side, we have no such general infrastructure, so that 
isn't possible currently.


--

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

[jratike80]

+1

For me the RFC feels good. Existing data formats like GeoTIFF and GeoJSON
can deliver the 4D spatiotemporal coordinates correctly by using the epoch
attached as metadata when the whole dataset  is using the same epoch. None
of the formats dealt in the RFC should get broken. If some software does not
know what to do with the metadata it will discard the metadata and the
situation is the same than now. Those who use dynamic coordinate systems
probably know that without epoch the data are undefined and then they will
try to find the epoch by some other means.

Personally I like that data and metadata are kept in the same file. But if
it feels bad, could it be an option to use a sidecar file ".aux.xml" for the
single file / single layer formats like GeoJSON?

Obviously there is lot to do with dynamic reference systems
https://geophysica.fi/pdf/geophysica_2019_54_kierulf.pdf but this RFC could
be a good start.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> Motion:
> 
> adopt RFC 81: support for coordinate epochs in geospatial formats ( 
> https://github.com/OSGeo/gdal/pull/3827 )
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
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

[Andrew Bell]

On Thu, May 13, 2021 at 3:21 PM Javier Jimenez Shaw 
wrote:

> My two cents:
>
> About NGS / NOAA, I know that the new CRS they are preparing for 2022 it
> clearly time dependent. I attended an online conference (oriented to
> surveyors) last year about it, and they insisted a lot on the time variable
> and plates drift.
> There are some of them in the PROJ mailing list (maybe here as well)
> -there was a discussion about including some grid files in PROJ-data-.
> Maybe involving them in this topic may produce more traction.
>

I'm not sure the issue is whether people expect to use time-marked CRS.
It's more whether GDAL should attempt to add their support into formats not
built for it.

I also wonder if people who create time-marked files from GDAL will be
confused/mislead when those files aren't properly read by other software.

-- 
Andrew Bell
andrew.bell...@gmail.com
___
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

[Javier Jimenez Shaw]

My two cents:

About NGS / NOAA, I know that the new CRS they are preparing for 2022 it
clearly time dependent. I attended an online conference (oriented to
surveyors) last year about it, and they insisted a lot on the time variable
and plates drift.
There are some of them in the PROJ mailing list (maybe here as well) -there
was a discussion about including some grid files in PROJ-data-. Maybe
involving them in this topic may produce more traction.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Thu, 13 May 2021 at 19:54, Greg Troxel  wrote:

adopt RFC 81: support for coordinate epochs in geospatial formats (
https://github.com/OSGeo/gdal/pull/3827 )


> Howard Butler  writes:
>
> > It extends existing formats in GDAL's own way
> > ---
> >
> > Are there many other cases where GDAL augments and extends behavior of
> > formats by bolting on metadata bits? I can think of some GeoTIFF tags
> > where GDAL has done this in the past. Some of them have been adopted
> > industry-wide, but most have not. We definitely haven't done that to a
> > long list of formats like this RFC proposes to do.
>
> (I don't count formally.)
>
> I think I agree with Even's position here.  And, I see this as not being
> "GDAL's own way", but "a proposed way for the open geospatial community".
>
> But, overall this makes me wonder: Are there any formats for expressing
> epoch in the open source/open format world, and also in the proprietary
> world?.  I'm not aware of any (which means epsilon more than zero) and a
> quick search did not turn up anything.
>
> Obviously the US NGS keeps track of such things in their bluebook and
> NGS Integrated Datbase formats as they transform positions among epochs
> when doing adjustments, but that's a rather specialized and not so
> relevant to GIS format.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
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]

And, I see this as not being
"GDAL's own way", but "a proposed way for the open geospatial community".


Except for the proposal for GeoTIFF (using a new GeoKey) and FlatGeoBuf 
(using WKT:2019 COORDINATEMETADATA[]) (and maybe GeoJSON), all solutions 
I propose are obviously in the (harmless) hack category. I don't expect 
XML comments to be a standard body vetted solution. The purpose is to 
have some support to preserve the coordinate epoch when converting 
between popular formats with GDAL tooling. The idea is that a data 
producer can have some way to encode the information if they wish. And 
if in the years to come, better ways of encoding it are found and 
standardized, the information will be here to re-encode the data in a 
more standard way.


There are number of data producers emitting data referenced against WGS 
84 with metric or submetric accuracy and they don't provide the 
coordinate epoch. That must stop.


But, overall this makes me wonder: Are there any formats for expressing
epoch in the open source/open format world, and also in the proprietary
world?.  I'm not aware of any (which means epsilon more than zero) and a
quick search did not turn up anything.


I'm not aware of file formats or database layouts (I raised an issue for 
PostGIS: https://trac.osgeo.org/postgis/ticket/4911). The only 'thing' 
I'm aware of that takes into account coordinate epoch is the 'OGC API - 
Features - Part 2: Coordinate Reference Systems by Reference' spec: 
https://docs.ogc.org/is/18-058/18-058.html#_storage_crs . But I wonder 
who can fill such field with none of the data backend having support for 
it. hence this RFC. I see it more as a bootstrapping than the ultimate 
solution.



--
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

[Greg Troxel]

Howard Butler  writes:

> It extends existing formats in GDAL's own way
> ---
>
> Are there many other cases where GDAL augments and extends behavior of
> formats by bolting on metadata bits? I can think of some GeoTIFF tags
> where GDAL has done this in the past. Some of them have been adopted
> industry-wide, but most have not. We definitely haven't done that to a
> long list of formats like this RFC proposes to do.

(I don't count formally.)

I think I agree with Even's position here.  And, I see this as not being
"GDAL's own way", but "a proposed way for the open geospatial community".

But, overall this makes me wonder: Are there any formats for expressing
epoch in the open source/open format world, and also in the proprietary
world?.  I'm not aware of any (which means epsilon more than zero) and a
quick search did not turn up anything.

Obviously the US NGS keeps track of such things in their bluebook and
NGS Integrated Datbase formats as they transform positions among epochs
when doing adjustments, but that's a rather specialized and not so
relevant to GIS format.


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

[Even Rouault]

Howard,

It is magical
---

If you have GDAL-extended versions of a few select data formats and you have 
the correct chain of PROJ and GDAL, the behavior of your coordinates is going 
to change for various transformations. This could be confusing and challenging 
to track down in debugging scenarios. The discrepancies between doing the same 
transformations in different softwares will be especially noticeable.
Having different results in coordinate transformations due to have will 
not be much different than using different PROJ versions using different 
versions of the EPSG database, possibly with different set of grids 
installed.


It extends existing formats in GDAL's own way
---

Are there many other cases where GDAL augments and extends behavior of formats 
by bolting on metadata bits? I can think of some GeoTIFF tags where GDAL has 
done this in the past. Some of them have been adopted industry-wide, but most 
have not. We definitely haven't done that to a long list of formats like this 
RFC proposes to do.
We are not going to invent a new raster or vector format just to add a 
coordinate epoch into it, right ? So this proposal does minor and 
backward compatible enhancements to popular existing formats.


No corresponding socializing activity
-

Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf, GML, 
JPEG2000, KML, and Shapefile communities and advocate for these improvements? 
It would be a lot of time and effort to go back after the fact and officially 
augment all of these formats with epoch metadata.  Many of these are never 
going to have new versions either, so there isn't much hope of a new format 
version coming along with support for coordinate epochs.
Well, this is a public RFC for everybody awareness, and there will be a 
page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage 
OGC github repos pointing to it. I don't necessarily expect much follow 
up from them though, but at least we'll have tried to make advance the 
topic a bit.


Is the format of epoch standardized?
-

The proposed epoch format, such as 2021.3, *looks* like a floating point 
number, but it isn't really, is it? Do you ever need more precision than a year 
and a day? *shrug* It seems like it's own special time format. Is there a 
standard time format that could instead be used here?


This format is a floating point number and is the accepted way of 
encoding coordinate epochs. The after decimal point part represents the 
fraction of the year. It is referenced in "OGC Abstract Specification 
Topic 2: Referencing by coordinates" 
(https://docs.opengeospatial.org/as/18-005r4/18-005r4.html). In table 4: 
coordinateEpoch: "date at which coordinates are referenced to a dynamic 
coordinate reference system, expressed as a decimal year in the 
Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is 
epoch 2017.23."


(31+28+25) / 365. = 0.23...

Two digits after the decimal point should be enough in practice. For 
'slow' and continuous phenomenons like plate drift motion, an error of a 
couple days will not change the result by more than a fraction of 
millimetre. If you use a deformation model that takes into account 
earthquakes however, you could perhaps need to add a 3rd digit to 
identify precisely the day.


Even


--
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

[Howard Butler]

> On May 13, 2021, at 4:44 AM, Even Rouault  wrote:
> 
> Hi,
> 
> Motion:
> 
> adopt RFC 81: support for coordinate epochs in geospatial formats ( 
> https://github.com/OSGeo/gdal/pull/3827 )
> 
> Starting with my +1

-0

I'm not enthusiastic about the proposed implementation. I don't have an 
alternative solution which would allow me to veto it, however. Here's why I 
think it is bad to decorate all of these old formats with our own epoch 
metadata:

It is magical
---

If you have GDAL-extended versions of a few select data formats and you have 
the correct chain of PROJ and GDAL, the behavior of your coordinates is going 
to change for various transformations. This could be confusing and challenging 
to track down in debugging scenarios. The discrepancies between doing the same 
transformations in different softwares will be especially noticeable. 

It extends existing formats in GDAL's own way
---

Are there many other cases where GDAL augments and extends behavior of formats 
by bolting on metadata bits? I can think of some GeoTIFF tags where GDAL has 
done this in the past. Some of them have been adopted industry-wide, but most 
have not. We definitely haven't done that to a long list of formats like this 
RFC proposes to do.

No corresponding socializing activity
-

Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf, GML, 
JPEG2000, KML, and Shapefile communities and advocate for these improvements? 
It would be a lot of time and effort to go back after the fact and officially 
augment all of these formats with epoch metadata.  Many of these are never 
going to have new versions either, so there isn't much hope of a new format 
version coming along with support for coordinate epochs. 

Is the format of epoch standardized?
-

The proposed epoch format, such as 2021.3, *looks* like a floating point 
number, but it isn't really, is it? Do you ever need more precision than a year 
and a day? *shrug* It seems like it's own special time format. Is there a 
standard time format that could instead be used here?

Howard

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

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

[Even Rouault]

Hi,

Motion:

adopt RFC 81: support for coordinate epochs in geospatial formats ( 
https://github.com/OSGeo/gdal/pull/3827 )


Starting with my +1

Even

--
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