Software struikelt
over gaten en overlap
Bestaande oplossingen:
automatisch repareren van
een planaire partitie
Fig. 3 Het vertalen van cirkelbogen naar expliciete coördinaten ('stroken') kan leiden tot een opeenhoping van 'slivers', omdat de cirkelbogen in twee verschil
lende richtingen - eenmaal voor het rechtervlak, eenmaal voor het linkervlak - worden behandeld.
lende organisaties en deze buurobjecten
niet in onderlinge samenhang zijn afgeba
kend. Figuur i laat zien dat het definiëren
van dezelfde grens door verschillende
BGT-bronhouders in de data van de BGT-
pilots leidde tot niet goed aansluiten van
geometrieën (iedere kleur staat voor één
bronhouder).
Regels in de BGTgegevenscatalogus
(BGT, 2012) over Topologie en Afstem
ming tussen bronhouders
Over topologie: "De vlakobjecten
in de BGT op maaiveldniveau, dus
op niveau nul, partitioneren de
ruimte. Dat betekent dat elk van deze
objecten topologisch gestructureerd
moet zijn, dat deze objecten naadloos
op elkaar aan moeten sluiten en er op
maaiveldniveau geen gaten mogen
voorkomen en dat deze objecten
elkaar niet mogen overlappen.
Objecten op een niveau ongelijk aan
nul doen niet mee in de topologische
structuur."
Over topologie tussen verschil
lende bronhouders: "De BGT
beschrijft objecten die worden
aangeleverd door bronhouders.
Een object valt altijd geheel binnen
het gebied van één bronhouder.
Bronhoudergrenzen vallen samen
met objectbegrenzingen en 'bewe
gen mee'wanneer er mutaties in
de objectbegrenzingen optreden.
Deze regels vereisen dat tussen
bronhouders afstemming nodig is
over de objectafbakeningen op de
bronhoudergrenzen."
De slivers komen zeker niet alleen voor op
de grenzen van verschillende bron houders.
Zo kan ook het exporteren van ruimtelijke
data tot problemen leiden. Bijvoorbeeld
wanneer een Shapefile naar GML wordt
geëxporteerd en coördinaten worden afge
rond naar millimeter, zoals aangegeven in
de BGT-cata log us: "De coördinaatgetallen zijn
op miHimeternauwkeurigheid,]Zo nodig
wordt daartoe afgerond". Door afronding
kunnen coördinaten over kleine afstand ver
schuiven met slivers en overlap tot gevolg.
Hierdoor kunnen ook oorspronkelijke valide
polygonen niet-valide worden vanwege
zelf-doorsnijding (zie figuur 2).
Een laatste oorzaak die
we voor de slivers heb
ben gevonden in onze
testen is het definiëren
van gekromde grenzen met cirkelbogen in
CAD software voordat het in een GlS-omge-
ving komt waar BGT-data (of de voorloper
ervan) wordt beheerd. In de GIS-omgeving
worden de cirkelbogen vaak vertaald in
expliciete coördinaten, ook al zijn GM_Arcs
toegestaan in de BGT. Bij twee vlakken die
gescheiden worden door zo'n cirkelboog
wordt bij conversie voor elk vlak afzonderlijk
de cirkelboog in coördinaten vertaald. Dit
leidt tot een opeenvolging van slivers die
met het oog niet of nauwelijks zichtbaar zijn,
zoals bleek in onze testen (zie figuur 3).
Het automatisch detecteren en repareren
van gaten en overlap in een landsdekkende
BGT is niet triviaal. Standaard softwaresys-
temen als Oracle, ArcGIS, FME en PostGIS
bieden hiervoor weliswaarfunctionaliteit,
maar deze zijn alle gebaseerd op het bere
kenen van een planaire
graaf en het'snappen'
van vertices. Deze
aanpak, in combinatie
met de vaak enorme
hoeveelheid data die gecheckt moet worden
en het grote aantal minieme slivers, doet
software nogal eens crashen of is erg traag.
Bovendien is veelal extra werk nodig om
de eenmaal gedetecteerde problemen te
analyseren. Maar het grootste knelpunt van
de standaardoplossingen is dat geen van alle
een robuuste oplossing biedt voor het auto-
Fig. 4 Er bestaat geen optimale waarde voor een snapafstand die op een gehele dataset kan worden
toegepast. In dit geval wordt een deel van de polygon onterecht tot een lijn geconverteerd vanwege
een te grote tolerantiewaarde.
Geo-lnfo 2012-8 5
