WMS legenda: layer-naam versus style-naam bij een default-style

Standaarden
#1

Openlayers 6, wat ik als viewer bibliotheek gebruik, ondersteund voor het ophalen van legenda-plaatjes van WMS services alleen de GetLegendGraphic-methode helaas. Het irriteerde me al een tijdje dat ik daardoor alleen een gebroken image
image
als legenda kreeg, omdat vrijwel alle WMSsen op service.pdok.nl via het Style-element een legenda-plaatje aanbieden (en GetLegendGraphic niet ondersteunen). Op zich niks mis mee, en heeft als voordeel dat het een stuk makkelijker is, dus heb ik daar maar een oplossing voor gebouwd.

Daarbij viel me wel op dat in ieder geval bij Spoorwegen in het plaatje de naam van de default style word/is gezet. Zowel de Name als de Title van alle Styles van Spoorwegen is ‘Default’, en dat staat dus ook overal in de pngtjes. Niet echt informatief als ik een aantal lagen uit die WMS tegelijk gebruik :smile:




dit zijn de legenda-plaatjes voor Wissel, Spooras en Kruising…

Ik weet niet of die png’tjes automatisch gegenereerd worden, maar als daar in plaats van het woordje Default de style-naam (of layer-naam) opgenomen kan worden, zou dat de zaak wat duidelijker maken (niet heel veel overigens, omdat er ook geen tot erg weinig verschil is in de lijnsymbologie). En in lijn trekken met de meeste andere WMSsen op service.pdok.nl.

Voor zover ik kan zien gaat het bij de meeste WMSsen wel redelijk goed (ik heb niet alles gecheckt), maar vooral bij Spoorwegen is een legenda niet echt verhelderend :smiley:
En het feit dat een default-style als default gebruikt zou moeten worden: in mijn ervaring word, als je niet specifiek een style opgeeft, altijd de eerste gebruikt, dus dat default lijkt tegenwoordig toch al niet zoveel effect meer te hebben. Overigens kan ik dat mis hebben hoor, maar dat lijken mijn experimenten wel uit te wijzen.

DescribeLayer-verzoek
#2

Even uit mijn hoofd zegt de WMS standaard dat een legenda plaatje geen label moet hebben als het een enkelvoudige legenda betreft (dus 1 item, zoals in dit voorbeeld).
Pas indien er meerdere items zijn (bijvoorbeeld meerdere klassen), dan zou het legenda plaatje labels moeten bevatten.

Imho zou dus het label “default” geheel weggelaten moeten worden, en niet vervangen door iets anders.
Waarschijnlijk wordt dit label automagisch gegenereerd obv de naam van de stijl. Stijlnaam aanpassen zou dan moeten leiden tot een beter label.

#3

Hmmm. In dat geval zijn er nogal wat WMS-legenda’s die niet aan de WMS standaard voldoen. Zoals bijvoorbeeld Woonplaats uit de BAG:

Persoonlijk vind ik het wel handig als de stylenaam er bij staat, scheelt weer screen real estate (want ik hoef er zelf geen laagnaam meer bij te zetten).
Aan de andere kant: het maakt me eigenlijk niet veel uit, het is makkelijk genoeg om de layer-name erbij te zetten, maar dan is het wel handig als het consistent is.
Ik ga eens in de WMS-specs duiken denk…

#4

Voor mij nieuw is dat je kunt kiezen of je de legenda met of zonder tekst wilt hebben door de naam van de rule als parameter mee te geven. Vergelijk:
https://service.pdok.nl/prorail/spoorwegen/wms/v1_0?service=wms&request=GetLegendGraphic&version=1.1.1&layer=Wissel&format=image/png
met
https://service.pdok.nl/prorail/spoorwegen/wms/v1_0?service=wms&request=GetLegendGraphic&version=1.1.1&layer=Wissel&format=image/png&rule=default

Nb. voor bijv. BAG-panden heet de rule geen “default”, maar “pand”:
https://service.pdok.nl/lv/bag/wms/v2_0?service=wms&request=GetLegendGraphic&version=1.1.1&layer=pand&format=image/png&rule=pand)

1 like
#5

:astonished:

Voor mij nieuw is dat GetLegendGraphic blijkbaar wel werkt, terwijl dat NIET in de Capabilities gepubliceerd word!

En overigens klopt dat van die Rule ook maar gedeeltelijk: als ik de GetLegendGraphic van bag:pand_status wil ophalen, komt de melding terug dat

msWMSGetLegendGraphic(): Image handling error. Unavailable RULE (bag:pand_status).

https://service.pdok.nl/lv/bag/wms/v2_0?service=wms&request=GetLegendGraphic&version=1.1.1&layer=pand&format=image/png&rule=bag:pand_status

