pygeoapi
pygeoapi copied to clipboard
WIP: Add metadata path to config for MVT
@francbartoli I've started making at attempt at this, but I'm a bit out of my depth.
Is it better to add the metadata_url
to the config vs update pg_tileserv so it writes the metadata.json at the path pygeoapi expects?
It'd be this one line wouldn't it (https://github.com/CrunchyData/pg_tileserv/blob/0af7454f93fd057481bed93d7def6bffb47b1836/layer.go#L98) @justb4?
Well actually the first does make sense to me
This is not an official review, as I would need more time to understand both the intent and design for this PR and its precursors. But think the idea is to fetch tilejson
metadata from an MVT endpoint, providing these as OATiles md.
For one thing, learning the hard way in GeoHealthCheck, Vector Tile endpoints are not consistent in their metadata (i.e. the equivalents of OWS "Capabilities", "DescribeLayer" etc), and see here. One cannot assume the presence of any field, even if mandatory in the MapBox tilejson spec. To start with, there are multiple spec-versions, most fields optional, but even a required field like "tilejson"
denoting the version may not be present. Also here, defensive get(field, default)
s and some heuristics is a must to prevent KeyError
s and get the 'nuggets' out..
@justb4 this PR is focused on being able to add a tiles metadata path in the config.yml, so this is used by pygeoapi, instead of the current url construction method which assumes the metadata.json will be at http://baseurl/layer/metadata.json
This then doesn't work if using pg_tileserv as the provider as it puts the metadata at http://baseurl/layer.json
@KoalaGeo ok, maybe this is something to implement with a "tile-server-provider" config attribute, and parse for different implementations (like pg_tileserv
) and tilejson-spec
variants. Something similar is done in the pygeoapi OGR provider. There we call these source_types
(like "WFS" and "ESRIJSON") and SOURCE_HELPERS
.
@justb4 that seems more complex than adding an attribute/field for the explicit URL path to the metadata.
The sources type approach would require knowing & coding the implementation variations, which could be changed by the implementation at a later date.
@KoalaGeo also fine. Let's see how that works out for pg_tileserv
and then other MVT providers.
@justb4 & @francbartoli I've had another look at this but sorry to say at the moment it's very much beyond my python capabilities to implement the intended fix
Closing as unable to progress.