binnen de tolerantiewaarde ligt, dan
zou het systeem moeten beslissen de
polygoon aan te passen binnen de ge
geven tolerantie (en feitelijk een nieu
we representatie generen). Deze nieu
we representatie kan dan geldig of on
geldig zijn afhankelijk van de specifie
ke configuratie. Merk op dat buitenrin
gen van een polygoon tegen de klok in
zijn gespecificeerd en dat de binnen
ringen met de klok mee gegeven zijn
in de testpolygonen. Er zouden meer
testvarianten gemaakt kunnen wor
den door de oriëntatie om te draaien
(dit is nu alleen gedaan bij testpoly
goon 1, waarbij beide varianten zijn
meegenomen). Verder kunnen ringen
die zichzelf raken gemodelleerd wor
den als één ring of als verschillende
ringen. In de testpolygonen is steeds
de verschillende ringenvariant geko
zen, behalve bij testpolygoon 4 waar
beide mogelijkheden worden getest:
4a, de verschillende ringenvariant
(zonder een expliciet punt waar de rin
gen elkaar wel exact raken) en 4b, de
'enkele zelfralcende ring'-optie. Er is
zelfs een derde variant denkbaar (nog
niet getest): twee verschillende ringen
maar dan wel in beide ringen het raak
punt (identiek) opnemen. Behalve deze
varianten (op oriëntatie en hoe om te
gaan met rakende ringen), is er nog
een aantal andere testpolygonen te
verzinnen. Het is belangrijk om al deze
typen polygonen te verzamelen om zo
de compleetheid (correctheid) van de
relevante standaarden te evalueren.
We hebben de testpolygonen in ver
schillende geo-DBMS'en getest: Oracle,
Informix, PostGIS (PostgreSQL) en
ArcSDE binary. Van deze implementa
ties voldoen Informix en PostGIS aan
de OpenGIS-specificaties voor een poly
goon (SFS, level 2). Het OpenGIS Well
Known Text (WKT, 'bekende tekst') for
maat is gebruikt bij het invoegen van
de records in de verschillende syste
men. Hieronder een voorbeeld van een
'insert' SQL statement zoals is gebruikt
om een correct polygoon (testpolygoon
2) toe te voegen (met uitzondering van
ArcSDE, waar het laadproces anders
verloopt):
insert into test_polygon values ('2', ST_Po-
lyFromText('polygon(
(33300 19200, 19200 30000, 8300 15000,
200004200, 3330019200),
(25000 13300, 17500 13300, 17500 19200,
25000 19200, 25000 13300))', 128992));
Oracle heeft als enige een aparte validatiefunctie waarin
een tolerantiewaarde kan worden opgegeven (in het voor
beeld is de tolerantie waarde 4000):
select id, sdo_geom.validate_geometry_with_context(geom,4000)
as valid from test_polygon
where sdo_geom.validate_geometry_with_context(geom,4000)
'TRUE';
Tabel 1 geeft een overzicht van de reactie van de verschil
lende systemen. Deze tabel bevat ook het verwachte resul
taat volgens de ISO- en OpenGIS-definities en volgens onze
eigen definitie. De waarnemingen en interpretaties leiden
tot de volgende algemene conclusies. Oracle Spatial (ver
sion 9.2.0.3.0) heeft een tolerantieparameter, die kan wor
den gebruikt bij vele operaties. In deze testen is de toleran
tiewaarde steeds 4000. Experimenten met andere toleran
tiewaarden geven (soortgelijke) resultaten. Indien Informix
(Spatial DataBlade Release 8.11.UC1, Build 225) een poly
goon met verkeerde oriëntatie vindt, dan wordt deze intern
omgedraaid zonder waarschuwing. PostGIS 0.6.2 (on Post
greSQL 7.1.3) ondersteunt alleen de GeomFromText-functie
(en niet de PolyFromText functie) en de geometrie wordt
niet gevalideerd.
Zoals ook tijdens onze testen en benchmarking van ver
schillende geo-ICT-producten al was gebleken, is er nog
geen consistent gebruik van een polygoondefinitie. Dit is
zowel het geval voor de standaarden (specificaties) zelf als
voor de implementatie hiervan in producten. Zowel op ba
sis van de ISO19107-standaard alsook op basis van de Open
GIS (SFS for SQL)-implementatiespecificatie, is het soms erg
moeilijk of zelfs onmogelijk om te bepalen of een polygoon
geldig is of niet. Volgens onze evaluatie met de verzameling
testgevallen, zijn de resultaten van (on)geldige polygonen
niet altijd hetzelfde volgens de geharmoniseerde ISO- en
OpenGIS-standaarden. Bovendien, zowel ISO als OpenGIS-
definities zeggen niets over het belangrijke aspect van de
tolerantiewaarde. Dit is een belangrijke reden waarom wij
onze eigen definitie van een polygoon (met gaten) hebben
gegeven. Deze is vervolgens verfijnd tot het begrip geldige
schone polygonen, die geschikt zijn voor het uitwisselen
tussen verschillende systemen.
Niet alleen in theorie (ISO en OpenGIS), maar ook in de
praktijk (naast de genoemde Geo-DBMSsen is ook een
'middleware' product getest, LaserScan Radius Topology,
wat hier niet verder is beschreven) bleken er belangrijke
verschillen te bestaan bij de validatie van polygonen. Het
behoeft geen verdere uitleg dat dit vervelende problemen
zal geven bij het uitwisselen van gegevens, en in het ern
stigste geval zelfs verlies van gegevens. Wij roepen daarom
de standaardisatie-organisaties en de Geo-ICT-leveranciers
op dit probleem aan te pakken en onze polygoondefinitie te
overwegen.
In dit artikel werden alleen simpele polygonen op een plat
vlak besproken. Echter, er kunnen in de wereld van Geo-ICT-
producten (en -standaarden) toch nog een aantal complexe
re situaties zich voordoen:
GEO-INFO 2004-3
Systeemtesten
Conclusie