Dus wat die Rule-parameter precies doet, weet ik niet (zoals ik al zei: ik moet hoognodig weer eens in de specs duiken :wink: ). Als je die rule-key vervangt door ‘style=’, dan werkt het weer wel overigens, met de namen van de verschillende statussen erbij.
Maar algemeen: in de definitie van de style in de capabilities staat een rechtstreekse link naar een png, wat veel makkelijker werkt: dmv een XPath zijn die style-links er zo uit te halen (wat ik dan op miin server doe, en die haal ik in een json op - scheelt heel veel overtollige capabilities-xml-bytes naar de browser overhalen :slight_smile: ).

#6

Default is nu aangepast naar de betreffende laagnaam. Dus het is informatiever geworden. Zie: Spoorwegen WMS

3 likes
#7

Top, ik zie het!

Dankjewel voor de snelle actie, dat word gewaardeerd :slight_smile:

1 like
#8

De rule parameter is een zgn vendor specific parameter. Vendor specific parameters zijn wel onderdeel van de WMS-standaard, maar iha niet interoperabel.

Dit werkt dus alleen als in een client specifieke code is geschreven voor deze specifieke server software (GeoServer denk ik). Op het moment dat de dataset wordt uitgeserveerd met andere WMS-software (bijvoorbeeld Mapserver), dan zal de rule parameter niet werken.

#9

Dacht ik eerst ook, maar toen ik zag dat zowel Mapserver als Geoserver die rule-parameter ondersteunt ben ik ik de OGC-specs gaan kijken.
Het request GetLegendGraphic op zich is optionale, daarbinnen is de rule-parameter ook weer optional, maar het is wel onderdeel van de standaard.
Als ik de standaard zo lees zouden méérdere rule-parameters zelfs zijn toegestaan?

#10

Ah, my bad. Inderdaad zijn er een aantal parameters die erbij komen indien de service het insturen van SLD’s ondersteunt.

De rule wordt in de SLD benoemd. Indien je die niet zelf hebt gemaakt en ingestuurd, danwel de sld staat niet op een openbare weblocatie, dan valt het nog niet mee de juiste rule te noemen.

En inderdaad zou je dan meerdere rules kunnen benoemen. Elke rule resulteert in 1 “kaarlaag” binnen het getekende kaartje, en daarmee ook binnen de legenda.

Nogmaals, alles uit mijn hoofd, dus mogelijk fout.

#11

Met het request GetStyles kun je de SLD ad-hoc opvragen. Wel alleen in combinatie met de parameter &version=1.1.1. (lijkt in WMS 1.3.0 niet meer te bestaan)
Die SLD zul je dan zelf weer uiteen moeten rafelen (parsen met een XSLT, @antonbakker kom er maar in :slight_smile: ) om de rules er uit te vissen.

#12

Als dat werkt, ja. Omdat het niet in de capabilities gepubliceerd word dat het werkt, kun je er dus niet van uit gaan dat dat altijd zo blijft. Net als met de GetLegendGraphic die je eerder noemde: die word ook niet gepubliceerd in de capabilities (van de PDOK WMS services, althans). En daar vertrouw ik dus ook niet op.

Daarnaast: Capabilities parsen met een xpath is bovendien veel minder omslachtig dan met een XSLT, is mijn ervaring, dus dat zal met een dergelijke sld wel niet veel anders zijn… En dan heb ik meteen de legenda’s voor alle layers, en de getfeatureinfo url.

#13

Ook mijn eerdere GetLegendGraphic blijkt alleen in “&version=1.1.1” te werken.
Zolang die WMS-server versie 1.1.1.serveert mag je er dus wel op vertrouwen.

Blijkbaar is WMS 1.1.1 veel rijker dan WMS 1.3.0. Waarom dát zo is snap ik (nog) niet.

#14

Dat denk ik niet. Het betreffende request staat niet in het capabilities document, en daarmee geeft de server luid en duidelijk aan het request niet te ondersteunen. Dat ie toch iets terugstuurt als je ernaar vraagt is lief, maar zou ik niet op durven vertrouwen.

1 like
#15

Nee, want ook als ik de capabilities opvraag voor WMS versie 1.1.1 staat GetLegendGraphic NIET bij de mogelijke Requests. En dus kun je er, zoals Marco ook al zegt, NIET op vertrouwen dat dat een ondersteunde optie is. Daar is de capabilities nou net voor bedoeld: dat is wat de service publiceert om afnemers te laten weten wat ie kan. En ondanks dat GetLegendGraphic dus wel iets retourneert, en blijkbaar ook intern door de 1.1.1 service gebruikt word (zie voorbeeldje hieronder), geeft de service dus duidelijk aan dat GetLegendGraphic als afzonderlijk Request niet beschikbaar is.

