Digitale presentatie en vormgeving van een spatio-temporele interface voor een fotodatabank

Transcriptie

1 Digitale presentatie en vormgeving van een spatio-temporele interface voor een fotodatabank Mathias Ghys Promotoren: prof. dr. Guy De Tré, prof. dr. Pieter Uyttenhove Begeleiders: ir. Tom Matthé, Patrick Hochstenbach Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel Vakgroep Architectuur en stedenbouw Voorzitter: prof. dr. Bart Verschaffel Faculteit Ingenieurswetenschappen Academiejaar

2 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Datum Handtekening i

3 Dankwoord Mijn dank gaat uit naar alle mensen die mij dit academiejaar geholpen en gesteund hebben bij de realisatie van mijn afstudeerwerk. Eerst en vooral wil ik mijn promotors, Prof. dr. G. De Tré en Prof. dr. P. Uyttenhove en mijn begeleiders Tom Matthé en Patrick Hochstenbach bedanken. Prof. dr. G. De Tré en Prof. dr. P. Uyttenhove hebben, om mij op het goede spoor te zetten bij mijn onderzoek, telkens tijd vrijgemaakt in hun drukke agenda. Tom en Patrick gaven me steeds de informatie en vooral de vrijheid die ik nodig had om dit eindwerk tot een goed einde te brengen. Zowel Tom als Patrick beantwoordden onmiddellijk mijn vele vragen via met concrete antwoorden die mij direct verder leidden. Verder wil ik mijn familie bedanken voor de steun en nodige afwisseling, waar ook mijn medestudenten en vrienden voor gezorgd hebben. ii

4 Digital presentation and design of a spatiotemporal interface for a photographic database Mathias Ghys Supervisor(s): Prof. dr. G. De Tré and Prof. dr. P. Uyttenhove Abstract Digital photographic material is an increasingly important component in multimedia database systems. Often spatiotemporal data is linked with the data. This spatiotemporal metadata appears to be an important tool for searching the database and visualising query results. A prototype is built to demonstrate the opportunities of working with spatiotemporal components of data. Google Maps is used to achieve this goal. Keywords Google Maps, spatiotemporal metadata, fuzzyness, web application, three-tier architecture I. INTRODUCTION THE objective of this dissertation is to create a prototype to provide better access to digital photographic archives. To achieve this goal a suitable interface has to be created (web interface) that provides the opportunity of intuitive navigation. A few tools and databases that could help to achieve this goal are studied. A main problem appears to be the matching between the data in the photographic archive and a geographic location on the map. Another goal was to use mouse operations for the searches and visualise the results on a map. MARC-XML DUMP FILE Producer Consumer Database Database viewer Server II. STARTING POINT SQL OVER JDBC ID OpenURL image "on the fly" -Thumb -Small -Medium -Large DHTML CSS SERVLETS AJAX JAVASCRIPT... Webapplication Fig. 1. Overview with the different components of the webapplication The application is a simulation of an existing photographic database that is property of the architectural group of Ghent University. The photographs are all stored in an erez Digital Asset Management System [1], with a software layer on M. Ghys is student civil engineer, computer science, software-engineering, Ghent University (UGent), Gent, Belgium. Mathias.Ghys@UGent.be. top. Digital Asset Management consists of tasks and decisions surrounding ingesting, annotating, cataloguing, storage and retrieval of digital assets, such as digital photographs, animations, videos and music. Digital asset management systems are computer software and/or hardware systems that aid in the process of digital asset management. Photographic metadata is stored in MARC21 format [2]. The MARC standards consist of the MARC formats, which are standards for the representation and communication of bibliographic and related information in machine-readable form, and related documentation. OpenURL [3] is used for the final presentation of the images. The OpenURL standard is designed to support mediated linking from information resources (sources) to library services (targets). To design the application, it s not necessary to interact directly with the photograpic database. We use a dump of MAR- CXML records instead. In the database, a reference to the image in the erez DAM is stored. Like this, a beautiful portable application is formed: De MARCXML standard is used as input, the OpenURL standard is used as output, and the application is the magic box in the middle. We also investigate the benifits of supporting inprecise information and fuzzyness. A general overview of the different components of our application is shown in Fig. 1. III. DATABASE In accordance with this dissertation, a double DVD was bought at AGIV 1 [4] with on them the so called CRAB address positions [5]. These CRAB address positions database consists of many tables that represent specific parts of all addresses in Flanders and Brussels. A selection is made and following tables of the database are used: gemn representing the name of a place. gem representing the places and having a unique id. streetnm representing the streetname. huisnr representing the house number. tobjhnr representing the link between house number and geographical information terrobj representing every physical location with unique coordinates However, this approach seems to have a few disadvantages. Obviously, a first disadvantage is that the database is limited to the geographical information of locations in Flanders and Brussels. In the dump XML file, only locations in Belgium occur, but already for the French part of the country, no coordinates can be found in the database. If the application should want to 1 Agentschap voor Geografische informatie Vlaanderen

