gpkg with epsg:3812 data

[pvgenuchten]

Is your feature request related to a problem? Please describe.

at foss4g timisuara pygeoapi workshop we tried to add gpkg data in epsg:3812 format.
we had to set the parameter storage_crs to get the data projected to the correct projection (both in sqlitegpkg as well as ogr provider)
some questions:

• why does pygeoapi not deduce the storage_crs from the data
• setting the crs in the extent section seems to have no effect at all
• has this aspect been documented enough? we missed the aspect

[pvgenuchten]

actually this section describes the storage_crs convention, so maybe we should make it more prominent only, as described in geopython/diving-into-pygeoapi#241

[webb-ben]

why does pygeoapi not deduce the storage_crs from the data

For Postgis, this is because there is no distinction between EPSG:4326 and OGC:CRS84 because they share the same projection with flipped axis ordering. I believe some providers do try to distinguish the source content CRS.

setting the crs in the extent section seems to have no effect at all

As far as I understand, the extent crs specifically refers to the extent bbox, not the content itself. Assuming the minor differences between projections, these two extents should be roughly the same.

        extents:
            spatial:
                bbox: [-180,-90,180,90]
                crs: http://www.opengis.net/def/crs/OGC/1.3/CRS84

        extents:
            spatial:
                bbox: [-20037508.3428,-20037508.3428,20037508.3428,20037508.3428]
                crs: http://www.opengis.net/def/crs/EPSG/0/3857

has this aspect been documented enough? we missed the aspect

It is documented primarily at https://docs.pygeoapi.io/en/latest/crs.html although we can do better highlighting in other relevant parts of the documentation

[pvgenuchten]

Thanx @webb-ben,