Ontbrekende herhalende openbare ruimte labels bij wegen van meer dan 600 meter

De BGT Handleiding zegt:
Als een openbare ruimte een lengte heeft van meer dan 300 meter, dan is het noodzakelijk om de naam vaker af te beelden.
bron: https://www.geonovum.nl/uploads/standards/downloads/BGTGegevenscatalogus111.pdf

  • Op deze kaart selecteer ik wegvakken in het NWB van meer dan 600 meter meter die een Openbare Ruimte Label in het NWB hebben.
  • Vervolgens zoek in de Openbare ruimte labels het label voorkomt van het type ‘Weg’.
select w.wvk_id, w.bag_orl, st_length(w.geom), w.geom, 
count(*)
from wegvakken w
left join  orl_ogc_20251031 b 
on w.bag_orl=b.bag_opr
where wegbehsrt <> 'R'
and bag_orl is not null 
and b.openbareruimtetype ='Weg'
and st_length(w.geom) > 600
group by  w.wvk_id, w.bag_orl, st_length(w.geom), w.geom

Alle wegvakken van meer dan 600 meter zouden in beginsel 2 labels moeten hebben. Op de kaart zie je ‘rode gemeentes’ waar dat niet het geval is, naast veel ‘groene gemeentes’.

Zou je kunnen stellen dat de ORL’s in die gemeentes niet conform de specs zijn?

Nog even de top 20 gemeentes waar dit het vaakst voorkomt

gme_naam count
Ede 374
Noordoostpolder 359
Hof van Twente 335
Emmen 285
Weststellingwerf 250
Hulst 242
Leudal 238
Apeldoorn 230
Opsterland 226
Borger-Odoorn 215
Amsterdam 199
Peel en Maas 193
Raalte 191
Echt-Susteren 191
Ooststellingwerf 189
Deventer 182
Nederweert 176
Medemblik 176
Weert 174
Haarlemmermeer 163

Helemaal waar dat de weg van meer dan 600 meter ìn een gemeente ligt. Maar hou je er ook rekening mee dat de weg een bronhouderscode kan hebben van een niet-gemeente?

Of kan het zo zijn dat van bijvoorbeeld een provinciale weg de bgt afbakening van de weg de provincie doet en de gemeente de ORL moet toevoegen aan die weg?

En vergeet niet dat die labels geplaatst worden om een goede kartografische weergave te krijgen, niet om een correcte object-registratie te doen…

Je zou natuurlijk ook kunnen stellen, dat dit soort labels zoals openbareruimtenaam een overblijfsel zijn uit het CAD-tijdperk en ze eigenlijk een attribuut zouden moeten zijn van de daadwerkelijke objecten. De plaatsing en cartografische (schreef ik het toch bijna met een “ḱ”) visualisatie van de labels kan dan worden bepaald op het moment van weergave, niet op het moment van registratie.

2 likes

@ThomasHaarlem: Goed punt. De telling laat zien binnen welke gemeente iets gebeurt, maar dat is niet hetzelfde als wie de bronhouder is. Dus het zegt op zichzelf niets direct over de gemeente. (Al is het wel opvallend dat de gemeentegrenzen goed zichtbaar zijn; dat zegt dus indirect toch iets over de gemeente.)

De analyse is uitgevoerd op wegvakniveau. Als meerdere wegvakken dezelfde ORL hebben, is dat nog niet meegenomen.

Ook dank aan @sbjager en @emacgillavry voor de duiding: het oorspronkelijke doel van deze kaart is cartografie, niet de naamgeving van objecten.

Aha nu ik je openingspost beter lees: Begrijp ik goed dat er in het NWB hele lange wegvakken zijn (meer dan 600 meter) en dat je dat vergelijkt met de BGT?
Want wat ik ook heb begrepen is dat (sommige?) gemeenten de BGT-wegen opdelen in kleinere wegvakken ten behoeve van de BOR (beheer openbare ruimte).
Kan het dan goed zijn dat ook in die BGT keurig om de 300 meter een ORL staat, of in elk geval in elk opgedeelde BGT-wegvak, maar dat dat niet terugkomt uit je analyse omdat die uitgaat van één lang wegdeel?

Je ziet inderdaad heel keurig hoe de rode lijnen de gemeentegrenzen volgen, dus het zal een bronhouders-dialect zijn :slight_smile:

Hoe lees je je openbare ruimtelabels in? Ik heb de GML Light gedownload, en kijk daar rechtstreeks in. En dan zie ik in Medemblik dat bijvoorbeeld de Poelweg 2 features heeft, waarvan de 1e 3 plaatsingspunten heeft, en de 2e 1. In totaal komt de Poelweg als label dus 4 keer voor, maar het gaat maar om 2 featuremembers. Dus dat zou een oorzaak kunnen zijn, dat sommige bronhouders 1 plaatsingspunt per label aanhouden, en anderen meerdere plaatsingspunten per label. Is misschien ook afhankelijk van welke software ze gebruiken.

Ik gebruikte de openbareruimtelabel uit de PDOK plugin:
https://api.pdok.nl/lv/bgt/ogc/v1/collections/openbareruimtelabel?f=json

Ik heb Medemblik ook gedownload, ook daar heb ik maar 2 labels voor de Poelweg:
Download via GML light (PDOK download viewer)

