De BAG specificeert voor verblijfobject ééndimensionale geometrie (punt) en voor standplaats en ligplaats tweedimensionale geometrie (vlak).
Binnen RSGB wordt voor verblijfobject de mogelijkheid van tweedimensionale geometrie (vlak) toegevoegd. Dat betekent dat we voor verblijfobject (en ook voor overig gebouwd object) zowel punt als vlakgeometrie kunnen vastleggen. Een goede zaak.
Voor standplaatsen en ligplaatsen (en overige terreinen) kent RSGB echter alleen vlakgeometrie. Zou het niet wenselijk zijn om binnen RSGB ook voor standplaatsen, ligplaatsen en overige terreinen (benoemd terrein) de puntgeometrie te definiëren. Ik kan mij voorstellen dat dat nuttig is voor bijvoorbeeld de weergave van huisnummers van standplaatsen en ligplaatsen op een huisnummerkaart.
Overigens staat StUF bg 03.10 op dit moment puntgeometrie voor benoemd terrein toe, omdat gebruik wordt gemaakt van het supertype TGO.
In BGT / IMGeo kennen we OVERIG BOUWWERK. Dit is hetzelfde objecttype als OVERIG GEBOUWD OBJECT en in een volgende versie van RSGB wordt OVERIG GEBOUWD OBJECT vervangen door OVERIG BOUWWERK. Maar OVERIG BOUWWERK kent een PuntLijn(Multi)Vlak geometrie. Heeft VERBLIJFSOBJECT dan ook een dergelijke geometrie of is bij een verblijfsobject lijngeometrie en multivlakgeometrie helemaal niet mogelijk?
In BGT /IMGeo zijn overigens begroeide terreindelen e.d opgenomen en daarvan legt men alleen vlakgeometrie vast. Het zijn weliswaar andere objecttypen maar zegt dit -als leek zijnde- niet al iets over het niet kunnen vastleggen van puntgeometrie bij BENOEMD TERREIN?
Volgens pagina 5 van de catalogus BGT v1 kan een overig bouwwerk alleen (multi)vlak zijn. Een (mulit)vlak of zelfs 3D geometrie wordt voor een Verblijfsobject niet uitgesloten in de toekomst van BAG (p44 catalogus BGR), maar lijkt me vooralsnog niet aan de orde. Om op de oproep van Ruud terug te komen: voor de weergave is het niet nodig om puntgeometrie toe te voegen, elk pakket kan de centroide uitrekenen en een text op die plek tonen. Het is eerder uit kosten/inspanningsoverwegingen dat een Verblijfsobject is versimplificeerd naar een puntje. Lijkt me niet logisch iets (stand/lig/bouwwerk) dat al een polygoon is te vereenvoudigen. Ik zou eerder pleiten om de vlak-geometrie van een Pand te hergebruiken voor een Verblijfsobject.
@Barend: even terugkomend op de BGT. Op pagina 87 staat dat een overige constructie Punt-, lijn-, vlak- of multivlakgeometrie kent. En overig bouwwerk is een subtype van overig constructie. Eerlijkheidshalve vind ik het behoorlijk verwarrend hoe het gegevensmodel opgezet is. Klaarblijkelijk moet ik elders lezen wat de geometrie is van een objecttyp. lekker duidelijk!
@Ruud: de BAG beperkt de geometrie van het verblijfsobject niet tot punten. Bij de definitie van vbo-geoemtrie staat:
Je kunt dus ook vbo's krijgen met een vlak ipv een punt. In het RSGB is voor VBO binnen de gegevensgroep BAG-gegevens wel de beperking opgelegd dat het om punten gaat. Daarbij kan een vbo ook een vlak hebben. Feitelijk wijkt het RSGB hier dus af van de catalogus BAG.
Mogelijk is dit veroorzaakt doordat de eerste versie(s) van de LV BAG alleen punten accepteerde. Inmiddels zijn ook vlakken toegestaan. Ik geloof dat er momenteel maar één gemeente is die vlakken aanlevert voor vbo's.
Het lijkt me dus goed om een algemene oplossing te zoeken waarbij adrespunten worden berekend. Als er toch behoefte bestaat om punten op te slaan voor het plotten van adressen in de kaart, dan stel ik voor die ook bij de adressen op te nemen en niet bij de objecten. Dan heb je meteen de mogelijkheid om hoofd- en nevenadressen bij de betreffende (voor-) deur te plotten ipv op dezelfde plek in het vbo.
Sid: Deze situatie roep destemeer om duidelijkheid. Als het correct is wat jij zegt, is er dus één gemeente die geen BAG gegevens kan uitwisselen met StUF bg, omdat de geometrie van VBO niet past binnen StUF. Daarom is het een goede zaak dat nu voor VBO beide vormen van geometrie mogelijk worden.
Maar omdat de meerderheid van de gemeenten bij VBO alleen puntgeometrie heeft, zal vooralsnog VBO beide vormen van geometrie moeten hebben. Het toevoegen van een extra puntgeometrie bij adres is een leuk idee, maar komt denk ik niet voort uit een praktische behoefte bij gemeenten.
Diezelfde flexibiliteit (twee mogelijke vormen van geometrie) bepleiten wij voor de andere "adresseerbare objecttypen". De gemeenten hebben dan tenminste mogelijkheden om te kiezen waarmee ze werken.
Ruud,
Het toevoegen van puntgeometrie voor lig- en standplaatsen lijkt mij niet nuttig. Voor deze objecten zijn gemeenten immers al verplicht om vlakken aan te leveren, daarvoor is geen keuze mogelijk. Waarom zouden ze dan ook nog punten toe gaan voegen? Dit geeft meer werk voor feitelijk minder informatie. Je moet je ook ernstig afvragen wat de betekenis is van een puntgeometrie van een benoemd vlakje aarde. De puntgeometrie van een VBO is natuurlijk semantisch gezien al discutabel, maar is veel minder werk dan een vlak. Voor lig- en standplaatsen hebben we al vlakken, dus waarom zouden we daaraan nog een semantisch discutabel gegevens als puntgeometrie toevoegen?
Als het gaat om de positie van het adres, dan pleit ik nog steeds voor adrespunten: neem de informatie op waar hij thuis hoort. Maak deze optioneel en bij een lege waarde kan de software altijd nog kiezen om de geometrie van het object te kiezen voor het tekenen van een adres.
Voor het overige terrein kan ik me dan wel weer voorstellen dat je gemeenten de keuze geeft voor registratie van punten of vlakken. Hiervoor is immers geen (wettelijke) verplichting tot het registreren van de (moeilijker te onderhouden) vlakken.