Focusgroep raadpleegdiensten (26 maart 2026)
- 1 Inleiding
- 2 Het Wegenregister downloaden
- 2.1 Basisproduct
- 2.1.1 Algemene productstructuur
- 2.1.2 Kanten
- 2.1.3 Richtingen
- 2.2 Afgeleid product
- 2.1 Basisproduct
- 3 Web Mapping Service (WMS)
- 3.1 Doel
- 3.2 Opbouw
- 3.3 Attribuutwaarden combineren in één kaartlaag
- 3.4 Opbouw, symbologie en tekortkomingen van de huidige WMS
- 3.4.1 Opbouw en symbologie
- 3.4.2 Tekortkomingen
- 3.5 Noden en wensen voor de nieuwe service
- 3.5.1 Wegsegmentstatus
- 3.5.2 Richting
- 3.5.3 Straatnamen
- 3.5.4 Dynamische segmentatie
- 3.5.5 Wegknopen en kruisingen
- 3.6 Opbouw van de nieuwe service
- 3.7 Sneuvelstructuur
- 3.7.1 Wegbeheerder
- 4 Andere raadpleegdiensten
Inleiding
Deze pagina bevat de voorbereiding voor de focusgroep raadpleegdiensten, waarop we de verschillende manieren bespreken waarop het vernieuwde Wegenregister ontsloten zal worden.
Doel van de focusgroep is om de voorstellen hieronder te valideren en bij te sturen waar wenselijk, en om resterende open vragen te bespreken.
Alle raadpleegdiensten zullen in eerste instantie beschikbaar zijn in Lambert 1972 én Lambert 2008.
Het Wegenregister downloaden
Het Wegenregister zal in twee varianten aangeboden worden als ESRI shapefile:
Een basisproduct
waarin elke lijngeometrie precies één wegsegment voorstelt, en
waarin dynamisch gesegmenteerde attributen opgenomen zijn in aparte tabellen.
Een afgeleid product
waarin dynamisch gesegmenteerde wegsegmenten opgeknipt worden, en
waarin elke lijngeometrie een stuk van een wegsegment voorstelt waarvoor alle attribuutwaarden identiek zijn.
Waarom twee varianten?
Het basisproduct
ontsluit het Wegenregister conform de geldende datastandaarden, met lijngeometrieën die we zo stabiel mogelijk willen houden, en
is gericht op gebruikers die geïnteresseerd zijn in data-analyses (denk: relationele tabellen joinen en gerichte query’s uitvoeren op een eigen kopie van het basisregister, etc.).
Het afgeleide product
ontsluit het Wegenregister in een vorm die het makkelijker maakt om wegeigenschappen te visualiseren (denk: verhardingstypes in kaart brengen, enkel wegen tonen met een bepaalde morfologie, etc.)
In het afgeleide product krijgen opgeknipte lijngeometrieën een tijdelijke identificator (WS_TEMPID) bovenop de permanente, stabiele wegsegmentidentificator (WS_OIDN).
Feedback:
Zijn ESRI shapefiles toekomstbestendig als bestandsformaat om het Wegenregister te ontsluiten?
Het Wegenregister zal in eerste instantie enkel als shapefile beschikbaar zijn voor download, maar Geopackage kan op termijn een goede aanvulling zijn.
Illustratie 1. Wegsegment 234432 is dynamisch gesegmenteerd voor het attribuut ‘morfologie’: halverwege wijzigt deze van ‘weg bestaande uit één rijbaan’ naar ‘pad’ – zie linkerafbeelding hieronder.
In het basisproduct (centrale afbeelding hieronder) komt dit wegsegment overeen met één lijngeometrie met objectidentificator WS_OIDN 234432.
In het afgeleide product (afbeelding rechts) wordt wegsegment met WS_OIDN 234432 opgeknipt in twee lijngeometrieën die elk een tijdelijke identificator (WS_TEMPID) meekrijgen (8765 en 8766 in het voorbeeld). Tussen beide lijngeometrieën wordt een schijnknoop (718) geplaatst.
In het afgeleide product worden zowel tijdelijke identificatoren (WS_TEMPID) als stabiele identificatoren (WS_OIDN) ontsloten – zie ook verderop.
Hieronder gaan we dieper in op de bestandsstructuur van beide producten.
Basisproduct
Algemene productstructuur
In het basisproduct is er een één-op-één relatie tussen wegsegmenten en lijngeometrieën.
Attributen die niet dynamisch gesegmenteerd zijn, met name ‘wegsegmentstatus’ en ‘geometriemethode’, komen mee in de tabel ‘Wegsegment’.
Attributen die dynamisch gesegmenteerd zijn, worden opgenomen in aparte tabellen ‘Att[attribuutnaam]’.
Wegsegment 234432 uit illustratie 1 heeft morfologie ‘weg bestaande uit één rijbaan’ van 0m tot 64,56m. Daarna heeft het morfologie ‘pad’. Dit resulteert in twee lijnen in de tabel ‘AttMorfologie'.
Metadata:
In de tabel ‘Wegsegment’ komt het tijdstip van aanmaak mee in de kolom ‘CREATIE’, en komt het tijdstip van laatste wijziging mee in de kolom ‘VERSIE’.
In de tabel ‘AttMorfologie’ komt enkel het tijdstip van laatste wijziging mee voor het record in de tabel (kolom ‘VERSIE’).
Feedback:
Kan het gebeuren dat een wegsegment bvb. géén morfologie heeft voor een deel van het segment?
Neen. Van- en totposities van wegsegmenten moeten netjes op elkaar aansluiten, en moeten gekend zijn over de ganse lengte van het wegsegment.
Zie ook Dynamische segmentatie | Afspraken rond dynamische segmentatie.
Kanten
De attributen ‘straatnaam’ en ‘wegbeheerder’ hebben een kant: ze zijn al dan niet van toepassing op de linkerzijde van de weg, de rechterzijde, of beide zijden. In datastandaarden zoals OSLO Fietsinfrastructuur worden er géén aparte linker- en rechterentiteiten opgenomen hiervoor, maar wordt er één entiteit opgenomen met een eigenschap ‘kant’. We spreken dus niet over de entiteiten ‘linkerstraatnaam’ en ‘rechterstraatnaam’, maar wel over de entiteit ‘straatnaam’ met de eigenschap kant (links, rechts, of beide).
Conform deze standaarden zal er in het basisproduct één tabel zijn voor de attributen ‘straatnaam’ en ‘wegbeheerder’, en geven we voor elke lijn in deze tabel aan op welke kant ze van toepassing is.
Illustratie 2. De straat in onderstaande afbeelding vormt de gemeentegrens tussen Linter en Kortenaken. In Linter heeft ze de straatnaam ‘Ransbergstraat’ en in Kortenaken heeft ze de straatnaam ‘Dorpsstraat’. We nemen bijgevolg twee lijnen op in de tabel ‘AttStraatnaam’ voor het corresponderende wegsegment 394809: één voor de straatnaam aan linkerzijde, en één voor de straatnaam aan rechterzijde. Aangezien ook de wegbeheerder verschillend is aan de linker- en rechterzijde van de weg, nemen we eveneens twee lijnen op in de tabel ‘AttWegbeheerder’.
Voor wegsegmenten die dezelfde straatnaam en/of wegbeheerder hebben aan linker- en rechterzijde, hoeft er slechts één lijn opgenomen te worden in de corresponderende tabel, met ‘KANT=3’ en ‘LBLKANT=beide'.
Hoe gaan we om met wegsegmenten die géén straatnaam hebben?
Nemen we voor deze wegsegmenten een lijn op in de tabel ‘AttStraatnaam’ met als ‘identificator' de waarde ‘-9’ ('niet van toepassing') en als ‘naam’ de waarde 'NULL’, zoals in de huidige download?
Of nemen we géén lijn op in de tabel ‘AttStraatnaam’ voor deze wegsegmenten?
(Analoog voor andere attributen, zoals wegcategorie en verkeerstypes?)
Feedback:
De voorkeur gaat uit naar de huidige manier van werken: we nemen een record op met waarde ‘-9’ en label ‘niet van toepassing’, zowel voor straatnaam als voor andere attributen. Weten dat een attribuutwaarde niet van toepassing is (of niet gekend in geval van waarde ‘-8’) is waardevol.
Wat met straatnamen voor trage wegen? De gemeente is hier leidend. Indien de straatnaam door de gemeente toegevoegd werd in het Adressenregister, kan deze gekoppeld worden aan wegsegmenten uit het Wegenregister.
Richtingen
Voor de verkeerstypes auto, fiets en voetganger nemen we aparte tabellen op in het basisproduct. Deze attributen hebben geen kant, maar wel een richting. Ook hier spreken we in het basisproduct over één entiteit met een richting (heen, terug of beide) als eigenschap.
Illustratie 3. Op wegsegment 1133 in onderstaand voorbeeld zijn auto’s enkel toegelaten in de heenrichting. Fietsers zijn toegelaten in beide richtingen, en voetgangers zijn eveneens toegelaten. Deze informatie wordt ontsloten in de tabellen ‘AttVerkeerstypeauto’, ‘AttVerkeerstypeFiets’ en ‘AttVerkeerstypeVoetganger’.
Er werd hier gekozen voor individuele tabellen per verkeerstype en niet voor één tabel waarin alle verkeerstypes gecapteerd worden, om volgende redenen:
Gebruikers zijn vaak slechts geïnteresseerd in één verkeerstype.
Als er in de toekomst nog extra verkeerstypes gecapteerd zouden worden, dan kunnen ook deze in een aparte tabel worden toegevoegd, zonder verdere wijzigingen aan het bestaande product.
Afgeleid product
In het afgeleide product heeft elke lijngeometrie voor elk attribuut precies één constante attribuutwaarde over haar volledige lengte. Dit resulteert in volgende productstructuur, waarin alle wegsegmentattributen meegenomen kunnen worden als kolommen in de tabel ‘Wegsegment’:
Voor de wegsegmenten 234432, 394809 en 1133 besproken in respectievelijk illustraties 1, 2 en 3 geeft dit onderstaand resultaat. Merk op
dat wegsegment 234432 uit illustratie 1 overeenkomt met meerdere tijdelijke identificatoren 8765 en 8766,
dat wegsegment 394809 een verschillende linker- en rechterstraatnaam heeft, en
dat wegsegment 1133 uit illustratie 3 toegankelijk is voor auto’s in de heenrichting, maar niet in de terugrichting.
In de tabel ‘Wegsegment’ van het afgeleide product is er precies één tabellijn voor elke ‘opgeknipte’ lijngeometrie (WS_TEMPID). Merk op dat dit enkel mogelijk is indien we de linker- en rechterkant van de attributen ‘straatnaam’ en ‘wegbeheerder’ expliciet als kolom meenemen. Stel dat we voor WS_TEMPID 9876 slechts één kolom ‘KANT’ hadden om de straatnaam van dit wegsegment aan te duiden. Dan hebben we twee lijnen nodig om dit te doen: één voor de linkerkant (Dorpsstraat) en één voor de rechterkant (Ransbergstraat), zoals in de tabel ‘AttStraatnaam’ uit het basisproduct.
In het afgeleide product willen we vermijden dat gebruikers relaties ('joins') moeten leggen tussen tabellen om attribuutinformatie te raadplegen. Daarom werd er in dit product voor gekozen om attributen met een kant in twee aparte kolommen (links en rechts) te ontsluiten. Om redenen van uniformiteit stellen we voor om ook attributen met een richting op deze manier te ontsluiten: één kolom voor de heenrichting, en één voor de terugrichting.
Feedback:
Hoe tijdelijk zijn WS_TEMPID’s?
Zeer tijdelijk. Deze worden telkens opnieuw gegenereerd bij de productaanmaak. De WS_TEMPID van een lijngeometrie kan van dag één op dag twee wijzigen zonder dat de corresponderende geometrie wijzigt. Het is absoluut niet de bedoeling dat WS_TEMPID’s gebruikt worden ter vervanging van de permanente identificatoren van wegsegmenten (WS_OIDN), en dat bvb. werkschema’s van gemeenten gekoppeld worden aan tijdelijke identificatoren. Het koppelen van data moet steeds gebeuren met de WS_OIDN van een wegsegment.
Van- en totposities voor verschillende (dynamisch gesegmenteerde) attributen van eenzelfde wegsegment zullen op elkaar afgestemd worden, om te vermijden dat er in het afgeleide product geometrieën voorkomen die korter zijn dan 1m.
Stel bvb. dat de wegbeheerder en straatnaam van een wegsegment X wijzigen op een gemeentegrens. Dan is volgende situatie ongeldig:
X heeft
wegbeheerder A van positie 0m tot positie 50m en
wegbeheerder B van positie 50m tot positie 100m.
X heeft
straatnaam C van positie 0m tot positie 50,10m en
straatnaam D van positie 50,10m tot positie 100m.
Merk op dat dit, indien geldig, in het afgeleide product zou resulteren in drie lijngeometrieën voor wegsegment X, elk met een tijdelijke identificator:
een lijngeometrie X1 van 0m tot 50m,
een lijngeometrie X2 van 50m tot 50,10m, en
een lijngeometrie X3 van 50,10m tot 100m.
De lijngeometrie X2 is in dit geval ongeldig omdat we ook in het afgeleide product eisen dat geometrieën steeds minimaal 1m lang zijn.
In de beheertools zal verwacht worden dat in bovenstaand voorbeeld de van- en totposities voor straatnaam en wegbeheerder naar elkaar toe getrokken worden wanneer deze op minder dan 1m van elkaar liggen, zodat deze situatie zich nooit voordoet.
Beide producten zullen in de toekomst beschikbaar zijn met versnijding, bvb. op gemeentegrenzen. Minstens voor het basisproduct wordt ook bekeken om verschilbestanden te voorzien, zoals voor het GRB.
Idealiter kunnen de producten ook automatisch gedownload worden (beschikbaar via API).
Web Mapping Service (WMS)
Doel
Een WMS laat toe om geodatasets als kaarten te laden, en om deze data rudimentair te bevragen in een kaarttoepassing of GIS software. Een kaart wordt ingeladen als een afbeelding (JPEG, PNG, etc.) met een vooraf gedefinieerde opmaak/legende.
Naast het visuele aspect laat de WMS ook puntbevraging van objecten toe: bij een klik op op een wegsegment krijg je de identificator en attribuutwaarden mee voor dit object.
(Waarvoor) gebruiken jullie de Wegenregister WMS?
Wegennetwerk visualiseren?
Wegsegmentinformatie opvragen (puntbevraging)?
Nog?
Lokale en andere overheden maken weinig tot geen gebruik van de WMS service.
Vaak wordt het GRB als basisvisualisatie gebruikt, en in de GRB WMS zijn wegsegmenten ook zichtbaar.
De WMS wordt vooral gebruikt in beheertools zoals LARA, en als visualisatie van het wegennet in Geopunt.
Niettemin is er veel interesse in visualisaties/legendes van het register, omdat deze ook als .sld of .lyr(x) file meegegeven zouden kunnen worden als bijlage bij de download.
Als deze files meekomen, hoeven afnemers niet langer zelf een symbologie op te zetten voor data uit het register, wat hen veel tijd en werk kan besparen.
Opbouw
Een WMS is opgebouwd in drie hiërarchische niveaus:
bovenaan de service zelf,
daaronder groepen van lagen, en
daaronder individuele lagen of 'map layers'.
Groepen zijn louter containers voor één of meerdere map layers. Alle styling/vormgeving gebeurt op het onderste niveau van map layers. Een map layer komt overeen met één symbool in de legende van een WMS. Zo worden er in de Gebouwenregister WMS verschillende symbolen gebruikt om de verschillende statussen van gebouwen te visualiseren:
Attribuutwaarden combineren in één kaartlaag
Als we in een WMS een apart symbool willen gebruiken voor een combinatie van attribuutwaarden, dan moeten we die combinatie ook als aparte laag definiëren.
Stel bvb. dat we verschillende lijnsoorten willen gebruiken voor statussen, en verschillende kleuren voor morfologieën, zoals in deze tabel:
Groep | Kaartlaag | Symbool |
|---|---|---|
Wegsegmentstatus | gepland | |
| gerealiseerd | |
| … |
|
Morfologie | autosnelweg | |
| fietspad | |
| aardeweg | |
| … |
|
Het is niet mogelijk om deze symbolen te combineren, tenzij je ze als een aparte laag definieert. Dus als we willen dat geplande fietspaden gevisualiseerd worden a.d.h.v. een groene stippellijn, gerealiseerde fietspaden als een volle groene lijn etc., dan moeten we hiervoor aparte lagen definiëren en kunnen we kaartlagen niet langer groeperen op attribuutniveau:
Groep | Kaartlaag | Symbool |
|---|---|---|
Wegsegmentstatus & morfologie | geplande autosnelwegen | |
geplande fietspaden | | |
geplande aardewegen | | |
… |
| |
gerealiseerde autosnelwegen | | |
gerealiseerde fietspaden | | |
gerealiseerde aardewegen | | |
… |
|
We kunnen niet voor elke combinatie van attribuutwaarden aparte kaartlagen gaan definiëren. Voor status en morfologie alleen al zou dit 5 x 12 = 60 kaartlagen opleveren, en zou dit betekenen dat je bvb. 12 kaartlagen moet aanvinken/selecteren om alle gerealiseerde wegsegmenten te zien.
We zullen dus selectief moeten zijn in het definiëren van aparte kaartlagen voor combinaties van attribuutwaarden.
Opbouw, symbologie en tekortkomingen van de huidige WMS
Opbouw en symbologie
De huidige service visualiseert wegsegmenten o.b.v. hun morfologische wegklasse.
Voor elke morfologische wegklasse werd één kaartlaag gedefinieerd. Autosnelwegen zijn rood gekleurd, aardewegen bruin, wandel- en/of fietswegen groen, veerverbindingen blauw en alle andere wegen grijs. Ook lijndiktes en zoomniveaus vanaf dewelke een wegsegment zichtbaar zijn, variëren afhankelijk van de morfologische wegklasse van het segment.
Verder is er een aparte laag met straatnaamlabels.
Tekortkomingen
De huidige service is te sterk gefocust op één attribuut, nl. morfologische wegklasse. Waarden voor andere attributen, bvb. wegsegmentstatus, zijn niet zichtbaar, hoewel hier nood aan is (visualisatie van geplande wegen, wegen buiten gebruik, gehistoreerde wegen).
De huidige service volstaat niet als visualisatie voor de toekomstige beheertools (LARA, GeoIT, etc.)
Beheer van wegknopen vereist visualisatie van wegknopen
Beheer van dynamisch gesegmenteerde attributen zal gebruiksvriendelijker zijn als we ook kunnen zien van en tot welke positie een attribuutwaarde van toepassing is langsheen het wegsegment.
Beheer van toegelaten verkeerstypes zal gebruiksvriendelijker zijn als we ook richtingen kunnen visualiseren waarin automobilisten of fietsers mogen rijden.
Kleuren van kaartlagen in de huidige service zijn moeilijk zichtbaar in combinatie met bepaalde achtergrondlagen.
Noden en wensen voor de nieuwe service
Met de nieuwe WMS service willen we naar een symbologie waaruit je méér kan afleiden dan louter de morfologie en straatnaam van een wegsegment. Idealiter is het daarnaast ook mogelijk om ‘op het zicht’
wegknopen te identificeren
de status van een wegsegment af te leiden (incl. gehistoreerde wegsegmenten)
de richting te achterhalen waarin auto’s / fietsers al dan niet toegelaten zijn op het wegsegment
te zien of een wegsegment dynamisch gesegmenteerd is voor één of meerdere attributen
Hieronder bespreken we deze aspecten om beurt, samen met enkele verdere topics. Daarna gaan we over tot enkele concrete scenario’s voor de opbouw van de nieuwe service.
Wegsegmentstatus
In de huidige WMS service worden geplande wegen en wegen buiten gebruik mee ontsloten in dezelfde symbologie als gerealiseerde wegen. Verwijderde wegen worden niet mee ontsloten.
Voor de nieuwe service stellen we voor om een aparte kaartlaag te voorzien per wegsegmentstatus, zodat wegsegmenten met status gepland/gehistoreerd/buiten gebruik/niet gerealiseerd mee gevisualiseerd kunnen worden met een eigen symbologie.
(Illustratie: WS_OIDN 1175118)
Richting
Om richtingen te visualiseren waarin auto’s of fietsers toegelaten zijn, stellen we voor om
om aparte kaartlagen te voorzien per verkeerstype (auto / fiets / voetganger), en
om met pijlen te werken die aangeven in welke richting verkeerstypes toegelaten zijn, bvb. zoals in de illustraties hieronder.
Feedback:
Indien verkeer toegelaten is in beide richtingen, zou je ook zonder marker kunnen werken. Is dit performanter bij het laden van de service?
Een ander alternatief is om de lijnen achterwege te laten en enkel met markers te werken voor verkeerstypes, zodat deze lagen beter combineerbaar worden met andere lagen in de service.
Straatnamen
Straatnamen kunnen, zoals nu reeds het geval is, als labels toegevoegd worden (met vermelding van zowel linker- als rechterstraatnaam indien verschillend).
Dynamische segmentatie
Om duidelijk te maken dat attribuutwaarden wijzigingen in de lengterichting van een wegsegment, stellen we voor om aparte symbolen te voorzien voor verschillende attribuutwaarden.
Wegknopen en kruisingen
Om het decentraal beheer van wegknopen en kruisingen mogelijk te maken in LARA, moeten deze gevisualiseerd kunnen worden. We stellen voor om aparte kaartlagen te voorzien voor wegknopen, gelijkgrondse kruisingen en ongelijkgrondse kruisingen (symbologie nog nader te bepalen).
Opbouw van de nieuwe service
Vertrekpunt: lagengroep o.b.v. hun wegsegmentstatus
De absolute basis voor het visualiseren van het Wegenregister is een kaartlaag met het actieve wegennet, bij voorkeur in een neutrale symbologie zodat deze makkelijk gecombineerd kan worden met andere (achtergrond)lagen.
Naast deze gerealiseerde wegen stellen we voor om wegen met een andere status in dezelfde lagengroep te visualiseren a.d.h.v. verschillende lijnsoorten, al dan niet met een verschillende kleurentint.
In onderstaande voorbeelden zien we hoe verschillende grijstinten combineren met twee achtergrondlagen: het GRB (kleur) enerzijds en orthofoto’s anderzijds. We vertrekken links bij de grijstint van de meeste wegen in de huidige WMS. Naarmate we naar rechts vorderen, wordt de grijstint donkerder. Welke van deze grijstinten geniet jouw voorkeur als basisvisualisatie van het actieve wegennet?
Feedback:
In het GRB worden wegsegmenten net in een lichtere grijstint gevisualiseerd.
Voorkeur gaat uit naar een grijstint die donkerder is dan die van de huidige service, o.w.v. compatibiliteit met andere kaartlagen.
Andere attributen
Voor andere gewenste attributen definiëren we telkens één corresponderende lagengroep, met daaronder één laag per attribuutwaarde.
Op het niveau van attribuutwaarden stellen we voor om enkel gerealiseerde wegsegmenten te visualiseren, om twee redenen:
Gebruikers die geïnteresseerd zijn in attributen zoals morfologie, wegcategorie of verharding, zijn doorgaans vooral (enkel) geïnteresseerd in wegen met status ‘gerealiseerd’.
Om attribuutinformatie te tonen in combinatie met meerdere statussen moeten we elk van deze combinaties als aparte laag definiëren, wat zorgt voor een vermenigvuldiging van het aantal kaartlagen – zie ook Focusgroep raadpleegdiensten (26 maart 2026) | Attribuutwaarden combineren in één kaartlaag.
Omdat er te veel combinaties van attributen en attribuutwaarden zijn, zal niet elke combinatie van kaartlagen een visueel aantrekkelijk resultaat opleveren.
Voorstel: we zorgen er voor
dat elk attribuut a.d.h.v. een duidelijke kleurencode gevisualiseerd kan worden, en
dat elk attribuut onder de neutrale lagen voor wegsegmentstatussen gevisualiseerd kan worden.
Wanneer meerdere kaartlagen met eenzelfde lijndikte en een verschillende kleurcode gecombineerd worden, dan ‘wint’ de laag die bovenaan ligt.