Of gebruik ik Qgis niet goed?

Ik denk dat dat wel meevalt, ik vrees alleen dat QGis alleen de featuremembers leest met 1 punt voor elk featuremember. En dan vallen er bij de Poelweg dus 3 weg, omdat 1 van die labels een multipunt is. Ik weet in QGis zo gauw geen oplossing, maar er zijn hier mensen die veel meer weten van QGis dan ik :wink:
En dit soort problematiek is wel eerder voorgekomen. Ik zal eens zoeken hier op het forum, want als ik me goed herinner is iets vergelijkbaars eerder langs gekomen hier (met de Top10 wegen - lijn + vlak of zoiets).

Vermoedelijk zal je originele analyse dus wat anders uitpakken dan nu, en wederom vermoedelijk ligt de oorzaak bij de software die de diverse bronhouders gebruiken.

Je noemt de Poelweg in gemeente Medemblik. Deze openbare ruimte ligt in twee BAG-woonplaatsen: Medemblik en Oostwoud. Per BAG-woonplaats wordt er in de BGT één openbareruimtelabel gemaakt. Dat verklaart waarom je twee openbareruimtelabels krijgt.

Een openbareruimtelabel kan meerdere plaatsingspunten (labelposities) bevatten. Die plaatsingspunten zie je ook in de BGT-visualisaties van PDOK.

Hieronder het openbareruimtelabel van de Poelweg in BAG-woonplaats Medemblik (gedownload via de PDOK download viewer). Dit openbareruimtelabel heeft 6 plaatsingspunten.

<imgeo:orlLk01T StUF:entiteittype="ORL" StUF:functie="update">
    <imgeo:parameters>
    <StUF:mutatiesoort>T</StUF:mutatiesoort>
    <StUF:indicatorOvername>V</StUF:indicatorOvername>
</imgeo:parameters>
    <imgeo:object StUF:entiteittype="ORL" StUF:verwerkingssoort="T">
        <imgeo:identificatie>
    <imgeo:namespace>NL.IMGEO</imgeo:namespace>
    <imgeo:lokaalID>G0420.339aebe8017a4d7bb44c4915185dc983</imgeo:lokaalID>
</imgeo:identificatie>
<imgeo:creationDate>2017-05-23</imgeo:creationDate>
<imgeo:terminationDate xsi:nil="true" StUF:noValue="geenWaarde" />
<StUF:tijdstipRegistratie>20170523000000</StUF:tijdstipRegistratie>
<imgeo:bronhouder>G0420</imgeo:bronhouder>
<imgeo:inOnderzoek StUF:metagegeven="true" xsi:nil="true" StUF:noValue="geenWaarde" />
<imgeo:relatieveHoogteligging>0</imgeo:relatieveHoogteligging>
<imgeo:bgt-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#Status">bestaand</imgeo:bgt-status>
<imgeo:plus-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#VoidReasonValue" xsi:nil="true" StUF:noValue="geenWaarde" />
        <imgeo:identificatieBAG_OPR>0420300000000076</imgeo:identificatieBAG_OPR>
        <imgeo:openbareRuimteNaam>
            <imgeo:tekst>Poelweg</imgeo:tekst>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>133836.960 527972.753</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>87.4</imgeo:hoek>
            </imgeo:positie>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>133937.849 528047.532</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>-27.1</imgeo:hoek>
            </imgeo:positie>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>134096.242 528131.401</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>-32.4</imgeo:hoek>
            </imgeo:positie>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>134338.923 528291.799</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>-34.2</imgeo:hoek>
            </imgeo:positie>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>134561.069 528439.244</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>-31.5</imgeo:hoek>
            </imgeo:positie>
            <imgeo:positie>
                <imgeo:plaatsingspunt><gml:Point xmlns:gml="http://www.opengis.net/gml">
            <gml:pos>134792.595 528573.350</gml:pos>
          </gml:Point></imgeo:plaatsingspunt>
                <imgeo:hoek>-31.5</imgeo:hoek>
            </imgeo:positie>
        </imgeo:openbareRuimteNaam>
        <imgeo:openbareRuimteType codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#TypeOpenbareRuimte">Weg</imgeo:openbareRuimteType>
    </imgeo:object>
</imgeo:orlLk01T>

Je gebruikt nu in QGIS de laag ‘Openbare Ruimte Label (ORL)’ van type ‘OGC API-Features’ uit de PDOK-plugin. Die laag laat maar één van die plaatsingspunten zien, en is dus niet geschikt voor je analyse.
In plaats daarvan zou je alle plaatsingspunten uit het openbareruimtelabel moeten gebruiken.


Hartelijk dank, het is gelukt

De data gedownload via…
ogr2ogr --debug on -overwrite ^
-f GPKG bgt20251001.gpkg ^
-nln bgt_openbareruimtelabel ^
-lco GEOMETRY_NAME=geom ^
-progress ^
-s_srs EPSG:28992 -t_srs EPSG:28992 ^
“OAPIF:Basisregistratie Grootschalige Topografie (OGC API)” ^
openbareruimtelabel

De analyse waarmee ik begon wordt daarmee ook beter, het aantal opvallende gemeentes neemt af.

2 likes

Bedankt voor de terugkoppeling, fijn dat het gelukt is.
Dit ziet er inderdaad al een stuk beter uit!