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
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,
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
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
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
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
>
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
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
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
> 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
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
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 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
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
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
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
>
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
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
+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
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
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
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)
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
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
> 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
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
26 matches
Mail list logo