Want dat is wel vreemd: onderstaand de Style voor kilometrering uit de twee verschillende capabilities:

<WMT_MS_Capabilities version="1.1.1">
<Style>
  <Name>kilometrering</Name>
  <Title>Kilometrering</Title>
  <LegendURL width="114" height="23">
     <Format>image/png</Format>
     <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://service.pdok.nl/prorail/spoorwegen/wms/v1_0?language=dut&amp;version=1.1.1&amp;service=WMS&amp;request=GetLegendGraphic&amp;layer=kilometrering&amp;format=image/png&amp;STYLE=kilometrering"/>
  </LegendURL>
</Style>
        
<WMS_Capabilities version="1.3.0">
<Style>
  <Name>kilometrering</Name>
  <Title>Kilometrering</Title>
  <LegendURL width="78" height="20">
    <Format>image/png</Format>
    <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://service.pdok.nl/prorail/spoorwegen/wms/v1_0/legend/kilometrering/kilometrering.png"/>
  </LegendURL>
</Style>

In versie 1.1.1 is de OnlineResource voor de LegendURL van deze Style een request naar GetLegendGraphic, in versie 1.3.0 is het een rechtstreekse link naar een PNGtje. Da’s wel vreemd.
Aan de andere kant: WMS Versie 1.1.1 Specs dateren van januari 2002, 1.3.0 van januari 2004. Dus zelfs de meest recente specs zijn al 19 jaar oud!

Oh: en dit

valt wel mee. Het hangt er volledig van af hoe de betreffende service geconfigureerd is. Tussen de functionaliteiten zit echt niet zo heel veel verschil, het is voornamelijk een verschil van de manier waarop.

#16

Alhoewel de 1.1.1. services nog wel aangeroepen kunnen worden adverteren en ondersteunen we deze niet officieel. Dat gezegd hebbende zijn we er ons van bewust dat dit nog wel gebruikt wordt en er verschillen zijn. We gaan nog onderzoeken hoe hier in de toekomst mee om te gaan.

Het klopt dat we bij 1.3.0 rechtstreeks naar een PNG verwijzen, dit doen we omdat niet alle dynamische legenda’s een goede uitleg/beeld geven bij het kaartbeeld. In die gevallen krijgen we legenda’s aangeleverd van data-aanbieders welke we vervolgens statisch uitserveren. In het kader van consistentie bieden we de legenda’s in alle WMS 1.3.0 services op die manier (statisch) uit.

#17

Aha. Daar kan ik me iets bij voorstellen inderdaad. Van de vector-gegevens die ik mbv Openlayers weergeef, probeer ik meestal ook een legenda te laten zien - maar als er een functie voor die symbologie word gebruikt, gaat dat falikant de mist in (dus dan maak ik het maar zelf met wat html-divjes). Als je legenda van tevoren kunt opmaken, dan kun je ze in dergelijke gevallen inderdaad vaak beter laten aansluiten op wat er op de kaart te zien is.

Prima! Scheelt ook weer server-cpu en dergelijke :slight_smile:

Dank voor de uitleg. En zou het niet eens tijd worden om 1.1.1 eenvoudigweg uit te faseren? Zelfs 1.3.0 is al 19 jaar oud, dus het lijkt mij dat alle bestaande software toch wel met 1.3.0 om zou moeten kunnen gaan…

1 like
#18

Nemen we mee in het onderzoek als één van de overwegingen. Bedankt (ook de rest) voor de feedback!

1 like
#19

Nog eentje dan:
mijn functionele behoefte is dat ik soms een WMS wil “nabouwen”, maar dan nét iets anders. Dan is het met “GetStyle” ophalen van de SLD een handige start.
Hetzelfde zou bereikt kunnen door de PDOK-SLDs beschikbaar te maken via GitHub (volgens mij is die wens jaren geleden ook een keer op dit forum voorbij gekomen.

1 like
#20

Dat mag je even wat meer context geven, want dat begrijp ik niet. Een WMS is wat het is. Als je daar iets anders voor wil hebben, dan heb je weinig keuze anders dan de achterliggende vector informatie te downloaden en zelf publiceren, lijkt mij. Maar dat is helemaal afhankelijk van je achterliggende vraag (jouw ‘functionele behoefte’ is een antwoord op een achterliggende informatievraag - en dus loop je hier een groot risico op een XY Probleem).

Hoewel je in Openlayers wel iets met CSS classnames kan doen, maar dat is redelijk beperkt (wel handig om grijswaarden bijvoorbeeld te maken van een OSM of een Top10NL bijvoorbeeld - wat dan weer praktisch is als ondergrond voor je eigen vector info…).