5 support global data, the database no longer suffices and other international databases have to be bought. A second disadvantage, in particular for this dissertation, is that the coordinates in the terrobj table, are not conform the common used WGS84-date. WGS84 (World Geodetic System 1984) is the datum used for GPS positioning. It consists of threedimensional Cartesian coordinate system and an associated ellipsoid, so that WGS84 positions can be described as either XYZ Cartesian coordinates or latitude, longitude and ellipsoid height coordinates. The origin of the datum is the Geocentre (the centre of mass of the Earth) and it is designed for positioning anywhere on Earth. Latitude and longitude coordinates in the terrobj table are based on the Belgian Lambert 72 date. To transform the coordinates, a common transformation algorithm is used. A third disadvantage deals with the performance. If the database would be used in the state it was bought, without modifications the queries seem to be very slow. Indexes were added to the tables, and preprocessing is done, but still the database is very slow. The reason is that each query involving coordinates implies searching records. With indexing this can occur in 21 steps but this is still unacceptably slow. A solution was found in adding the Geonames [6] database, that contains different names for the same location, based on the language of the location and a unique identifier and coordinates. This table is used for the location view. For the more detailed view, the photographic database table is extended with two fields containing the longitude and latitude coordinates, which increases the performance of searching significantly. IV. USER INTERFACE For the application, the software design pattern Three-tier architecture is used. Three-tier is a client-server architecture in which the user interface, functional process logic ( business rules ), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. Google Maps [7] is used at the client side with a layer of JavaScript on top. The search pages are built in DHTML. Dynamic HTML, or DHTML, is a collection of technologies used together to create interactive and animated web sites by using a combination of a static markup language (such as HTML), a client-side scripting language (such as JavaScript), a presentation definition language (such as CSS), and the Document Object Model. Communication with the underlaying business layer occurs with AJAX. With AJAX (asynchronous JavaScript and XML), web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. Data is retrieved using the XMLHttpRequest object. An interesting field in database research is the use of Fuzzy Datasets. The application interacts with users quering the database. Lots of users will not have an exact idea of what they re looking for. Next to showing exact results, the UI also shows results that could match the query, and these are labeled in a different color to make distinction with the exact results. A distinction is made between preferences inside selection conditions and preferences between selection conditions. Preferences inside selection conditions will lead to flexible search criteria and permit to express that some values are preferred over other ones. Preferences between selection conditions are used to associate different grades of importance to the selection conditions. VI. BUSINESS LAYER The business layer starts with the Java servlets receiving their information from the client with AJAX. Once received, the information is passed to a DAO. A Data Access Object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. The advantage of using data access objects is the relatively simple and rigorous separation between two important parts of our application which can and should know almost nothing of each other, and which can be expected to evolve frequently and independently. Changing business logic can rely on the same DAO interface, while changes to persistence logic do not affect DAO clients as long as the interface remains correctly implemented. The DAO connects to the database using JDBC en sends the data back to the client, using the DAO. VII. CONCLUSIONS The research will show that the development of an application that visualizes photographic material correctly and in an acceptable time involves a lot of adaptations to existing databases and Google Maps. A knowledgable approach however allows for both powerful results and user friendly interfaces, catering to a broad public. ACKNOWLEDGMENTS The author would like to acknowledge his supervisors Prof. dr. G. De Tré and Prof. dr. P. Uyttenhove. Also the great support from ir. Tom Matthé en Patrick Hochstenbach is much appreciated. REFERENCES [1] erez Digital Asset Management System, [2] MARC Standards, [3] National Information Standards Organization The OpenURL Framework for Context-Sensitive Services, OCLC(Online Computer Library Center, ANSI/NISO Z [4] AGIV homepage, [5] CRAB address project of GIS, [6] GeoNames geographical database, [7] Google maps homepage, [8] Syllabus tot the course Vage Databanken, Prof. dr. G. De Tré, Universiteit Gent. V. FUZZY DATA

6 Inhoudsopgave 1 Samenvatting 1 2 Inleiding Uitgangspunt Ontwerpbeslissingen Databank CRAB Adresposities Inleiding Entiteiten Analyse Cities databank Library databank Ontwikkelingen Gebruikersinterface Inleiding Google maps Gebruikersinterface Opbouw HTML pagina Voorbeeld Vage data Preferenties binnen bevragingscondities Preferenties tussen bevragingscondities iii

7 5 Business logica Inleiding Ontwerp Servlets Data Access Object Conclusie 43 A Coördinatentransformatie 45 B Fuzzyness 50 B.1 Logische operatoren B.2 Implicatoren C Bijlage: CD-Rom 55 Bibliografie 57 iv

8 Hoofdstuk 1 Samenvatting Digitaal fotomateriaal vormt meer en meer een belangrijke component bij multimediadatabanken. Vaak zijn aan het materiaal spatiotemporele metadata gekoppeld, die weergeven waar en wanneer foto s zijn genomen. Deze spatiotemporele metadata vormt een handig instrument bij het opzoeken en visualiseren van data. Dit afstudeerwerk beoogt de ontwikkeling van een prototype van een instrument voor verbeterde toegankelijkheid tot digitale fotoarchieven. Hiertoe dient een gepaste interface (bvb. webinterface) te worden ontworpen die gemakkelijk en intuïtief navigeren toelaat. Er worden verschillende technieken en databanken onderzocht die toelaten spatiale data uit de multimediadatabank zo efficiënt mogelijk te linken aan bestaande geografische locaties. Ook wordt getracht zowel de zoekacties op de databank visueel te laten gebeuren en de gevonden data visueel voor te stellen. De bestaande Google Maps applicatie in combinatie met JavaScript en DHTML bleek een schitterende tool om deze doelstellingen te verwezelijken. Spatiotemporele metadata deed ook nadenken hoe vage data het best kan benaderd worden. Vaak weet een gebruiker bij een zoekopdracht niet de exacte periode of de exacte locatie van hetgeen hij zoekt. Er wordt onderzocht hoe hieraan best tegemoet kan gekomen worden in het prototype. Uit het onderzoek zal blijken dat met vele factoren rekening moet gehouden worden bij het ontwerp van een applicatie om digitaal fotomateriaal correct en binnen een aanvaardbare tijd te visualiseren. Echter met een goede aanpak kunnen schitterende resultaten behaald worden en kan meegeholpen worden aan de tendens om via gebruiksvriendelijke interfaces, databanken toegankelijk te maken voor een zo breed mogelijk publiek. 1

9 Hoofdstuk 2 Inleiding 2.1 Uitgangspunt Voor dit afstudeerwerk wordt uitgegaan van de ALEPH (2) fotodatabank van de vakgroep architectuur van de Universiteit Gent. ALEPH is de online catalogus van de Gentse universiteit en beschrijft het bezit van de bibliotheken van de UGent. Deze omvat boeken, visueel materiaal, manuscripten, serials,... Voor de beelddatabank wordt gebruik gemaakt van een Lucene full-text indexer (10). Lucene is een gratis open source, tekst gebaseerde information retrieval API, geschreven in Java. Het wordt ondersteund door de Apache Software Foundation en is vrijgegeven onder de Apache Software Licentie. Het is geschikt voor alle toepassingen die volledige tekstindexering en zoekfunctionaliteiten vereisen. Hierdoor wordt het veel gebruikt in internet zoekmachines en het lokale single-site zoeken. Een veel voorkomend misverstand is dat Lucene zelf een zoekmachine is met ingebouwde Spider en HTML parsing functies. Echter deze functies moeten apart worden toegevoegd aan de applicatie. Naast HTML, PDFs en Microsoft Word kunnen vele andere soorten documenten worden geïndexeerd. De databank die gebruikt wordt is een Oracle databank. Hierin wordt de ALEPH metadata opgeslagen volgens het MARC (MAchine-Readable Cataloging) formaat (11). Dit is een uitgebreide standaard die het mogelijk maakt bibliografische gegevens in een vrij platte eenvoudige structuur op te slaan in de databank. Een conversiescript haalt de metadata uit de ALEPH catalogus en haalt de meest essentiële velden eruit. De foto s zijn opgeslagen in een erez Digital Asset Management System (DAM) 2

10 (6), met een softwarelaag bovenop. Digital Asset Management bestaat uit taken en beslissingen die draaien rond het opnemen, catalogeren, opslaan en terugvinden van digitale assets, zoals digitale afbeeldingen, animaties, video s en muziek. Digital asset management systems zijn software- en/of hardwaresystemen die helpen bij het proces van digital asset management. De term Digital Asset Management (DAM) wordt ook vaak gebruikt als verwijzing naar het protocol voor het downloaden, hernoemen, backuppen, groeperen, archiveren, optimaliseren, onderhouden en exporteren van bestanden. De beelden hebben een grootte van enkele MB tot 2,6 GB. erez zorgt ervoor dat snelle toegang mogelijk wordt tot delen van de beelden (of thumbnails) m.b.v. on-the-fly conversies. Voor de uiteindelijke presentatie van de beelden wordt gebruik gemaakt van de OpenURL standaard (21). OpenURL verpakt bibliografische informatie op een manier die internetdiensten in staat stelt deze te vertalen naar een voor de gebruiker zinvol resultaat. OpenURL bestaat uit een basis URL die verwijst naar de locatie van de link-server die de dienst aanbiedt en een Query string die de conceptuele data bevat en typisch voorkomt in de vorm van key-value paren. Een voorbeeld van een OpenURL is de volgende URL: rft_id=info%3augent-repo%2ftopo%2f226-b-00001& svc_id=thumbnail&url_ver=z Hier wordt de erez Digital Asset Management system als bron gebruikt om de OpenURL te genereren. Het doel is een webinterface die de gebruiker helpt aan de opgevraagde informatie te komen. De ALEPH bibliotheek wordt getoond in Figuur 2.1. Aangezien de Lucene full-text indexer te complex is en niet relevant voor het onderzoek wordt voor dit afstudeerwerk vertrokken van een dump van MARCXML records die de beelden beschrijven. Er wordt gebruik gemaakt van een demo-tool die MARCXML records oplaadt naar een postgresql databank. MARCXML is een XML (24) schema gebaseerd op het MARC21 formaat, dat bibliografische gegevens leesbaar maakt voor computersystemen. Verderop, wanneer dieper ingegaan wordt op de fotodatabank, wordt de opbouw van een dergelijk MARCXML bestand van dichterbij bekeken. Enkel de data die nodig zijn voor de applicatie (titel, auteur, datum, plaatsnamen, beeldbestand-ref) worden gemapt naar de databank. Elk MARC record verwijst naar een beeldbestand. In de databank is een verwijzing opgeslagen 3

11 Aleph bibliotheek Oracle databank erez Digital Asset Management system MARC-XML OpenURL Producer Consumer ID afbeelding "on the fly" -Thumb -Small -Medium -Large ID Lucene full-text indexer Figuur 2.1: Schematische voorstelling van de werking van de ALEPH fotodatabank naar het beeldbestand dat op de server van de universiteit staat. Op deze manier wordt een connectie naar een Digital Asset Management systeem gesimuleerd zonder zelf een erez te moeten draaien. Nog beter zelfs: elke DAM die het OpenURL protocol ondersteunt kan dan in principe de fotodatabank gebruiken, hetgeen een mooie portable applicatie is. De MARCXML standaard wordt als input gegeven, de OpenURL levert de beelden en de applicatie fungeert als een magic box in het midden. Een schematisch overzicht van onze applicatie wordt getoond in Figuur 2.2. Het doel van dit afstudeerwerk is eigenlijk de communicatie tussen de fotodatabank en de eindgebruiker grafisch te laten gebeuren. Hierbij kan de gebruiker door het trekken van een rechthoek op een kaart en het verschuiven van sliders zoekopdrachten op de databank formuleren. De gevonden data worden dan eveneens visueel weergegeven. Hoe zo een bibliotheekitem wordt afgebeeld is te zien in Figuur 2.3. De gebruiker krijgt een marker te zien op de kaart en bij het aanklikken opent er een info venster met de gegevens voor dat bepaalde item, inclusief een kleine thumbnail. De foto kan dan vergroot worden door op de thumbnail te klikken. 4

12 Hiernaast wordt nog eens onderzocht hoe kan gewerkt worden met vage data. Dit heeft vooral belang bij spatio-temporele databankgegevens; indien een gebruiker afbeeldingen zoekt van Brugse abdijen in de 20e eeuw, kan hij ook geïnteresseerd zijn in een Brugse abdij uit 1895 of een abdij in de omgeving van Brugge. Hiervoor wordt kort bekeken hoe we informatie, die niet aan strikte zoekcriteria voldoet, kunnen visualiseren. Op een aparte pagina wordt ook de mogelijkheid gegeven zoekopdrachten te combineren, al dan niet vaag. Resultaten worden verschillend afgebeeld naargelang de mate waaraan ze aan de query voldoen. Zo kan de gebruiker, indien hij met onnauwkeurige informatie werkt, een onderscheid maken op basis van relevantie. In Figuur 2.3 is te zien hoe de marker een rode kleur heeft. Dit wijst erop dat het bibliotheekitem in grote mate voldoet aan de query. 2.2 Ontwerpbeslissingen Een eerste beslissing die moet gemaakt worden is de keuze van de databank. Met de XMLProducer-tool wordt relevante informatie uit de MARCXML records ingeladen in een databank. Eigenlijk is de keuze welke databank gebruikt wordt vrij, maar de keuze valt op postgresql, omdat het een relationele database-server is die mogelijkheden biedt voor het toevoegen van verschillende soorten indexen op de velden. Bovendien biedt postgresql een grote portabiliteit tussen verschillende besturingssystemen en is het, in tegenstelling tot bv. oracle, gratis ter beschikking. Aan de server-zijde wordt gebruik gemaakt van een Apache Tomcat server v.6.0 als implicatie van de Java servlet technologie. Navicat (13) fungeert als front end voor de PostgreSQL databank. De keuze viel op Navicat omdat het compatibel is met Mac OS X, wat het besturingssysteem is. Aan de cliënt-zijde wordt gebruik gemaakt van Java-script, DHTML, CSS en AJAX-technologie. Voor het visualiseren van de gegevens wordt gebruik gemaakt van de Google Maps (9) applicatie. De Google maps API in combinatie met Java Script biedt hiertoe enorme mogelijkheden. 5

13 MARC-XML DUMP FILE OpenURL Producer ID afbeelding "on the fly" Consumer Server -Thumb -Small -Medium -Large SQL OVER JDBC Webapplicatie Databank Databank viewer DHTML CSS SERVLETS AJAX JAVASCRIPT... Figuur 2.2: Schematische voorstelling van de werking van de webapplicatie Figuur 2.3: Screenshot van het pop-up window dat verschijnt bij het aanklikken van een marker 6

14 Hoofdstuk 3 Databank 3.1 CRAB Adresposities Inleiding In het kader van dit afstudeerwerk werd een dubbel DVD aangekocht bij het AGIV 1 (1) met daarop de zogenaamde CRAB adresposities (5). De adresposities zijn een uittreksel uit het Centraal Referentie Adressen bestand (CRAB), een referentiedatabank van het AGIV met de geografische positie van de adressen in Vlaanderen. Het product CRAB adresposities bevat een lijst van 2,25 miljoen huisnummers in Vlaanderen en hun positie op kaart. De gegevens zijn gestructureerd volgens het CRAB-uitwisselingsformaat. Ook de straatnamen in België zitten in het product, met voor Vlaanderen en Brussel een koppeling met de wegen. De formaten waarin de alfanumerieke CRAB-gegevens worden aangeboden worden opgesomt in Tabel 3.1. Het dgn-, dwg-, gml- en shape-formaat zijn geografische formaten. Enkel de bestanden die xy-coördinaten bevatten worden in deze formaten aangeboden. De informatie is geografisch niet versneden, wat wil zeggen dat de data niet zijn opgedeeld over verschillende bestanden, op basis van de geografische ligging. Met de informatie op de DVD is het mogelijk de bibliotheekdatabank te verbinden aan kadastrale percelen en gegevens, gekoppeld aan straten, in kaart te brengen. De adresposities zijn een combinatie van gegevens uit de kadastrale legger, het VK- 1 Agentschap voor Geografische Informatie Vlaanderen 7

15 formaat beschrijving dbf dbase IV dgn Intergraph Microstation dwg AutoCAD gml Geography Markup Language mdb Microsoft Office Access 2003 shape ESRI-shapefile Tabel 3.1: overzicht van de ondersteunde formaten in de CRAB adresposities databank BO 2, het GRB 3, CADMAP (project dat zich bezig houdt met de digitalisering van het kadastraal percelenplan), het Rijksregister en MultiNet. Het AGIV voerde tal van bewerkingen uit om de kwaliteit van de gegevens te garanderen (het koppelen van kadastrale straten aan werkelijke straten, het interpoleren van huisnummerbereiken en het identificeren van dubbele straatnamen) Entiteiten Figuur 3.1 toont het conceptueel model dat uitgetekend is in UML-notatie en een overzicht geeft van de verschillende entiteiten en hun attributen en onderlinge relaties. Voor een aantal relaties werd een aparte entiteit voorzien, hoewel het meerdereop meerdere relaties zijn: Postkanton-huisnummer Straatnaam-substraat Gemeente-subkanton Gemeente-kadgemeente Reden daarvoor is de bijhouding van de eventuele historiek. Een huisnummer bv. kan in de loop der tijd met meer dan één postkanton geassocieerd geweest zijn. In Tabel 3.2 wordt de overeenkomst getoond tussen de entiteiten en hun attributen enerzijds en de velden uit de verschillende tabellen anderzijds. Figuur 3.2 toont de samenhang tussen de verschillende entiteiten en hun attributen in een logisch datamodel. Onmiddellijk valt op dat er eigenlijk meer entiteiten zijn dan nodig voor onze applicatie. Uit De XML-dump die ter beschikking gesteld werd, wordt per bibliotheekobject respectievelijk enkel de titel van het werk, de auteur, begin- en einddatum, de locatie en de URL naar de afbeelding gehaald. 2 Verrijkte kruispuntbank voor ondernemingen 3 Grootschalig Referentie Bestand 8

16 Het enige gegeven waarvan kan vertrokken worden om een opzoeking te doen in de adresposities databank is dus de locatie. Om de gegevens uit de databank in kaart te brengen, is het uiteraard van primordiaal belang dat er adressen staan bij de gegevens in de databank. In dit geval kunnen ze als volgt weergegeven worden op een kaart: Stap 1: Koppelen van de adressen aan de adressen op de DVD. Stap 2: Deze op hun beurt aan de percelen koppelen. Stap 3: De gekoppelde percelen in kaart brengen. Stappen 1 en 2 zijn uit te voeren in de databank en stap 3 wordt uitgevoerd in een GIS 4. Idealiter zouden de adressen in de databank CRAB-compatibel moeten zijn. In dat geval zou kunnen vertrokken worden van een unieke straatnaamsleutel en een huisnummer die in de databank zijn opgeslaan. Deze kunnen dan gekoppeld worden aan de tabel huisnr, waarvan de unieke straatnaamsleutel en het huisnummer aan een unieke huisnummersleutel kunnen gelinkt worden in de tabel huisnr. Via de tabel tobjhnr kan hiermee een koppeling tot stand gebracht worden met een uniek terreinobject terrobj en worden de unieke coördinaten van het perceel verkregen. Deze coördinaten kunnen dan met een GIS in kaart gebracht worden. Zo eenvoudig is het echter niet, want de adressen zijn niet CRAB-compatibel. Hoe de adressen in de databank worden omgezet naar een koppel unieke lengte- en breedtecoördinaten is weergegeven in Figuur 3.3. Dit is een sterk vereenvoudigd logisch datamodel waarin de entiteiten die niet nodig zijn worden genegeerd. In dit afstudeerwerk wordt er voor de eenvoud van uitgegaan dat de databank beschikt over een straatnaam, huisnummer en een plaatsnaam voor elk record. Het is immers niet de taak van het afstudeerwerk om die data in te vullen of te genereren, maar wel om, vertrekkende van die data, ze te visualiseren Analyse Een eerste belangrijk nadeel van de CRAB-adresposities databank is dat ze bijna uitsluitend voor Vlaanderen en Brussel toepasbaar is. Indien in de webapplicatie ook data uit andere landen, of zelfs Wallonië zou moeten gevisualiseerd worden op kaart, zouden ook in andere landen databases moeten aangekocht worden met dezelfde functionaliteit. Een voordeel is dan weer dat de data zeer up-to-date gehouden 4 Geografisch informatiesysteem 9

17 Entiteit.attribuut huisnummer.sleutelhuisnummer huisnummer.identificatorstraatnaam huisnummer.huisnummer huisnummer.begindatum huisnummer.einddatum postkantoncode.sleutelpostkantoncode postkantoncode.sleutelhuisnummer postkantoncode.postkantoncode postkantoncode.begindatum postkantoncode.einddatum straatkant.sleutelstraatkant straatkant.sleutelwegobject straatkant.identificatorstraatnaam straatkant.kant straatkant.beginpositie straatkant.eindpositie straatkant.pariteit straatkant.eerstehuisnummer straatkant.laatstehuisnummer straatkant.begindatum straatkant.einddatum straatnaam.identificatorstraatnaam straatnaam.straatnaam straatnaam.taalcodestraatnaam straatnaam.straatnaamtweedetaal straatnaam.taalcodestraatnaamtweedetaal straatnaam.nisgemeentecode straatnaam.begindatum straatnaam.einddatum subadres.sleutelsubadres subadres.sleutelhuisnummer subadres.subadres subadres.aardsubadres subadres.begindatum subadres.einddatum substraat.sleutelsubstraat substraat.straatcode substraat.subkantoncode substraat.begindatum substraat.einddatum substraat straatnaam.sleutelsubstraatstraatnaam substraat straatnaam.identificatorstraatnaam substraat straatnaam.sleutelsubstraat substraat straatnaam.begindatum substraat straatnaam.einddatum terreinobject.sleutelterreinobject terreinobject.identificatorterreinobject terreinobject.aardterreinobject terreinobject.positiexterreinobject terreinobject.positieyterreinobject terreinobject.begindatum terreinobject.einddatum terreinobject huisnummer.sleutelterreinobjecthuisnummer terreinobject huisnummer.sleutelterreinobject terreinobject huisnummer.sleutelhuisnummer terreinobject huisnummer.begindatum terreinobject huisnummer.einddatum wegobject.sleutelwegobject wegobject.identificatorwegobject wegobject.aardwegobject wegobject.begindatum wegobject.einddatum Tabel.veld huisnr.id huisnr.straatnmid huisnr.huisnr huisnr.begindatum huisnr.einddatum pkancode.id pkancode.huisnrid pkancode.pkancode pkancode.begindatum pkancode.einddatum strkant.id strkant.wegobjid strkant.straatnmid strkant.kant strkant.beginpos strkant.eindpos strkant.pariteit strkant.eerstehnr strkant.laatstehnr strkant.begindatum strkant.einddatum straatnm.id straatnm.straatnm straatnm.taalcode straatnm.straatnm2 straatnm.taalcode2 straatnm.nisgemcode straatnm.begindatum straatnm.einddatum subadr.id subadr.huisnrid subadr.subadr subadr.aard subadr.begindatum subadr.einddatum substr.id substr.straatcode substr.subkancode substr.begindatum substr.einddatum sstrstrn.id sstrstrn.straatnmid sstrstrn.substrid sstrstrn.begindatum sstrstrn.einddatum terrobj.id terrobj.objid terrobj.aard terrobj.x terrobj.y terrobj.begindatum terrobj.einddatum tobjhnr.id tobjhnr.terrobjid tobjhnr.huisnrid tobjhnr.begindatum tobjhnr.einddatum wegobj.id wegobj.objid wegobj.aard wegobj.begindatum wegobj.einddatum Tabel 3.2: aanbevolen tabel- en veldnamen in de adresposities databank 10

18 Agentschap voor Geografische Informatie Vlaanderen terreinobject +identificatorterreinobject[1] +aardterreinobject[1] +positieterreinobject[0..1] +begindatum[1] +einddatum[0..1] wegobject +identificatorwegobject[1] +aardwegobject[1] +begindatum[1] +einddatum[0..1] kadgemeente +kadgemeentecode[1] +begindatum[1] +einddatum[0..1] 1 1..* kadgemeentenaam +kadgemeentenaam[1] +taalcodekadgemeentenaam[1] +begindatum[1] +einddatum[0..1] * 0..* terreinobject-huisnummer +begindatum[1] +einddatum[0..1] straatkant +kant[1] +beginpositie[1] +eindpositie[1] +pariteit[0..1] +eerstehuisnummer[0..1] +laatstehuisnummer[0..1] +begindatum[1] +einddatum[0..1] 0..* kadgemeente-gemeente +begindatum[1] +einddatum[0..1] 0..* 0..* 0..* subadres +subadres[1] +aardsubadres[1] +begindatum[1] +einddatum[0..1] 0..* 1 huisnummer * * +huisnummer[1] +begindatum[1] +einddatum[0..1] 0..* 1 straatnaam +identificatorstraatnaam[1] +straatnaam[1] +straatnaamtweedetaal[0..1] +begindatum[1] +einddatum[0..1] 0..* 1 gemeente +nisgemeentecode[1] +taalcode[1] +taalcodetweedetaal[0..1] +begindatum[1] +einddatum[0..1] 1 1..* gemeentenaam +gemeentenaam[1] +taalcodegemeentenaam[1] +begindatum[1] +einddatum[0..1] * 0..* 0..* huisnummer-postkanton +begindatum[1] +einddatum[0..1] substraat-straatnaam +begindatum[1] +einddatum[0..1] 0..* 1 substraatnaam +substraatnaam[1] +taalcodesubstraatnaam[1] +begindatum[1] +einddatum[0..1] 1..* 1 substraat +straatcode[1] +begindatum[1] +einddatum[0..1] 0..* 1 1..* postkantonnaam +postkantonnaam[1] +taalcodepostkantonnaam[1] +begindatum[1] +einddatum[0..1] 1..* 1 1 postkanton +postkantoncode[1] +begindatum[1] +einddatum[0..1] 1 1..* subkanton +subkantonnummer[1] +begindatum[1] +einddatum[0..1] 1 1..* subkanton-gemeente +begindatum[1] +einddatum[0..1] Figuur 1: Conceptueel datamodel Figuur 3.1: conceptueel datamodel uitgetekend in UML-notatie wordt en de informatie zeer betrouwbaar is, aangezien ze samengesteld wordt met gegevens uit het kadaster. Een tweede groot nadeel, in het bijzonder voor het afstudeerwerk, is dat de coördinaten uit de tabel terrobj, niet onmiddellijk kunnen gebruikt worden door een applicatie 11 Objectcataloog :32 15/16

19 Agentschap voor Geografische Informatie Vlaanderen PK U1 U1 U1 terreinobject sleutelterreinobject identificatorterreinobject aardterreinobject positiexterreinobject positieyterreinobject begindatum einddataum PK U1 U1 U1 wegobject sleutelwegobject identificatorwegobject aardwegobject begindatum einddatum PK U1 U1 kadgemeente sleutelkadgemeente kadgemeentecode begindatum einddatum kadgemeentenaam PK sleutelkadgemeentenaam FK1,U1 sleutelkadgemeente kadgemeentenaam U1 taalcodekadgemeentenaam U1 begindatum einddatum straatkant terreinobject_huisnummer PK seutelterreinobjecthuisnummer FK1,U1 sleutelterreinobject FK2,U1 sleutelhuisnummer U1 begindatum einddatum PK sleutelstraatkant FK1,U1 sleutelwegobject FK2,U1 identificatorstraatnaam U1 kant U1 beginpositie eindpositie pariteit eerstehuisnummer laatstehuisnummer U1 begindatum einddatum kadgemeente_gemeente PK sleutelkadgemeentegemeente FK1,U1 sleutelkadgemeente FK2 sleutelgemeente U1 begindatum einddatum PK subadres sleutelsubadres PK huisnummer sleutelhuisnummer PK straatnaam identificatorstraatnaam PK gemeente sleutelgemeente PK gemeentenaam sleutelgemeentenaam FK1,U1 sleutelhuisnummer U1 subadres U1 aardsubadres U1 begindatum einddatum FK1,U1 identificatorstraatnaam U1 huisnummer U1 begindatum einddatum FK1,U1 sleutelgemeente U1 straatnaam straatnaamtweedetaal U1 begindatum einddatum U1 U1 nisgemeentecode taalcode taalcodetweedetaal begindatum einddatum FK1,U1 sleutelgemeente gemeentenaam U1 taalcodegemeentenaam U1 begindatum einddatum huisnummerpostkanton substraat_straatnaam PK sleutelpostkantoncode PK sleutelsubstraatstraatnaam FK1,U1 sleutelhuisnummer FK2 sleutelpostkanton U1 begindatum einddatum FK2,U1 sleutelsubstraat FK1 sleutelstraatnaam U1 begindatum einddatum PK substraatnaam sleutelsubstraatnaam PK substraat sleutelsubstraat FK1,U1 sleutelsubstraat substraatnaam U1 taalcodesubstraatnaam U1 begindatum einddatum U1 straatcode FK2,U1 sleutelsubkanton U1 begindatum einddatum postkantonnaam PK sleutelpostkantonnaam FK1,U1 sleutelpostkanton postkantonnaam U1 taalcodepostkantonnaam U1 begindatum einddatum postkanton PK sleutelpostkanton U1 postkantoncode U1 begindatum einddatum subkanton PK sleutelsubkanton FK1,U1 sleutelpostkanton U1 subkantonnummer U1 begindatum einddatum subkanton_gemeente PK sleutelsubkantongemeente FK1,U1 sleutelsubkanton FK2 sleutelgemeente U1 begindatum einddatum Figuur Figuur 3.2: Logisch logisch datamodel als Google Maps. Google Maps gebruikt als geografische coördinaten (lengtegraad, breedtegraad) de WGS84 datum, dat gedefinieerd wordt door GPS 5. Geografische coördinaten in WGS84 zijn gebaseerd op de WGS84-ellipsoïde, een wiskundig model van de aarde. Een ellipsoïde wordt gedefinieerd met een equatoriale straal en een poolstraal. Meer informatie over de WGS84 datum is te vinden in (20). Echter de coördinaten in het x- en y-veld van de tabel terrobj zijn opgeslagen als cartografische coördinaten (x,y) in het Lambert72 stelsel. 5 Global Positioning System 12 Objectcataloog :32 16/16

20 data2 gemnm gem PK id PK id I2 I2 I2 title author date1 date2 location postcode straatnaam nummer landcode latitude longitude url FK1,U1 gemid U1 gemnm taalcode begindatum einddatum begintijd beginbew beginorg U1 nisgemcode taalcode taalcode2 begindatum einddatum begintijd beginbew beginorg terrobj tobjhuisnr huisnr straatnm PK id PK id PK id U1 U1 objid aard x y begindatum einddatum begintijd beginorg beginbew kadgemcode FK2,U1 terrobjid FK1,U1 huisnrid begindatum einddatum begintijd beginorg beginbew U1 huisnr FK1,U1 straatnmid begindatum einddatum begintijd beginorg beginbew huisnrid0 FK1,U1 nisgemcode U1 straatnm taalcode straatnm2 taalcode2 begindatum einddatum begintijd beginorg beginbew straatnm0 Figuur 3.3: vereenvoudigd logisch datamodel Tot op heden blijft de Belgian Datum 1972 (Lambert 72) voor alle praktische toepassingen zowel op nationaal als op internationaal vlak het enige officiële referentiesysteem. Het bestaat uit ongeveer gematerialiseerde punten (palen en verheven punten) bepaald door tienduizenden waarnemingen. Dit referentiesysteem heeft echter de laatste 30 jaar zijn deugdelijkheid bewezen. Dat het, dankzij de moderne GPS-technieken, vatbaar is voor verbeteringen is evident. De toekomst ligt ongetwijfeld in een netwerk van permanente GPS-stations waarvan de coördinaten bepaald zijn in het officiële referentiesysteem (nationaal of Europees?). Een overzicht van de verschillende referentiesystemen is terug te vinden in Figuur 3.4. Voor alle praktische lokale toepassingen is ETRF89 identiek aan WGS84. Op de site van het NGI (12) worden Dynamic Link Libraries (DLL voor windows,.so voor Linux) ter beschikking gesteld die diverse transformaties uitvoeren tussen ETRS89, Lambert en UTM coördinaten. In Appendix A wordt de coördinatentransformatie van dichterbij bekijken. Een derde bedenking die kan gemaakt worden is de performantie van een databankrequest; in Tabel 3.3 worden de gebruikte tabellen en hun aantal records getoond. Er zijn 2 aanpassingen gedaan om de performantie te verbeteren: 13

21 Referentiesystemen Globaal Locaal Internationaal Europees Internationaal Europees ITRS ETRS89 ED50 LAMBERT72 WGS84 BEREF Figuur 3.4: schematische voorstelling van de verschillende referentiesystemen Als eerste is ervoor gezorgd dat voldoende indexen aangemaakt worden in de databank. Alle velden die gekoppeld zijn of waarover gezocht wordt, werden geïndexeerd. Als index type werd zo goed als overal een B-tree gebruikt. Een geografische selectie uitvoeren op een kaart gebeurt met de volgende SQL-query: SELECT a.*,g.x,g.y FROM data a JOIN gemnm b ON a.location = b.gemnm JOIN gem c ON b.gemid = c.id JOIN straatnm d ON d.straatnm = a.straatnaam AND d.nisgemcode = c.nisgemcode JOIN huisnr e ON e.huisnr = a.nummer AND d.id = e.straatnmid JOIN tobjhnr f ON e.id = f.huisnrid JOIN terrobj g ON f.terrobjid = g.id WHERE g.y >= co1.getlongitude() AND g.y <= co2.getlongitude() AND g.x >= co1.getlatitude() AND g.x <= co2.getlatitude() Hierbij kan niet ontsnapt worden aan een scan over de lengte- en breedtecoördinaten. Een scan over rijen is traag. Echter met een index zou de databank dit in 21 stappen kunnen doorzoeken, hetgeen sowieso een enorme performantieverbetering is. Bij het matchen van straatnaam en gemeentenaam worden sommige koppelingen 14

22 tabel aantal records data gemnm 742 gem 589 straatnm huisnr tobjhnr terrobj Tabel 3.3: weergave van het aantal records per tabel niet gemaakt aangezien de data lichtjes verschillen. Om dit te vermijden moet de straatnaam en plaatsnaam uit de databank een beetje opgekuist worden. Onnodige spaties en speciale symbolen voor en na straatnamen en plaatsnamen moeten worden weggewerkt en voor het matchen moeten data in hoofdletters gezet worden om geen koppelingen te missen door een verschil in hoofd- en kleine letters. Echter de straatnm tabel is zeer groot en door een upper(straatnm) te gebruiken in de code kan de databank de index op dat veld niet gebruiken. Als tweede aanpassing worden onmiddellijk bij het inlezen van de gegevens in de databank de kolommen straatnaam en location in uppercase gezet en onnodige symbolen verwijderd. Zo wordt vermeden dat de cleaning on-the-fly moet gebeuren. Pre-processing wordt gezien als de sleutel tot een goede performantie. Tenslotte is er nog het probleem dat gemeenten en steden vaak een andere naam hebben naargelang de taal waarin ze beschreven zijn. Zo is bv. Tamise de Franse naam voor Temse. In de universiteitsbibliotheek is de plaatsnaam vaak opgenomen in de taal van het werk. Bijkomend probleem is dat er niet echt een standaard is voor de plaatsnamen die in de databank voorkomen. Zo kan Sint-Niklaas ook voorkomen als Sint Niklaas of St. Niklaas. Dit maakt opzoeken op locatie uiteraard enorm moeilijk. 3.2 Cities databank Het probleem van de verschillende talen en vormen waarin dezelfde plaatsnaam kan voorkomen in de databank deed nadenken om de bestaande CRAB-adrespositiesdatabank uit te breiden met extra tabellen. Onderzoek heeft naar de GeoNames webpagina (8) geleid. 15

23 De GeoNames geografische databank staat gratis ter beschikking en bevat meer dan acht miljoen geografische namen en 6,5 miljoen unieke plaatsbeschrijvingen waarvan het in 2,2 miljoen gevallen gaat over bevolkte gebieden en in 1,8 miljoen gevallen over alternatieve namen. Alle plaatsbeschrijvingen worden onderverdeeld in één van negen categorieën, die verder opgedeeld worden in codes 6. De gegevens zijn toegankelijk via een aantal webservices en via bestanden op de server. GeoNames integreert geografische gegevens zoals plaatsnamen in verschillende talen, vliegtuigroutes, bevolkingsaantallen en andere gegevens die afkomstig zijn van verschillende bronnen. Alle breedtegraad/lengtegraadcoördinaten hebben de WGS84 datum, waardoor ze direct kunnen gebruikt worden in de webapplicatie. Tenslotte is er een handige interface ter beschikking waarmee gebruikers de mogelijkheid hebben om handmatig nieuwe namen bij te voegen en te wijzigen. Op de downloadpagina van de GeoNames website (7) is er voor verschillende landen, waaronder België, een zip-bestand te downloaden met daarin alle plaatsbeschrijvingen. Dit bestand wordt geïmporteerd in de databank. De aldus gecreëerde databank bestaat uit 19 velden, die zeker niet allemaal nodig zijn voor een vlotte werking van de applicatie. Deze velden worden weergegeven in Tabel 3.4. Nu worden enkel die records geselecteerd die daadwerkelijk de naam zijn van een stad of gemeente. Dit gebeurt door het uitvoeren van de volgende SQL query op de databank: DELETE FROM cities WHERE featureclass <> P ; Hierdoor wordt reeds een eerste selectie gemaakt en zijn onbelangrijke locaties als administratieve centra, toeristische attracties en musea uit de databank verdwenen. Eens dit gedaan, worden de velden verwijderd die voor de applicatie niet van belang zijn. Enkel de velden geonameid, name, alternatenames, latitude, longitude en country code worden bewaard. Hetgeen de uiteindelijke bedoeling is, is om te kunnen zoeken op zowel de naam als de alternatieve naam van een locatie. Echter wordt het heel omslachtig en is het catastrofaal voor de performantie om telkens de velden name en alternatenames te moeten doorzoeken bij elke zoekopdracht. Daarom wordt de cities tabel naar een tijdelijke tabel gekopieerd en wordt het veld alternatenames opgedeeld met een StringTokenizer in verschillende woorden en met behulp van Java en JDBC wordt een nieuwe cities tabel opgebouwd met voor elke plaatsnaam (zowel de officiële als de alternatieve namen) een aparte record in de tabel

24 Uiteraard wordt dezelfde identifier (id) behouden voor de verschillende schrijfwijzen van de plaatsnaam, waardoor die niet meer uniek is. De verkregen cities databank wordt afgebeeld in Figuur 3.5. geonameid name asciiname alternatenames latitude longitude feature class feature code country code cc2 admin1 code admin2 code admin3 code admin4 code population elevation gtopo30 timezone modification date id van het record in de geonames database (int) naam van het geografische punt (utf8) (varchar(200)) naam van het geografische punt in ascii (varchar(200)) alternatieve namen, gescheiden door een komma (varchar(4000)) breedtegraad in decimale graden (wgs84) lengtegraad in decimale graden (wgs84) categorie waartoe het record behoort (vb P : city, village,...) (char(1)) code waartoe het record behoort (vb PPLC : capital of a political entity) (varchar(10)) ISO-3166 landcode, 2 letters alternatieve landcodes, gescheiden door een komma (60 characters) fipscode, isocode voor de us en ch (varchar(20)) code voor tweede niveau administratieve afdeling (varchar(80)) code voor derde niveau administratieve afdeling (varchar(20)) code voor vierde niveau administratieve afdeling (varchar(20)) bevolking (integer) hoogte in meter (integer) gemiddelde hoogte van een 30 x30 in meter (integer) id met de tijdzone (integer) datum van de laatste wijziging (yyyy-mm-dd) Tabel 3.4: overzicht van de verschillende velden in de cities tabel Figuur 3.5: screenshot van de cities databank Verschillende schrijfwijzen van eenzelfde locatie zijn opgenomen in de cities databank en hebben hetzelfde id. Als voorbeeld in Figuur 3.5 wordt opnieuw Temse genomen. 17

25 Deze databank is de beste manier om een zo groot mogelijk aantal verschillende schrijfwijzen van een locatie te laten matchen. Aangezien het hier om een prototype gaat wordt enkel het Belgische bestand geïmporteerd in de databank. Dit is echter gemakkelijk uitbreidbaar naar alle grote landen. Bovendien komen er in de dump die ontvangen werd uitsluitend Belgische locaties voor, wat het importeren van andere landen in deze databank eigenlijk zinloos maakt. 3.3 Library databank De beelddatabank die opgebouwd wordt uit de MARCXML dump krijgt de naam library. In het MARC formaat worden velden (tags) geïdenticeerd met een nummer en subvelden door een letter voorafgegaan door een $. Veel landen hadden hun lokale varianten, maar tegenwoordig wordt veel gebruik gemaakt van MARC21. Indien MARC21 records in XML gerepresenteerd worden spreekt men van MARCXML. MARC-tags en -subvelden worden dan omgezet naar XML-tags en XML-attributen. Dit maakt het mogelijk om XML-tools zoals XPath te gebruiken voor de presentatie en verwerking van MARC-records. Het MARCXML bestand bestaat uit verschillende MARC records, waarvan er hieronder een voorbeeld getoond is. Het eerste veld in het record is het leader-veld. Het telt altijd 24 tekens en bestaat uit data elementen die informatie bevatten om automatische systeemverwerking mogelijk te maken. Hierna volgen een aantal controlevelden. Controlevelden bevatten nooit subveldcodes. Ze kunnen een enkel data element bevatten of een aantal data-elementen met vaste lengte. De voor de applicatie belangrijkste velden zijn de datavelden die de bibliografische gegevens bevatten. <marc:record> <marc:leader>00000nkm 22 a 4500</marc:leader> <marc:controlfield tag="001"> </marc:controlfield> <marc:controlfield tag="005"> </marc:controlfield> <marc:controlfield tag="008">050302q xx nnn r zn </marc:controlfield> <marc:datafield ind1="7" ind2=" " tag="024"> <marc:subfield code="2">info</marc:subfield> <marc:subfield code="a">info:ugent-repo/topo/390-b-00006</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="040"> <marc:subfield code="a">ugent</marc:subfield> </marc:datafield> <marc:datafield ind1="0" ind2="0" tag="245"> <marc:subfield code="a">mortsel-vieux-dieu :</marc:subfield> <marc:subfield code="b">proprit de Mme Martin chausse de Lierre</marc:subfield> <marc:subfield code="h">[graphic material]</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="260"> 18

26 <marc:subfield code="c">[eind 19e-begin 20e eeuw].</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="500"> <marc:subfield code="a">g. Bongartz, Vieux Dieu</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="540"> <marc:subfield code="a">reproductierecht Universiteitsbibliotheek UGent</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="580"> <marc:subfield code="a">topografische collectie Universiteitsbibliotheek Gent</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="662"> <marc:subfield code="a">belgi</marc:subfield> <marc:subfield code="b">vlaanderen</marc:subfield> <marc:subfield code="c">antwerpen (prov.)</marc:subfield> <marc:subfield code="d">mortsel(2640)</marc:subfield> <marc:subfield code="f">mortsel(2640)</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="691"> <marc:subfield code="a">kastelen</marc:subfield> <marc:subfield code="b">dut</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="692"> <marc:subfield code="a">chteaux</marc:subfield> <marc:subfield code="b">fre</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="693"> <marc:subfield code="a">castles</marc:subfield> <marc:subfield code="b">eng</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="852"> <marc:subfield code="b">cd12l</marc:subfield> <marc:subfield code="c">brkz</marc:subfield> <marc:subfield code="j">brkz.topo.0390.b</marc:subfield> </marc:datafield> <marc:datafield ind1=" " ind2=" " tag="920"> <marc:subfield code="a">image</marc:subfield> </marc:datafield> </marc:record> De subvelden die voor de applicatie van belang zijn, zijn respectievelijk de titel van het werk, de auteur, beide data, de locatie en de URL van de afbeelding. Tabel 3.5 geeft een overzicht van de verschillende attributen die nodig zijn en hun respectievelijke velden en subvelden in het MARC record. Importeren van de velden uit het MARCXML bestand gebeurt via het XMLProducer programma (15) dat ontworpen werd door de Gentse Universiteitsbibliotheek. Mits enkele kleine aanpassingen kunnen velden uit het MARCXML bestand gehaald worden en opgeladen worden in de bibliotheekdatabank. Het commando waarbij een titel uit het MARCXML bestand wordt gehaald is het volgende: <entry key="title" 245 a ]"/> 19

