Geoserver wmts nu ook mogelijk per workspace

Ik vroeg me af of jullie (bij pdok en anderen) deze thread gezien hadden: [GEOS-7591] - JIRA. Vanaf geoserver 2.10 kun je ook virtuele services maken voor wmts. Mogelijk lost dit de uitdaging op met de huidige BRT etc WMTS, waarin allerlei lagen (uit verschillende workspaces?) in 1 wmts capabilities ontsloten worden. Zie bijvoorbeeld http://nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/3373be8c-8539-4763-bc22-eba23ac1898f

Hoi @pvgenuchten,

We zijn bekend met deze situatie, graag zien wij ook in de toekomst de WMTS-layers gesplitst per dataset. (M.a.w. geen ‘vervuiling’ van andere datasets, zoals de luchtfoto’s)

Technisch gezien hebben we de datasets al ontkoppeld van elkaar met onze application stacks (mapproxy+couchdb) en lijmen we de capabilities zelfs weer aan elkaar om dat dit vanuit historie nu het ‘koppelvlak’ naar de buitenwereld is. We zijn wel aan het nadenken over een mogelijk nieuwe URL strategie waarin ook dit soort ‘issues’ getackeld gaan worden.

Groet,
Wouter

ok prima, ik wist niet dat dit intentioneel was, bepaalde gebruikers hebben behoefte aan 1 centrale pdok-wmts-capabilities?

“behoefte” dat is een goede vraag, mogelijk dat ontwikkelaars/afnemers van onze service daar het beste antwoord op kan geven.

Ha Wouter, nog 1 gedachte hieromtrent, in het geval alle lagen in een enkele wmts service geplaatst zijn, kan deze service met een enkel ‘metadata voor service’ record in de catalogus beschreven worden. De keuze om echter iedere laag uit de service als een aparte service te beschrijven (https://nationaalgeoregister.nl/geonetwork/srv/metadata/dc8aeae7-619e-4eb2-a5c2-b22f83e17cca, https://nationaalgeoregister.nl/geonetwork/srv/metadata/d9d8dbde-f921-44f4-8b72-93ccbe038678) is wat verwarrend. Ben benieuwd hoe jullie hier naar kijken.

Hoi @pvgenuchten,
Ik ben het met je eens dat het verwarrend is(/overkomt) om dan iedere laag apart te beschrijven.
Het liefst zou ik het ook anders zien, we zijn bezig (over aan het nadenken) met een nieuwe URL strategie waarin o.a. dit ‘issue’ (het splitsten van de services) opgelost is.

Groet,
Wouter

Laat maar horen als je gedachten hierover van de community op prijs stelt :slight_smile:

Bijvoorbeeld door wat achtergrondinformatie en usecases te benoemen?

  • de achtergrond van servicemetadata;
  • waarom INSPIRE/iso alleen in een link van metadata voor service naar metadata voor dataset voorziet en niet andersom
  • Use case een service metadata vinden in een catalogus en de achterliggende service openen in bv QGIS
  • waarom inspire maar 1 dataset verwacht in een download service
  • waarom sommigen graag van het concept metadata voor service af willen
  • waarom (inspire) validators vaak niet de validiteit van links testen
  • etc