Hi Jukka,

 

This is the spec: https://docs.ogc.org/is/12-128r17/12-128r17.html

 

Two places are effected in the GeoPackage:
gpkg_contents table: min_x, min_y, max_x, max_y
user data table: row “geom” including WKB (as part of the BLOB)
 

For the *_x and *_y, GeoPackage Spec, Table 4 defines that *_x represents LON 
and *_y represents LAT, regardless of CRS. The current code produces LAT/LON 
values.

 

According to GeoPackage Requirement 19 the following is important to note:

“The axis order in WKB stored in a GeoPackage follows the de facto standard for 
axis order in WKB and is therefore always (x,y{,z}{,m}) where x is easting or 
longitude, y is northing or latitude, z is optional elevation, and m is 
optional measure. This ordering explicitly overrides the axis order as 
specified in the SRS metadata, applying Case 4 from OGC 08-038r7, Revision to 
Axis Order Policy and Recommendations[K11]. This was done to maintain 
consistency with previous implementations of WKB that predated the OGC policy.” 
And the OGC Policy Directive that resolves from K11 
(https://portal.ogc.org/files/?artifact_id=76024) states for case 4: “The 
Encoding specification (document) explicitly overrides the Axis Order as 
specified in the CRS metadata: In this case, a specification (document) 
specifies a default CRS but then overrides the axis order of the CRS as 
specified in the CRS metadata. A typical example is to specify WGS 84 (EPSG 
4326) in the specification but then state in the document that the axis order 
is the opposite of the CRS metadata. The payloads would then be encoded using 
the axis order as specified in the spec document and not in the CRS metadata. 
The OGC does not recommend implementing this use case.” 

 

=> The current code produces LAT/LON values

 

 

Another aspect – not linked to the issue of axis order – is that the definition 
and description is wrong in

https://github.com/geotools/geotools/blob/main/modules/plugin/geopkg/src/main/resources/org/geotools/geopkg/gpkg_spatial_ref_sys.sql
 

The file states LON/LAT for EPSG:4326 but it should be LAT/LON. 

 

The code in 
https://github.com/geotools/geotools/blob/main/modules/plugin/geopkg/src/main/java/org/geotools/geopkg/GeoPackage.java
 (lines 465 - 469) creates the CRS definition like this:

"GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\","
 

+ 
"6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],"
 

+ 
"PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,"
 

+ "AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]",
 

"longitude/latitude coordinates in decimal degrees on the WGS 84 spheroid");
 

There is no axis definition. But still there is a description that indicates 
wrong axis ordering. I’ve seen GeoPackages that use such a EPSG:4326 definition 
in their GeoPackage but they use another CRS for the actual geometry encodings…

 

Best

Andreas 

 

From: "Rahkonen Jukka (MML)" <jukka.rahko...@maanmittauslaitos.fi>
Date: Thursday, 28. October 2021 at 17:16
To: Ian Turton <ijtur...@gmail.com>, Andreas Matheus / Secure Dimensions 
<a...@secure-dimensions.de>
Cc: Geoserver Devel <geoserver-devel@lists.sourceforge.net>
Subject: VS: [Geoserver-devel] GeoPackage Extension Community Module - Issue 
with axis order

 

Hi,

 

GeoPackage geometry BLOB is defined in the GeoPackage standard. It is a WKB 
geometry (also OGC standard per OGC 06-103r4) with some additional flag bytes. 
Coordinate axis order in WKB BLOB and therefore also in GPKG BLOB is not 
affected by the coordinate reference system.

 

-Jukka Rahkonen-

 

Lähettäjä: Ian Turton <ijtur...@gmail.com> 
Lähetetty: torstai 28. lokakuuta 2021 17.50
Vastaanottaja: Andreas Matheus / Secure Dimensions <a...@secure-dimensions.de>
Kopio: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Aihe: Re: [Geoserver-devel] GeoPackage Extension Community Module - Issue with 
axis order

 

You'd probably be best raising a ticket against the supported GeoTools module 
(gepkg) which I assume provides the GeoServer Geopackage output. To be honest 
I'm not sure what the correct axis order for a GeoPackage is when requested 
from a WFS in 4326, and I'm not sure which OGC standard would apply (and if 
they agree). 

 

Ian

 

On Thu, 28 Oct 2021 at 14:40, Andreas Matheus / Secure Dimensions 
<a...@secure-dimensions.de> wrote:

Hello everyone,

 

Is there a maintainer for the GeoPackage Extension Community Module?

https://docs.geoserver.org/stable/en/user/community/geopkg/output.html

 

It looks like there is an issue with AXIS ORDER for WKB when creating a 
GeoPacakge out of a WFS request using CRS EPSG:4326.

 

I’ve read that Community plugins are not part of the official GeoServer 
software stack. So I wonder what the best way might be to report the bug on 
this plugin? 

 

Considering that I could provide a bugfix for consideration, what would be the 
best approach?

 

Best

Andreas

 

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



-- 

Ian Turton

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to