27 attribuut veldtype veldtag subveldcode title dataveld 245 a author dataveld 100 a date1 controleveld 008 karakter date2 controleveld 008 karakter location dataveld 260 a url dataveld 024 a Tabel 3.5: overzicht van de geïmporteerde velden in de library tabel Hierbij is TITLE de sleutel en het XPath de verwijzing naar de plaats in het XML record waar de waarde die bij de sleutel hoort moet worden opgehaald. Onmiddellijk na het inlezen van het MARCXML bestand en voor het toevoegen aan de database worden de gegevens nog even gepreprocessed. Vaak komen er in velden die later moeten vergeleken worden met andere velden speciale symbolen voor zoals :, ] en [ en worden sommige locaties en titels in kleine letters geschreven, terwijl andere keren hoofdletters worden gebruikt. Dit wordt getoond in Figuur 3.6. Opdat deze velden zo goed mogelijk zouden kunnen vergeleken worden met velden in andere databanken worden ze opgekuisd met het volgende commando: location = String.valueOf(resultSet.getObject("location")).replaceAll(" :","").replaceall("[","").replaceall("]","").replaceall(" "," ").touppercase(); De laatste replaceall(" "," ") is nodig aangezien importeren van tekst waarin een aanhalingsteken voorkomt voor fouten zorgt bij het inlezen in een postgresql databank, omdat dat symbool conflicteert met de aanhalingstekens van de SQL queries. Om een bibliotheekitem visueel te kunnen weergeven op een kaart zijn echter nog een straatnaam en een huisnummer nodig. Deze velden worden toegevoegd aan de library tabel en de waarde ervan wordt hard gecodeerd. Dit is jammer, maar bij geen enkel record zijn deze gegevens beschikbaar. Verder wordt de tabel nog uitgebreid met een landcode die overeenkomt met de landcode uit de Cities databank waar de plaatsnaam dezelfde is. Om tenslotte het resultaat van de query op de databank zo snel mogelijk te kunnen visualiseren op het scherm, worden er nog twee velden aan toegevoegd bij elk record die de breedtegraad, respectievelijk de lengtegraad van het bibliotheekitem voorstellen. Voor een record toegevoegd wordt aan de databank, worden zijn coördinaten berekend via de hierboven beschreven techniek. Vandaag is het ook mogelijk om via een webservice van Google Maps een straatnaam en een huisnummer op te geven en 20

28 Figuur 3.6: screenshot van de ingelezen MARCXML dump zonder preprocessing Google Maps stuurt de unieke lengte- en breedtegraad van dat adres terug. In de applicatie zijn methodes voorzien die de coördinatentransformatie tussen BD 1972 en EPRS89 doen zodat met de CRAB-adresposities tabellen kan gewerkt worden, maar standaard wordt gebruikt gemaakt van de webservice van Google maps om de coördinaten terug te vinden, wat opzoeken veel sneller maakt. Google Maps webservice gebeurt met de volgende link: Hierbij is address een String die het adres beschrijft en moet als waarde van de sleutel key de persoonlijke Google Maps sleutel ingevoerd worden om van de webservice gebruik te kunnen maken. Verder kan bij de key output gekozen worden in welk formaat het antwoord van de webservice dient ontvangen te worden. Met het oog op bruikbaarheid in verschillende landen en kijkend naar de evolutie op dit gebied is het werken met de WGS84 datum vast en zeker de betere keuze. Op de site van het NGI wordt meer uitleg gegeven over de verschillende coördinatenstelsels en worden algoritmen beschreven die de transformatie mogelijk maken tussen Lambert72 coördinaten en ETRS89 coördinaten. Uit allerlei informatie die op de site te 21

29 vinden was, werd het transformatiealgoritme opgebouwd, dat beschreven wordt in Appendix A. 3.4 Ontwikkelingen Met databanken beschreven zoals hierboven beschikt men reeds over solide raamwerken voor het modelleren en beheren van geografische informatie. De gestadige evolutie in computertechnologie geeft echter voortdurend aanleiding tot nieuwe onderzoeks- en toepassingsgebieden. Zo is men ondermeer bezig met geografische databanken (25). Een geografische databank is een databank die ontworpen werd om gegevens in een geografische omgeving op te slaan en te bevragen. Typische databanken kennen verschillende types numerieke en karakterdatatypes. Voor geografische databanken moeten echter bijkomende functionaliteiten worden voorzien om spatiale datatypes te kunnen verwerken. Typisch worden deze datatypes geometry of feature genoemd. Het Open Geospatial Consortium (14) heeft de Simple Features specificatie ontwikkeld en bepaalt standaarden voor het toevoegen van geografische functionaliteiten aan databank systemen. 22

30 Hoofdstuk 4 Gebruikersinterface 4.1 Inleiding Voor de ontwikkeling van de applicatie wordt uitgegaan van een drie-lagen architectuur (17). Bij een drie-lagen architectuur wordt een horizontale indeling aangebracht in applicaties. Er wordt een onderscheid gemaakt in een presentatie, logica en data laag. De componenten in de presentatie-laag verzorgen de presentatie (de userinterface) naar de eindgebruiker, mogelijk langs verschillende presentatie-kanalen. De logica-laag bevat de componenten waarin de functionaliteiten van de applicatie zijn geïmplementeerd. De data-laag bevat de componenten voor de toegang tot de gegevensverzamelingen. Een overzicht van het drie-lagen model wordt getoond in Figuur 4.1. Bij een goede toepassing kan het drie-lagen model de ontwikkeling sterk vergemakkelijken. Volgens het verdeel-en-heers -principe wordt de applicatie onderverdeeld in drie eenvoudigere delen, die perfect losstaan van elkaar en elk een apart domein beschrijven: GUI design voor de gebruikersinterface, Java programmeren voor de objectenlaag en Database engineering voor de tabellen. In dit hoofdstuk wordt dieper ingegaan op de gebruikersinterface. In het volgende hoofdstuk wordt de business logica in de objectenlaag en de data laag behandeld. Zoals reeds werd aangegeven in de inleiding is de kern van de interface de Google Maps applicatie. 23

31 Presentatielaag De bovenste laag van de applicatie is de gebruikersinterface. De belangrijkste functie van de interface is om taken en resultaten om te zetten naar iets wat voor de eindgebruiker verstaanbaar is. Duid een gebied aan op een kaart Geef de resultaten grafisch weer op die kaart Logische laag Deze laag coördineert de applicatie, voert commando s uit, maakt logische beslissingen en evaluaties, en doet berekeningen. Hij fungeert ook als doorgeefluik voor informatie tussen de hogere en de lagere laag. Zoek alle bibliotheekitems binnen een bapaald gebied Haal alle bibliotheekitems uit het XML record en voeg ze samen tot een oplossing QUERY XML Data laag In deze laag wordt informatie opgeslaan en wordt informatie opgehaald uit een databank of een bestandssysteem. Deze informatie wordt dan teruggegeven aan de logische laag voor verdere verwerking en wordt daar eventueel doorgegeven naar de gebruiker Databank MARCXML Figuur 4.1: Overzicht van het 3 lagen model 4.2 Google maps Google Maps is een gratis web mapping service applicatie en technologie aangeboden door Google. De Google Maps applicatie bestaat uit een kaart die de gebruiker kan verslepen en waarop kan worden ingezoomd. Standaard biedt Google Maps vijf viewing modes aan: Kaart (topografische kaart en stratenplan), Satelliet (satellietbeelden en hoge-resolutie luchtfoto s), Terrain (meer grafische voorstelling van een gebied met stratenaanduiding), Street view (360 view van sommige straten op ooghoogte) en Traffic (map met verkeersstromen). Voor de applicatie worden de Map en Satelliet modus gebruikt, samen met een combinatie waarbij straten worden aangegeven op satellietbeelden. 24

32 Google Maps maakt veelvuldig gebruik van JavaScript. De techniek waarbij achter de schermen asynchrone netwerkbevraging wordt gedaan met JavaScript en XMLHttpRequest opdat de interactie van de gebruiker met de applicatie niet verstoord wordt, wordt AJAX (Asynchronous JavaScript and XML) genoemd. Google Maps zelf maakt zelden gebruik van XmlHttpRequest, maar gebruikt meestal een verborgen IFrame. Om performantieredenen gebruikt Google JSON ipv XML voor gegevensoverdracht. Beide technieken vallen ook onder de AJAX noemer. Om de integratie van Google Maps in web applicaties te vergemakkelijken, heeft Google de Google Maps API ontworpen. Hiermee bieden ze de mogelijkheid om de applicatie aan te passen aan de eigen wensen en eigen features aan de map toe te voegen. 4.3 Gebruikersinterface De gebruikersinterface is toegankelijk via een web browser en bestaat uit 6 verschillende HTML (Hyper Text Markup Language) pagina s. 5 pagina s die toelaten op verschillende velden in de databank te zoeken. Respectievelijk op titel, auteur, datum, locatie en een geaggregeerde zoekopdracht waarbij aan elk veld een gewicht kan toegekend worden waarmee het belang van dat veld bij de zoekoperatie kan aangegeven worden. Tenslotte is er ook nog een pagina voorzien waar handmatig records aan de databank kunnen worden toegevoegd. Een screenshot van de volledige gebruikersinterface wordt getoond in Figuur 4.2. De afzonderlijke pagina s worden getoond in Figuur 4.3. Voor het ontwerp van de gebruikersinterface werden ideeën gehaald bij de website van recollecting landscapes (18), een herfotografieproject waaraan de Gentse universiteit haar medewerking verleende. De zoekpagina s zijn opgebouwd in DHTML (Dynamic HTML). DHTML is de verzameling van technieken die samen gebruikt worden om webpagina s interactief te maken; een statische taal (zoals HTML), een client-side scripting language (zoals JavaScript), een opmaaktaal (zoals CSS) en het Document Object Model. Als alternatief voor het Document Object Model wordt SAX gebruikt (Simple API for XML). SAX is een API voor het parsen van XML. Een parser die SAX implementeert (een SAX-parser) behandelt de XML-informatie als een enkele sequentiële 25

33 Figuur 4.2: Screenshot van de gebruikersinterface gegevensstroom. Deze gegevensstroom wordt in e e n richting afgehandeld, eerder gelezen data kan dus niet opnieuw gelezen worden zonder het geheel opnieuw te parsen. Een SAX-parser werkt volgens een event-gestuurd model, waarin de programmeur callback-methoden implementeert die door de parser worden aangeroepen wanneer die het XML-document doorloopt. SAX is toestandsloos en heeft bijgevolg weinig geheugenruimte nodig in vergelijking met de volledig opgebouwde gegevensboom in het DOM-model. Hierdoor is het goed bruikbaar voor de verwerking van grote gegevenshoeveelheden Opbouw HTML pagina de <BODY>-tag, die beschrijft wat eigenlijk te zien gekregen wordt van de HTML pagina, bevat praktisch geen informatie. Enkel worden met <DIV>-tags, die een bepaald deel van de pagina beschrijven, een map en eventueel nog andere Javascript 26

34 Zoeken op t i t el Zoeken op aut eur Zoeken op l ocat i e Zoeken op dat um It em t oevoegen Samengest el dezoekopdr acht Figuur 4.3: Screenshots van de verschillende zoekpagina s componenten toegevoegd, die dan in het JavaScript gedeelte binnen de <HEAD>tag verder gedefinieerd worden. Bij de oproep van de HTML pagina wordt dan een functie load() opgeroepen die de verschillende componenten definieert. Het BODY element van een HTML pagina ziet er als volgt uit: <BODY BGCOLOR="A7A7A7" CLASS="text" ONLOAD="load()" ONUNLOAD="GUnload()"> <CENTER><DIV ID="map" STYLE="width: 750px; height: 400px"></DIV></CENTER> </BODY> 27

35 Hierna worden in verschillende JavaScript functies de veranderlijken opgevraagd zoals de coördinaten van het zichtbare deel van de kaart, het zoomniveau, de vaagheidsfactor of de query waarnaar moet gezocht worden. Deze waarden worden dan als argumenten meegezonden via AJAX en het XMLHttpRequest naar een servlet. Een servlet is een in Java geschreven programma dat binnen een J2EE-webcontainer op een server draait. De servlet maakt hierbij gebruik van een aantal diensten die de webcontainer biedt, zoals het afhandelen van de communicatie met de client. Deze communicatie vindt meestal plaats op basis van het HTTP-protocol. De servlets liggen reeds in de objectenlaag en schermen complexiteiten van de onderliggende data-laag af voor de client. Als voorbeeld wordt de functie loadcities() getoond, die de coördinaten van een beschreven rechthoek als argument neemt en die een oproep doet naar de servlet SearchLocation en daarvan een XML bestand terugkrijgt. Eens dit XML bestand wordt ontvangen wordt de functie processcitydata() opgeroepen die dan de nodige informatie uit dat XML bestand gaat halen. function loadcities(longitude1,latitude1,longitude2,latitude2) { var request = GXmlHttp.create(); request.open("get", " method=findcoveredcities&longitude1="+longitude1+"&longitude2=" +longitude2+"&latitude1="+latitude1+"&latitude2="+latitude2, true); request.onreadystatechange = getcallbackfunction(request, processcitydata); request.send(null); } Voorbeeld In dit deel wordt als voorbeeld getoond hoe zoeken op locatie gebeurt. Bij het zoeken wordt onderscheid gemaakt tussen het zoeken op stedelijk en het zoeken op lokaal niveau. Omschakelen naar een andere modus gaat automatisch bij het veranderen van zoomniveau. Wanneer bij een zoekoperaties de kaart een zoomniveau heeft kleiner of gelijk aan 12, wordt op stedelijk niveau gezocht. Indien het zoomniveau bij het zoeken groter is dan 12 wordt op lokaal niveau gewerkt. Dit werd vooral gedaan om het zoeken overzichtelijk te maken. Het terugvinden van een bepaald werk heeft pas zin indien hard genoeg ingezoomd is en de straten en plaatsen echt kunnen herkend worden. In Figuur 4.4 wordt zoeken op locatie op stedelijk niveau geïllustreerd. De gebruiker activeert via de knop links beneden de selecteermodus, waardoor het scherm donkerder kleurt. Nu kan hij door de muis in te drukken en in een bepaalde richting te slepen een rechthoekig gebied selecteren. Wanneer hij de muis loslaat wordt de methode loadcities() van hierboven opgeroepen met de 28

36 coördinaten van de beschreven rechthoek als argument. Enkele ogenblikken later worden met rode stippen de steden aangegeven waar zich bibliotheekitems bevinden. Door op de marker van de stad te klikken, wordt sterk ingezoomd en wordt de stad het centrum van de kaart. Indien dan verder ingezoomd wordt naar een zoomniveau groter dan 12, kan gezocht worden op bibliotheekitems. Dit wordt getoond in Figuur 4.5. Op de eerste 2 figuren is de overgang te zien. Een bibliotheekitem wordt op lokaal niveau afgebeeld met een fototoestel. Op dit fototoestel kan geklikt worden, waardoor er zich een pop-upvenster opent met informatie over de foto en een thumbnail van de foto. Indien op de thumbnail geklikt wordt opent zich een nieuw venster met de volledige foto. Zoeken op auteur en titel gebeurt analoog. Daar is een extra tekstveld voorzien waar de gebruiker de titel of auteur waarop hij wil zoeken kan ingeven. Bij het zoeken op datum werd een slider component toegevoegd met twee knoppen. Hiermee kan een tijdsgebied aangegeven worden waartussen de foto moet zijn genomen. Figuur 4.6 toont deze slider component. 4.4 Vage data De spatiotemporele metadata die opgeslagen is bij fotomateriaal biedt perspectieven voor het opzoeken en visualiseren van de data. Het kan echter gebeuren dat de gebruiker zijn zoekopdracht niet perfect kan specifiëren. Zo wordt de informatie vanuit zijn visie onnauwkeurig. Ook kan het gebeuren dat de opgeslagen metadata niet exact is. Zo worden er soms twee data bijgehouden die een tijdsgebied beschrijven waartussen de foto waarschijnlijk is genomen. Dit inzicht biedt perspectieven voor het werken met vage data. Hoewel opgeslagen metadata soms onnauwkeurig is (bv bij een foto kunnen 2 verschillende data opgeslagen zijn die een tijdsgebied beschrijven waartussen de foto is genomen) wordt de data niet als vaag beschouwd. De databank wordt gezien als een reguliere databank waarop flexibele bevraging kan worden toegepast. Mechanismen die gebruikt worden voor flexibele bevraging van databanken steunen op vaagverzamelingenleer (27) en possibiliteitstheorie. De kerngedachte bij flexibele bevraging is dat er preferenties worden geïntroduceerd in de vraagstellingen (22). Dit kan gebeuren op twee niveaus: binnen elementaire bevragingscondities en tussen bevragingscondities. Preferenties binnen bevragingscodities geven aanleiding tot flexibele zoekcriteria en laten het toe om uit te drukken dat sommige waarden meer gepast zijn dan andere. Dit wordt in de applicatie toegepast bij het zoeken 29

37 Figuur 4.4: Illustratie van zoeken op locatie met de dragtool 30

38 Figuur 4.5: Illustratie van het weergeven van een bibliotheekitem 31

39 Figuur 4.6: Slider component die gebruikt wordt bij het zoeken op datum op datum en het zoeken op locatie. Preferenties tussen bevragingscondities worden gebruikt om verschillende graden van belangrijkheid te associëren met de condities. Een voorbeeld hiervan is het geaggregeerd zoeken waarbij met de verschillende criteria waarop gezocht wordt een gewicht wordt geassocieerd dat aangeeft hoe hard dit criterium moet doorwegen binnen het totaal van zoekcriteria. Voor deze applicatie wordt het aantal te kiezen gewichten beperkt tot 5. Ze worden weergegeven in Tabel 4.1. gewichtlabel gewicht zeer belangrijk 1.0 belangrijk 0.8 neutraal 0.5 onbelangrijk 0.3 zeer onbelangrijk 0.1 Tabel 4.1: Overzicht van de gebruikte gewichten Preferenties binnen bevragingscondities Zoals reeds aangehaald wordt dit toegepast bij het zoeken op titel en datum. Wanneer de gebruiker een tijdsgebied aangeeft met de slider kan hij via een keuzelijst kiezen hoe strict hij dit tijdsgebied beschouwt. Indien hij de data heel strict ziet is er geen sprake van onnauwkeurigheid en zal de voldoeningsgraad van zijn opvraging een element zijn van de verzameling {0, 1}. Echter wanneer hij het tijdsgebied minder exact wil definiëren, kan een groter gebied beschouwd worden waardoor de voldoeningsgraad kan behoren tot de verzameling [0, 1]. De continue lidmaatschapsfunctie die wordt verkregen door vaagheid in de opzoeking te brengen kan worden gemodelleerd door een trapezoïdale vormfunctie. Dit wordt geïllustreerd in Figuur 4.7. Er wordt vanuit gegaan dat het tijdstip waarop de foto wordt genomen onbekend is en gemodelleerd wordt door 2 data (op de figuur voorgesteld door de groene 32

40 rechthoekige grafiek die de waarde 1 krijgt in het tijdsgebied begrensd door de 2 data). In de applicatie wordt gewerkt met possibilistische waarheidswaarden waardoor een lidmaatschapsfunctie µ gebruikt wordt in plaats van de voldoeningsgraad. Voor de visualisatie wordt enkel rekening gehouden met de lidmaatschapsfunctie µ(t ). Wanneer de vraagstelling exact is, is te zien dat de trapezoïdale vormfunctie een rechthoekige vorm krijgt. Dit wordt getoond in figuur A. In figuur B en C vertonen de twee grafieken een overlapping bij functiewaarde 1. In figuur D is eveneens een overlapping, maar slechts op de zijflanken van de trapezoïdale functie. Hier wordt de lidmaatschapsfunctie µ(t ) berekend op basis van het snijpunt van de twee grafieken. Naar het algemene idee moet ook bij de visualisatie van de data de vaagheid grafisch voorgesteld worden. Er werd gekozen om de marker van de steden en het fototoestel dat de bibliotheekitems weergeeft een bepaalde kleur mee te geven volgens zijn lidmaatschapsgraad: een rode marker wanneer de lidmaatschapsgraad gelijk is aan 1, een oranje marker wanneer de lidmaatschapsgraad binnen het interval [0.5, 1[ ligt en een gele marker voor het interval ]0, 0.5[. Het resultaat van een zoekactie wordt getoond in Figuur 4.8 waar de markers die de plaatsnamen weergeeft een kleur krijgen naargelang hun lidmaatschapsgraad. Werken met preferenties binnen condities bij het zoeken naar titel en auteur is moeilijker, omdat het hier minder evident is de onnauwkeurigheden in de vraagstelling op te vangen. Een mogelijke oplossing hier is om te werken met String Matching algoritmes (26). Hierop werd niet dieper ingegaan, aangezien dit een complex probleem is. Dit probleem vormt zelfs een onderzoeksdomein op zich. Bovendien valt het ook ook buiten de doelstelling van dit afstudeerwerk. Bij het zoeken naar locatie en datum is werken met inexacte data mogelijk. Aan deze twee pagina s werd een slider component toegevoegd waarbij vijf waarden kunnen worden ingesteld (0-5 : van inexacte naar exacte data). Deze slider component wordt getoond in Figuur Preferenties tussen bevragingscondities In dit deel wordt dieper ingegaan bij de samengestelde bevragingsconditie. Tradiotioneel zijn alle enkelvoudige condities die voorkomen in een samengestelde bevragingsconditie even belangrijk. Nochthans kan het voorkomen dat de gebruiker bepaalde prioriteiten (voorkeuren en preferenties) heeft en wenst dat bepaalde condities meer relevant zijn voor het resultaat van de vraagstelling dan andere. Dit kan worden gerealiseerd door gewichten te associëren met de condities. Om de impact van gewichten adequaat te kunnen modelleren binnen het raamwerk dat gebruikt wordt voor de ondersteuning van flexibele bevraging, kunnen implicatieoperatoren 33

41 A B C D Figuur 4.7: Vormfunctie bij de flexibele bevraging van reguliere data Figuur 4.8: Visualisatie van een zoekopdracht waarbij de vraagstelling vaag is geformuleerd 34

42 Figuur 4.9: Slider component voor het instellen van de nauwkeurigheid van de zoekopdracht bij het zoeken op locatie en datum worden gebruikt. Inzicht in deze implicatieoperatoren werd vooral gekregen door het vak Vage Databanken (16), gedoceerd aan de Universiteit Gent. Er kan een onderscheid gemaakt worden tussen de implicatoroperatoren: ze kunnen voor conjunctie of disjunctie zijn. Voor de geaggregeerde zoekopdracht worden enkel de implicatoroperatoren voor conjunctie gebruikt. Ze zouden ook voor disjunctie kunnen geïmplementeerd worden, maar dat zou de overzichtelijkheid en de gebruiksvriendelijkheid van de applicatie niet ten goede gekomen zijn. In de applicatie kan gekozen worden tussen 3 verschillende aggregatieoperatoren: Zadeh: volgens extensieprincipe van Zadeh logische: op basis van logische(zadeh) t-norm en t-conorm probabilistische: op basis van probabilistische t-norm en t-conorm Voor de praktijk interessante impicatoroperatoren, waartussen voor de geaggregeerde zoekopdracht kan gekozen worden, zijn de volgende: Kleene-Dienes : (P K D Q) = (max(1 p, q)) Reichenbach: (P Rb Q) = (1 p + p q) 1 als p q Gödel: (P Go Q) = q anders In Appendix B worden de verschillende soorten logische operatoren besproken en wordt dieper ingegaan op de hierboven geïntroduceerde operatoren. Tenslotte wordt ook de mogelijkheid gegeven om te werken met of zonder gewichtspropagatie. Indien er gewerkt wordt zonder gewichtspropagatie worden de gewichten slechts éénmalig in rekening gebracht bij het begin van de berekening. Indien er gewerkt wordt met gewichtspropagatie worden de gewichten ook in rekening gebracht bij het begin van de berekening, maar wordt daarenboven aan alle tussenresultaten een nieuw, berekend, gewicht toegekend, dat dan bij verdere berekeningen opnieuw in rekening gebracht kan worden. 35

43 Tenslotte wordt in Figuur 4.10 nog een overzicht gegeven van het formulier met de invoervelden en de verschillende keuzemogelijkheden in de applicatie. Ook bij het geaggregeerde zoeken wordt de gevonden data gevisualiseerd op een kaart en net zoals bij het zoeken op datum en op locatie krijgen de markers een verschillende kleur naargelang de lidmaatschapsgraad van het object dat ze beschrijven. Figuur 4.10: Keuzeformulier voor de geaggregeerde zoekopdracht 36

44 Hoofdstuk 5 Business logica 5.1 Inleiding In dit deel wordt dieper ingegaan op de onderste 2 lagen van de drie-lagen architectuur. De middenste laag is de logische laag, die ook wel de Business logica genoemd wordt. De logische laag is eigenlijk een afsplitsing van de presentatielaag en beheert de functionaliteit van de applicatie door gedetailleerde verwerking. Een belangrijk idee bij het opdelen van de applicatie in 3 delen is om de functionaliteit te verdelen over drie eenvoudigere delen, die perfect losstaan van elkaar en elk een apart domein beschrijven. Hiernaast is ook het principe van Information Hiding (23) belangrijk, waarbij gewerkt wordt met interfaces die een opdeling maken tussen de functionaliteit en de implementatie. Op deze manier wordt de informatie afgeschermd tussen de verschillende modules doordat enkel met de interface wordt gecommuniceerd. Bijkomend voordeel is dat deze aanpak het implementeren erg vergemakkelijkt en overzichtelijk maakt en bijdraagt tot een grotere portabiliteit (19). Het begrip portabiliteit of overdraagbaarheid omvat de kwaliteitsattributen betreffende de capaciteit om software van één omgeving naar een andere te transfereren (porteren). Apart van de voor de hand liggende voordelen van moduleerbare software met goed gedefinieerde interfaces, is het de bedoeling van de drie-lagen architectuur dat elk van de drie lagen onafhankelijk van de anderen kan upgedate of vervangen worden als de requirements of de technologie veranderen. Zo heeft een switch van besturingssysteem enkel effect op de User Interface code van de presentatielaag. 37

45 5.2 Ontwerp Servlets Zoals reeds gezien werd in het vorige hoofdstuk, wordt voor elke query aan de clientzijde een oproep gedaan naar een servlet. Een servlet is een in Java geschreven programma dat binnen een J2EE-webcontainer op een server draait. De servlet maakt hierbij gebruik van een aantal diensten die de webcontainer biedt, zoals het afhandelen van de communicatie met de client. Deze communicatie vindt meestal plaats op basis van het HTTP-protocol. Die servlet-oproep vormt de overgang van de presentatielaag naar de logische laag. Het servlet object bevindt zich dus al in de logische laag. Het oproepen van de servlet vanuit de webinterface gebeurt op de volgende manier: var req = GXmlHttp.create(); req.open("get", " + " + method=findlibraryelementbyid&id="+id, true); req.onreadystatechange = getcallbackfunction(req, displaydetails); req.send(null); In de eerste lijn wordt een XMLHttpRequest instantie verkregen. De tweede lijn zorgt voor de eigenlijke servlet oproep door een HTTP GET connectie te openen naar de SearchTitle servlet. De derde parameter wijst erop dat de request asynchroon is. De derde lijn tenslotte stelt de handler functie in om callbackwaarschuwingen te krijgen van het request object. Indien de servlet zijn taak afgehandeld heeft en de oproeppagina krijgt een javax.servlet.servletresponse terug, dan wordt hierdoor de functie displaydetails opgeroepen. Een schematische voorstelling van de werking van een servlet wordt gegeven in Figuur 5.1: Een webbrowser roept zoals hierboven besproken een URL op waarmee een servlet geassocieerd is. Het servlet draait steeds op een server. Voor onze applicatie wordt Tomcat v6.0 (3) gebruikt. Het servlet business object heeft een levensduur gelijk aan die van de server. De server instantieert het servlet object en vuurt het init event. De server vuurt ook het service event voor elke request bij die URL. Het service event bevat steeds 2 parameters: het javax.servlet.servletrequest en het javax.servlet.servletresponse. Het ServletRequest geeft toegang tot de volledige HTTP request. Nadat de servlet zijn programmacode uitgevoerd heeft, geeft hij het javax.servlet.servletresponse terug. De inhoud hiervan kan geprogrammeerd worden en is in onze applicatie een XML file met alle gevraagde resultaten. 38

46 webbrowser URL REQUEST 1 javax.servlet. ServletRequest Service event javax.servlet. ServletResponse 3 2 javax.servlet. ServletResponse HTTP Listener Servlet Figuur 5.1: Werking van een Servlet object Data Access Object Binnen de servlet wordt een Data Access Object (DAO) (4) aangeroepen. Een Data Access Object is een object dat een abstracte interface levert voor sommige types databanken of persistentie mechanismes, en die enkele specifieke databankoperaties ter beschikking stellen zonder de details van de databank naar buiten te brengen. In deze applicatie wordt met een CityDAOImpl gewerkt die queries kan uitvoeren naar Cluster de databank. Deze CityDAOImpl implementeert de interface CityDAO. De methodes die moeten geïmplementeerd worden door de CityDAOImpl zijn de volgende (voor de leesbaarheid werden de argumenten weggelaten): package ajax.dao; import java.util.list; import ajax.domain.marker; import ajax.domain.libraryelement; public interface CityDAO { public abstract List<Marker> findallcities(); public abstract List<Marker> findalllocations(); public abstract List<Marker> findallcitiesondate(); public abstract List<Marker> findalllocationsondate(); public abstract List<Marker> findallcitiesontitle(); public abstract List<Marker> findalllocationsontitle(); 39

47 public abstract List<Marker> findallcitiesonauthor(); public abstract List<Marker> findalllocationsonauthor(); public abstract List<Marker> findallcitiesonaggregation(); public abstract List<Marker> findalllocationsonaggregation(); public abstract LibraryElement findlibraryelementbyid(int id); } In Figuur 5.2 wordt het UML klassendiagramma afgebeeld die de relaties toont binnen het DAO pattern. Voor de applicatie is de DataSource een databank. Meer bepaald de library en cities databanken. De DAO implementeert de mechanismen die nodig zijn voor de databanktoegang. In de applicatie gebeurt dit over JDBC (Java DataBase Connection). De code in de DAO waarmee we databanktoegang krijgen is de volgende: db = DriverManager.getConnection("jdbc:postgresql:"+database, username, password); dbmd = db.getmetadata(); System.out.println("Connection to "+dbmd.getdatabaseproductname()+" "+ dbmd.getdatabaseproductversion()+" successful.\n"); sql = db.createstatement(resultset.type_scroll_insensitive,resultset.concur_updatable); In de eerste regel wordt de connectie met de databank gemaakt via JDBC. In de tweede regel wordt metadata opgehaald om de connectie te bevestigen en na de printout met de bevestiging dat er een connectie is met de databank wordt een statement aangemaakt waarmee SQL queries kunnen worden uitgevoerd op de databank. Het BusinessObject vertegenwoordigt de entiteit die het systeem moet ondersteunen. Zoals in de applicatie, een zoekopdracht op titel, auteur, locatie, datum of de geaggregeerde zoekopdracht. Het TransferObject is een object dat aangemaakt wordt met als doel een opzoeking te doen op de databank, of om bewaard te worden in de databank. Tenslotte worden in Figuur 5.3 en Figuur 5.4 nog een sequentiediagramma en een vereenvoudigd klassendiagramma van de logische laag getoond. In het klassendiagramma worden hulpklassen niet afgebeeld. Ook worden om de figuur niet te overladen sommige klassenmethodes weggelaten. Er werd geprobeerd de interessante methodes op te nemen. 40

48 BusinessObject -Attributes- gebruikt DataAccessObject -Attributes- inkapseling DataSource -Attributes- +Operations() +Operations() +Operations() Krijgt, wijzigt, en creëert transfer object bewaar het transfer Object in de persistente data opslag TransferObject -Attributes- +Operations() Figuur 5.2: DAO Design pattern : Client : SearchLocation servlet : CityDAO : DataSource (JDBC) : erez DAM : doget(request : HttpServletRequest, response: HttpServletResponse) findallcities voer query uit resultaat lijst met resultaten serialisatie resultaten in een lijst resultaten in XML serialisatie resultaten in XML haal velden uit de XML oproep naar thumbnail via OpenURL Figuur 5.3: vereenvoudigd sequentiediagramma van de logische laag 41

49 1 1 «interface» Implicator +implic() : double +coimplic() : double Marker -id : int -name : string -coord -probtrue : double City -id : int -name : string -coord Coord -latitude : double -longitude : double GodelR KdS ReichenbachS EPTV -probtrue -probfalse -probundefined «uses» «uses» «uses» «uses» Fuzzyness «uses» citydaoimpl «uses» «interface» CityDAO +findallcities() +findalllocations() +findallcitiesondate() +findalllocationsondate() +findallcitiesontitle() +findalllocationsontitle() +findallcitiesonauthor() +findalllocationsonauthor() +findallcitiesonaggregation() +findalllocationsonaggregation() +findlibraryelementbyid() «uses» «uses» «uses» «uses» LibraryElement -id : int -author : string -title : string -date1 : string -date2 : string -location : string -url : string -address -coord LibRecord -title : string -author : string -date1 : int -date2 : int -location : string 1 1 ExtendedLibRecord -LibRecord -probtrue : double Address -streetname : string -number : string -city : string -postalcode : string -countrycode : string SearchTitle -query : string -citydao +setcitydao() +getcitydao() +doget() +dopost() SearchAuthor -query : string -citydao +setcitydao() +getcitydao() +doget() +dopost() SearchDate -citydao +setcitydao() +getcitydao() +doget() +dopost() citydao -citydao +setcitydao() +getcitydao() +doget() +dopost() SearchAggregation -citydao +setcitydao() +getcitydao() +doget() +dopost() AddRecord -citydao +setcitydao() +getcitydao() +doget() +dopost() Title Author Date Location Aggregation Add Figuur 5.4: vereenvoudigd klassendiagramma van de logische laag 42

50 Hoofdstuk 6 Conclusie In dit afstudeerwerk werd aangetoond hoe databanken met digitaal fotomateriaal, waaraan spatiotemporele metadata gekoppeld zijn, kunnen gevisualiseerd worden op een kaart. hierbij werd uitgegaan van bestaande databanken, die aangepast werden om dit doel te bereiken. Zo is het een noodzaak dat adresgegevens kunnen gekoppeld worden aan unieke lengte- en breedtecoördinaten, die dan gebruikt worden om het bibliotheekitem op de kaart te kunnen afbeelden. Voor het programmeergedeelte werd gebruik gemaakt van gekende design patterns zoals de drie-lagen architectuur, die vooral te maken hebben met het moduleren van verschillende delen van het programma; zo wordt een onderscheid gemaakt tussen de presentatielaag die de gebruikersinterface beschrijft en de business logic, die geïmplementeerd wordt in de logische laag en de datalaag. Bij het onderzoek naar dit afstudeerwerk, werd ondervonden dat er een trend aan de gang is om databanken te visualiseren en op die manier bereikbaarder te maken voor een groot publiek. De stappen van een databank met digitaal fotomateriaal naar de visualisatie ervan op een kaart worden in het gemaakte prototype aangetoond. Echter een grote uitdaging ligt nog in het uitbreiden van bestaande databanktabellen met extra velden die bv. unieke lengte- en breedtecoördinaten bevatten. Dit is nodig omdat het anders om performantieredenen zo goed als onmogelijk wordt om range zoekbewerkingen te gaan doen op ruimtelijke gebieden. Een goede oplossing zou zijn om elk bibliotheekitem te koppelen aan een uniek terrein-id. Indien dan van coördinatenstelsel veranderd wordt, dan moet enkel de tabel met de identifier en daaraan gelinkte coördinaten aangepast worden. Voor België en bij het NGI is de Belgian Datum 1972 zowel op nationaal als 43

51 op internationaal vlak nog steeds het enige officiële referentiesysteem. Echter die coördinaten zijn gebaseerd op de Hayford ellipsoïde en zijn enkel bruikbaar voor België. De toekomst ligt ongetwijfeld in een netwerk van permanente GPS-stations waarvan de coördinaten bepaald zijn in het officiële referentiesysteem (nationaal of Europees). Een andere bedenking is dat er weinig aandacht is besteed aan de situatie waarbij van eenzelfde locatie verschillend digitaal fotomateriaal is bijgehouden. In dat geval worden de markers boven elkaar op de kaart geplaatst. Een ideale oplossing zou zijn om een lijst te laten verschijnen van al het beschikbare fotomateriaal op die locatie en dan de gebruiker de mogelijkheid geven verder te klikken naar het item van zijn keuze. Deze aanpak biedt grote mogelijkheden voor het in beeld brengen van herfotografie en transformaties. Als algemene conclusie kan besloten worden dat met dit afstudeerwerk een prototype is ontworpen, dat nog vele beperkingen vertoont, maar dat met de juiste aanpak en middelen kan uitgroeien tot een uitstekende moduleerbare applicatie die voor verschillende databanken kan gebruikt worden en waarmee de databanken van de Gentse Universiteit met zijn schatten aan fotografische gegevens toegankelijk worden voor een zo breed publiek publiek. 44

52 Bijlage A Coördinatentransformatie 1. Verband tussen Lambert 1972 et 2008 coördinaten Lambert1972 projectie ( x, y) Lb72 ( x', y') Lb72 (1) Lambert correctiegrid (2) geografische coörd. ( ϕ, λ, h) BD72 (3) ( x, y) Lb08 (6) geografische coörd. ( ϕ, λ, h) (5) ETRS89 Lambert2008 projectie geocentrische coörd. ( X, Y, Z) BD72 7 parameter transformatie (4) geocentrische coörd. ( X, Y, Z) ETRS89 Belgian Datum 1972 Datum : BD72 Ellipsoide : Hayford 1924 European Terrestrial Reference System Datum : ETRS89 Ellipsoide : GRS80 Figuur A.1: schematische Opmerking : als men voorstelling bij de transformatie van tussen Lambert de conversie 1972 en 2008 tussen geen gebruik Lambert72 maakt datum en van het correctiegrid (1) kan dit leiden tot fouten van maximum 30 cm. ETRS89 datum In dit deel wordt de transformatie die nodig is om van Lambert72 coördinaten over te gaan naar ETRS89 van dichterbij bekeken. Het volledige conversieschema wordt getoond in Figuur 3.6. Als men bij de transformatie tussen Lambert 1972 en 2008 geen gebruik maakt van het correctiegrid (1) kan dit leiden tot fouten van maximum 30 cm. Aangezien deze fout te verwaarlozen is en er geen nood is om te converteren tot Lambert 2008 is er geen rekening gehouden met het correctiegrid. Nationaal Geografish Instituut 1 45

53 Cartesiaanscoördinatensysteem Geografischofgeodetischcoördinatensysteem A VerbandtussenCartesiaanseengeografischecoördinaten B C Figuur A.2: Overzicht van de verschillende coördinaten en hoe ze zich verhouden tot elkaar In stap (2) en (6) is er een transformatie van vlakke coördinaten (x,y) naar geografische coördinaten (φ,λ): De veranderlijken die nodig zijn voor de transformatie zijn de volgende: φ 1 en φ 2 : breedte van de standaard parallellen φ 0, λ 0 : breedte en lengte van het oorsprongspunt x 0, y 0 : coördinaten van het oorsprongspunt φ, λ : breedte en lengte van het te transformeren punt Hierbij is de lengte λ de ruimtehoek gevormd tussen het vlak van de referentiemeridiaan en de lokale meridiaan. De breedte φ is de hoek gevormd in het vlak van de 46

54 lokale meridiaan door de normaal in het punt en het evenaarsvlak. Dit wordt nog eens getoond in Figuur 3.7 B. De parameters van de projecties Lambert 1972 en 2008 zijn de volgende: Lambert 1972 projectie Lambert 2008 projectie Ellipsoïde Naam Hayford 1924 GRS80 1 grote as (a) ,0 m ,0 m 2 Afplatting (f) 1/297,0 1/298, Standaard ϕ N N parallellen ϕ N N Oorsprong Latitude oorsprong 90 N N Centrale meridiaan E E Verschuiving van x ,013 m ,0 m de oorsprong y ,438 m ,0 m De excentriciteit wordt gedefinieerd als e 2 = 2f f 2. De volgende elementen zijn gemeenschappelijk aan beide transformaties (directe en inverse): m 1 = cos ϕ 1 /(1 e 2 sin 2 ϕ 1 ) 0.5 m 2 = cos ϕ 2 /(1 e 2 sin 2 ϕ 2 ) 0.5 t 1 = tan(π/4 ϕ 1 /2)/[(1 e sin ϕ 1 )/(1 + e sin ϕ 1 )] e/2 t 2 = tan(π/4 ϕ 2 /2)/[(1 e sin ϕ 2 )/(1 + e sin ϕ 2 )] e/2 t 0 = tan(π/4 ϕ 0 /2)/[(1 e sin ϕ 0 )/(1 + e sin ϕ 0 )] e/2 n = (ln m 1 ln m 2 )/(ln t 1 ln t 2 ) g = m 1 /(nt n 1) r 0 = agt n 0 De directe transformatie gebeurt nu als volgt: (φ,λ) (x,y) t = tan(π/4 ϕ/2)/[(1 e sin ϕ)/(1 + e sin ϕ)] e/2 r = agt n θ = n(λ λ 0 ) x = x 0 + r sin θ y = y 0 + r 0 r cos θ 47

55 De inverse transformatie gebeurt op deze manier: (x,y) (φ,λ) r = {(x x 0 ) 2 + [r 0 (y y 0 )] 2 } 0.5 t = (r/ag) 1/n θ = arctan[(x x 0 )/(r 0 (y y 0 ))] λ = (θ/n) + λ 0 ϕ wordt berekend op een iteratieve manier: 1) ϕ 0 = π/2 2 arctan t (benaderde waarde) 2) ϕ i+1 = π/2 2 arctan{t[(1 e sin ϕ i )/(1 + e sin ϕ i )] e/2 } Eerst wordt de benaderde waarde berekend en die wordt dan gebruikt als input voor stap 2. Dit proces wordt herhaald tot de gewenste nauwkeurigheid bereikt is... In stap (3) en (5) gebeurt er een transformatie tussen de geografische coördinaten (φ,λ,h) en geocentrische coördinaten (X,Y,Z). We merken op dat zowel de directe als de inverse transformatie gebeuren op één en dezelfde ellipsoïde. Hier gebeurt de directe transformatie als volgt: (φ,λ,h) (X,Y,Z) v = a/(1 e 2 sin 2 ϕ) 0.5 X = (ν + h) cos ϕ cos λ Y = (ν + h) cos ϕ sin λ Z = [(1 e 2 )ν + h] sin ϕ De inverse transformatie gebeurt dan weer op deze manier: (X,Y,Z) (φ,λ,h) p 2 = X 2 + Y 2 r = (p 2 + Z 2 ) 0.5 u = arctan{(z/p)[(1 f) + (e 2 a/r)]} λ = arctan(y/x) ϕ = atan{[z(1 f) + e 2 a sin 3 u]/[(1 f)(p e 2 acos3u)]} h = p cos ϕ + Z sin ϕa(1 e 2 sin 2 ϕ) 0.5 Hier aangekomen rest ons enkel nog de 7 parameter transformatie die de geocentrische coördinaten transformeert van de Belgische Datum 1972 naar ETRS89: De 7 parameters welke door het NGI worden gepubliceerd steunen op de Coordinate Frame Rotation conventie; indien men gebruik maakt van de Position Vector 48

56 conventie, moet het teken van de drie rotatieparameters veranderd worden. Het gebruik van een verkeerde conventie leidt (gemiddeld) tot een positiefout van 65 meter: Conventie : Coordinate Frame Rotation X Y Z 7 parameters Translatie [meter] ETRS89 BD72 Rotatie in zestigdelige Schaalfactor Conventie : Position Vector X Y Z 7 parameters Translatie [meter] ETRS89 BD72 Rotatie in zestigdelige Schaalfactor Voor de transformatie van BD72 naar ETRS89, moet men het teken van zowel de translatie- als rotatieparameters veranderen en het inverse nemen (1/x) van de schaalfactor. 49

57 Bijlage B Fuzzyness B.1 Logische operatoren In Tabel B.1 geven we een overzicht van de verschillende klassen van waarheidswaarden, de bijhorende symbolen en de waarden die ze kunnen aannemen. klasse van waarheidswaarden notatie Symbolen logische waarheidswaarden TV µ(t ) µ(f ) = 1 - µ(t ) possibilistische waarheidswaarden PTV µ(t ) µ(f ) uitgebreide possibilistische waarheidswaarden EPTV µ(t ) µ(f ) µ( ) Tabel B.1: Verschillende klassen van waarheidswaarden Bij het implementeren van de negatie- en aggregatie-operatoren merken we op dat logische waarheidswaarden en possibilistische waarheidswaarden eigenlijk eenvoudigere bijzondere gevallen zijn van de uitgebreide possibilistische waarheidswaarden. Wanneer we bij de uitgebreide possibilistische waarheidswaarden µ( ) gelijk houden aan 0, krijgen we de klasse van de possibilistische waarheidswaarden. Wanneer we de possibilistische waarheidswaarden dan nog eens beperken tot µ(t ) {0, 1} µ(f ) 1 µ(t ) krijgen we de klasse van de logische waarheidswaarden. De voorschriften voor de bewerkingen met EPTVs zullen ook werken op PTVs en TVs. Hierdoor kunnen we 50

58 EPTV negatie conjunctie disjunctie Zadeh logische probabilistische Zadeh logische probabilistische Tabel B.2: Geïmplementeerde operatoren het aantal operatoren die we moeten implementeren beperken tot de volgende 7, die telkens EPTVs als argumenten nemen: Daarbij gebruiken we de volgende afkortingen voor de verschillende types aggregatieoperatoren: Zadeh: volgens extensieprincipe van Zadeh logische: op basis van logische(zadeh) t-norm en t-conorm probabilistische: op basis van probabilistische t-norm en t-conorm B.2 Implicatoren Gödel R-implicator De Gödel R-implicator wordt gedefinieerd als: 1 als p q (P Go Q) = q anders Deze functie wordt geïmplementeerd in Visual Basic met als argument twee reële getallen waarbij gecontroleerd wordt of ze tussen 0 en 1 liggen. De bijbehorende coimplicator kan afgeleid worden met de volgende formule: fim(x, co y) = (f im ( x, y)) waarbij als negatieoperator het complement wordt gebruikt ( x = 1 x). Toegepast geeft dit: 51

59 f co Go (x, y) = f Go ( x, y)) = (f Go ((1 x), (1 y)) 1 als y x = (1 y) anders 0 als y x = y anders GödelRimplicator GödelRco-implicator Figuur B.1: 3D plot van Gödel implicator en co-implicator Kleene-Dienes S-implicator De Kleene-Dienes S-implicator is opgebouwd aan de hand van een logische t-conorm en wordt al volgt gedefinieerd: (P K D Q) = (max(1 p, q)) De implicatorfunctie is dan als volgt gedefinieerd: f im (x, y) = u( x, y)) waarbij u de t-conorm is, en de negatie. (i,u, ) is een De Morgan triplet, wat wil zeggen dat (u(x, y)) = i( x, y). De bijbehorende co-implicator wordt dus als volgt gevonden: 52

60 f co K D (x, y) = (f K D ( x, y)) = (f K D (1 x, 1 y)) = (u(1 (1 x), 1 y)) = (u(x, 1 y)) = i(1 x, y) = min(1 x, y) Kleene-DienesSimplicator=max(1-p,q) Kleene-DienesSco-implicator=min(1-x,y) Figuur B.2: 3D plot van Kleene-Dienes implicator en co-implicator Reichenbach S-implicator Net als de Kleene-Dienes implicator, is de Reichenbach implicator een S-implicator, die dit keer opgebouwd wordt aan de hand van een probabilistische t-conorm. Deze implicator wordt als volgt gedefinieerd: (P Rb Q) = (1 p + p q) Met behulp van de bijbehorende t-norm kunnen we als volgt de co-implicator afleiden: 53

61 f co Rb (x, y) = (f Rb ( x, y)) = (f Rb (1 x, 1 y)) = (u(1 (1 x), 1 y)) = (u(x, 1 y)) = i(1 x, y) = (1 x) y ReichenbachSimplicator=(1-p+p*q) ReichenbachSco-implicator=(1-x)*y) Figuur B.3: 3D plot van Reichenbach implicator en co-implicator 54