76
Geo-Info I 2017-2
te vullen met vlakken (die tevens het juiste
detailniveau bevatten voor deze schaal).
Voor optie B is de vraag: voor een nieuwe
uitsnede en schaal wil ik de benodigde
topologische primitieven ontvangen om een
nieuwe kaart te kunnen maken, maar ik wil
niet opnieuw de primitieven ontvangen die
ik al eerder ontving voor laatste n uitsnede-
en-schaal-paren: (gebied,, schaal,), (gebied 2,
schaal2), enzovoorts. Antwoord: hier heb je
een set aan topologische primitieven, dit moet
voldoende zijn om de kaartuitsnede te vullen
met vlakken samen met de topologische pri
mitieven had voor (gebied,, schaal,), (gebied2,
schaal2), enzovoorts.
En bij optie C is de vraag die de client stelt:
voor een overgang tussen deze start uitsnede
en start schaal wil ik de juiste topologische
primitieven gesorteerd in goede volgorde
ontvangen om de kaartinhoud, die ik al had,
objectsgewijs te kunnen updaten en uit te
komen op eind uitsnede en eind schaal.
Antwoord: met deze stroom aan pakketjes van
topologische primitieven kun je de kaartin
houd in stapjes updaten, zodat je uiteindelijk
op de gewenste uitsnede en schaal uitkomt.
Om de vragen efficiënt te kunnen beantwoor
den wordt de vraag van de client door de
server omgezet in een database query. Binnen
de database zijn de topologische primitieven
geïndexeerd met een 3D R-tree (2D ruimte
met iD schaal) waardoor de database in staat
is snel een antwoord te geven.
De opties in meer detail
Optie A is relatief simpel en rechttoe rechtaan:
De inhoud van de kaart is precies afgestemd
op wat de gebruiker wil zien, overeenkom
stig hoe een WMS (Web Map Service) of
WFS (Web Feature Service) vraag-antwoord
verzoek werkt (voor respectievelijk een raster-
of vectorkaart). Een client is hierbij overigens
niet op de hoogte dat er een tGAP structuur
op de server aanwezig is. Na elk verzoek
wordt de hele opgebouwde topologische
structuur vervangen. Optie B lijkt erg op optie
A, maar met aanwezigheid van een cache
aan de clientzijde (tijdelijke opslagstruc
tuur). Aangezien een huidig verzoek van een
gebruiker waarschijnlijk gerelateerd zal zijn
aan een eerder verzoek (een gebruiker heeft
de kaart bijvoorbeeld slechts een klein stukje
verschoven/ingezoomd op de vorige situatie)
probeert deze optie de vario-schaal gegevens
die in het eerdere verzoek al zijn overge
dragen (deels) te hergebruiken. Hiervoor is
het nodig dat de client zich wel bewust is
dat voor elke topologische primitieve een
schaalbereik is gespecificeerd en de client dus
de juiste primitieven uit eerdere antwoorden
snel kan selecteren. Zowel optie A als optie B
vervangen het hele kaartbeeld, alle objecten
die in de kaart aanwezig zijn, in één keer na
een zoom actie (dus niet geleidelijk).
Optie C: nadat een gebruiker een grafische
zoom-stap heeft uitgevoerd, wordt een serie
van instructies aangevraagd om progressief
de inhoud van de kaart op object niveau
aan te passen: de inhoud zoom-stappen,
met nieuwe informatie, toe te voegen aan
de bestaande kaart. Doordat de hele tGAP
structuur bij deze oplossing ook bekend
gemaakt wordt aan de client (en dus welke
topologische primitieven gebruikt moeten
worden) kan een client zelf de primitieven
uit de kaart halen die voor een schaal niet
meer benodigd zijn en de primitieven uit het
antwoord toevoegen aan de huidige kaart.
Optie C werkt het kaartbeeld op objectniveau
bij en levert dus de meest geleidelijke van de
drie voorgestelde oplossingen.
Voor de verschillende opties zijn de structuren
die aan de clientkant nodig zijn enigszins
verschillend. Voor optie A is alleen een topolo
gische structuur nodig, op basis waarvan de
client de vlakken kan vormen. Voor optie B
is naast de topologische structuur ook een
structuur nodig (een cache) waarmee bijge
houden wordt welke vraag eerder gesteld
werd, en welk antwoord daarbij hoorde.
Voor optie C is de meest geavanceerde struc
tuur nodig, omdat topologische primitieven
incrementeel uit de structuur gehaald/
bijgeplaatst moeten kunnen worden, zodra ze
(niet) meer benodigd zijn.
Benchmark experiment
met landgebruiksdata
We hebben een deel van de Europese
landgebruik dataset (Corine 2006) omgezet
naar topologische primitieven en hier een
tGAP structuur voor gebouwd. Vervolgens
is getest met een interactiepad dat de
gebruiker heeft afgelegd (figuur 3). De acties
die voorkomen zijn: schuiven (pannen),
inzoomen en uitzoomen, waarbij soms grote
schaalstappen werden genomen en soms
kleine. Gebruikersacties resulteren in een set
van vragen, die afgevuurd kunnen worden
op de vario-schaal server. Dit vraag-antwoord
spel werd uitgevoerd door een automatisch
proces, dat steeds twintig keer is uitgevoerd
voor de verschillende opties.
Tijdens het experiment verzamelden we
gegevens over de hoeveelheid overgedragen
gegevens en de tijd die het bevragen van de
server nam. De metingen voor de verwer-
kingstijd van het vraag-antwoord verzoek
werden vervolgens geaggregeerd: gemid
delde, snelste en langzaamste verzoek. Bij de
verwerkingstijd werden twee tijdstippen
gemeten: de tijd die nodig is tot aan de start
van de ontvangst van het antwoord (time
to first byte) en de tijd die nodig is om het
antwoord in zijn geheel te ontvangen (time to
last byte, getoond in figuur 4(a)). Voor optie B
zijn 4 varianten getest: B0, B,, B2 en Bwaarbij
het nummer het aantal vorige verzoeken voor
kaartuitsneden aangeeft. Qua hoeveelheid
gegevens ligt gegevensgebruik voor de drie
opties in nagenoeg dezelfde orde grootte
(optie B0 is iets duurder, omdat deze optie
geen besparing kan realiseren door eerdere
verzoeken, maar er worden wel stukken van
de tGAP face boom overgestuurd, zoals nodig
bij opties B en C, maar niet bij optie A). Qua
verwerkingstijd functioneert optie C het best,
optie A is tweede en optie B (met varianten
0-3) laatste. Het experiment laat zien dat
elke vraag (ongeacht welke optie gebruikt
is) beantwoord kan worden binnen twee
seconden.
Optie A zet de basis, qua hoeveelheid
dataoverdracht als vergelijk voor de andere
opties. Nagenoeg dubbele overdracht van
gegevens vindt bij deze optie plaats als de
gebruiker de kaart slechts een klein beetje
schuift of in/uitzoomt.
Voor B wordt aangegeven hoeveel eerdere
kaartuitsneden door het proces werden ont
houden (tot drie eerdere uitsneden werden
onthouden). Voor optie B leidt het geven van
meerdere eerder opgevraagde uitsneden
tot meer benodigde verwerkingstijd van de
bevraging aan de serverkant. De database
bevraging wordt door elke toegevoegde uit
snede iets complexer, maar het aantal gese
lecteerde primitieven wordt kleiner. Het blijkt
dat bij slechts een uitsnede onthouden de
meeste winst wordt gehaald (vergelijk opties
B,- in figuur 4(a) en (b)) en dit is dus de beste
oplossing voor optie B; dubbele overdracht
wordt daarmee grotendeels voorkomen.
Optie C neemt de minste hoeveelheid tijd
om over te sturen (en heeft ook het snelste
moment van antwoord: time to first byte). Dit is
gunstig, omdat hierna begonnen kan worden
om de kaart incrementeel bij te werken. In
verhouding met optie B, ligt de hoeveelheid
datagebruik in dezelfde orde grootte (omdat
data van de vorige uitsnede die getoond werd
al aanwezig is op de client bij optie C ook niet
nogmaals opgestuurd wordt). We hebben
bij implementeren van optie C ook gemerkt
dat het noodzakelijk is dat de data in goede
