add OpenAerialMap /meta endpoint to catalogs

[andrewharvey]

sketching out how an OpenAerialMap catalog file might look

[1ec5]

Thanks for sketching this out! For the purpose of discussion, would you be interested in drafting some documentation that would go in FAQ.md, CONTRIBUTING.md, or schema.json to explain how this new OAM_META type works?

[andrewharvey]

I added some more details. But I don't have an answer of how it should then be used, like if this project should be responsible for fetching the each catalog items and converting it into an imagery.*.

[1ec5]

Maybe not in a manner that would directly include those items in the distribution, since it could be much more dynamic than clients would expect from an ELI distribution. But maybe we could vend utilities for resolving these items on demand.

[andrewharvey]

Maybe not in a manner that would directly include those items in the distribution, since it could be much more dynamic than clients would expect from an ELI distribution. But maybe we could vend utilities for resolving these items on demand.

I was thinking we need an alternative distribution for the ELI that's geographically indexed, so editors can make a request for sources and catalog items at a given hashed geographic location and receive back just those sources/items at that location.

[simonpoole]

I was thinking we need an alternative distribution for the ELI that's geographically indexed, so editors can make a request for sources and catalog items at a given hashed geographic location and receive back just those sources/items at that location.

In the past there was some work done on a tiled version of the index, @grischard was involved.

In general IMHO (legit) sources are not discoverable enough (in more than one way) in OSM, for an old (as in nearly a decade old) idea see https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas#Third_Party_Source_Management_System_2

[simonpoole]

Just a further observation: if you do add something along such lines shouldn't WMS and WMTS servers be included as catalogues?

[1ec5]

A WMS seems conceptually closer to a layer than a catalog. A given ArcGIS FeatureServer can have multiple layers, but the metadata is all the same. That said, we currently curate many individual layers of FeatureServers, based on our assumptions of what would be most valuable to a mapper. Perhaps we could list the overall server and let the mapper choose.

[andrewharvey]

If the are WMS/WMTS endpoints or ArcGIS endpoints that contain 100+ layers and all of those layers are under the same terms, and the WMS/WMTS or ArGIS endpoints also provides the metadata on layer extent, optionally vintage too, then yes I can see these being useful to be added as catalogs.

It'll depend case by case, if it gives us more control to add them all as individual sources, that might be the way to go, if we feel it's best for ongoing updates and maintenance as a catalog, then we do that.

Good point @1ec5 about curating the layers based on what we want to include for mappers, so I'd only include WMS or ArcGIS as catalogs where we want to include all the layers. I'm thinking more so where these provide imagery from many different capture dates and many different coverage areas.

[andrewharvey]

In general IMHO (legit) sources are not discoverable enough (in more than one way) in OSM, for an old (as in nearly a decade old) idea see https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas#Third_Party_Source_Management_System_2

I agree, and what we have in place at the moment is quite ad-hoc. I think ELI is a start, for reference layers that appear in the background of editors, but it doesn't cover vector data that might be importable. For example in Australia we use https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue to track interesting sources, their licensing, and compatibility, but a more integrated solution with more support from the LWG would be good.

[simonpoole]

If the are WMS/WMTS endpoints or ArcGIS endpoints that contain 100+ layers and all of those layers are under the same terms ....

You've got me slightly confused there, ELI already includes WMS endpoints with typically simply the most relevant layer getting there own ELI entries, wouldn't this simply be a question of reclassifying those endpoints? Random example https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/de/Mainz-Gint-OpenDataWMS.geojson?short_path=9786227

[andrewharvey]

You've got me slightly confused there, ELI already includes WMS endpoints with typically simply the most relevant layer getting there own ELI entries, wouldn't this simply be a question of reclassifying those endpoints? Random example https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/de/Mainz-Gint-OpenDataWMS.geojson?short_path=9786227

Ah I didn't realise we had wms_endpoint, so we already have support for WMS catalogs then.

It looks like these aren't supported by iD or Vespucci, but are supported by JOSM.

[simonpoole]

Vespucci got wms_endpoint support at the same time as OAM support was added (aka 8 years ago) https://vespucci.io/help/en/10.1.0%20Release%20notes/#wms-server-support. in 2020.

[andrewharvey]

Vespucci got wms_endpoint support at the same time as OAM support was added (aka 8 years ago) https://vespucci.io/help/en/10.1.0%20Release%20notes/#wms-server-support.

Sorry user error, I was looking in "Add background imagery layer" and couldn't see the wms_endpoint layers, but now I see you need to go to "Add imagery from WMS". When I saw that the first time I thought it meant from a custom WMS URL, I didn't realise once you click through you get a list of the ELI WMS options.

[simonpoole]

A WMS seems conceptually closer to a layer than a catalog. A given ArcGIS FeatureServer can have multiple layers, but the metadata is all the same.

AFAIK (well more iirc) WMS servers can have meta data both at the "server level" as well as individual layers. For example that's the reason I've never added any of the many Swiss WMS endpoints (for example from swisstopo) as there tends to be a hodgepodge of different terms of use that would not only have to be exposed via the UI to the end user, we would have to explain which ones can be used and which not.

In any case I'm not going on about this just to be annoying, it is just if ELI is going to add a policy for catalogues, which is IMHO a good idea, just maybe very limiting, we need to realise that we already have the problem and should include WMS and WMTS endpoints in any such policy.