Een beetje GIS voor iedereen

Sinds Google Maps weet iedereen waar je het over hebt: gegevens op een kaart zetten is waardevoller dan ze weergeven in een tabel. Uitslagen van onze parlements- verkiezingen zouden niet half zo overzichtelijk zijn zonder de kleurkaartjes van ons stemmende Nederland. Interactieve kaarten, gekoppeld aan (web-) applicaties of databases, zijn Geografische Informatie Systemen (GIS). Maar wat (en wie) heb je nodig om een GIS te bouwen? Met deze vraag werden wij (Aran en ik) geconfronteerd toen we ons eerste GIS wilden bouwen. In dit artikel delen we onze inzichten. In het vervolgartikel laten we zien hoe je zelf een eenvoudige GIS maakt met Google Maps.

Een beetje GIS

De verzamelnaam GIS dekt een karrenvracht aan toepassingen: je kunt op een klikbare kaart weergeven waar aardbevingenplaats vinden, waar criminaliteit is, of waar je zand- en grindbodems vindt in Nederland. Als het informatie is die een geografische inslag heeft werkt een GIS-aanpak beter dan een tabelletje.

Maar -voor dit blog interessanter- er is een breed aanbod van technologieën om je GIS mee te bouwen. Binnen dit aanbod is ESRI van oudsher toonaangevend, maar omdat Google de drempel verlaagt om te ‘beginnen met GIS’, begint dat landschap te veranderen…

Een fijne introductie tot de concepten van GIS, wat het is en waaruit het bestaat, is Wikipedia NL: GIS. ( Gelukkig hoef je niet alles daarvan te onthouden om de rest van dit artikel te begrijpen. )

Is er meer dan Google Maps dan?

Ja! Er bestaat een stabiel aanbod van GIS-tooling en GIS-kaartdataleveranciers. Doordat Google zowel de tools als de data levert heb je misschien niet door dat er een onderscheid is! Tooling komt sinds jaar en dag van ESRI en MapInfo. Datasets om op je kaart te zetten koop je en die komen bijna overal vandaan: generieke data (wegen, bevolking, landbouwgrond, satelietfoto’s) enerzijds, maar ook specialistische data (percelen, geologie, McDonald’s-filiaallocaties) anderzijds.

Het bestaansrecht van ESRI en concullega’s is evident: die tools kunnen veel meer dan je met Google Maps kunt en ze bestaan al veel langer. ESRI kan bijvoorbeeld kaartlagen willekeurig combineren en het resultaat met boekdrukkwaliteit exporteren. Er zit ook een bak libraries bij waarmee je op iedere denkbare manier een kaart manipuleert.

Wij wilden een GIS bouwen en -zonder in te gaan op wat dat moet doen- initieel was het voor ons duidelijk: als we GIS gaan doen, pakken we dus de powertools van ESRI. Maar toen…

Tegenvallers

Van de gevestigde spelers (met name: ESRI) verwacht je kwaliteit. ESRI geeft toe dat hun tooling een behoorlijke leercurve eist. Collega Aran heeft er 3 maanden fulltime aan besteed en begon toen de fijne kneepjes op te pikken. Er bleek dat vanzelfsprekende features niet voorzien zijn.

Je kunt de kaart in een ESRI-webapplicatie niet automatisch laten centreren en zoomen rondom een point-of-interest (plek op de wereld). Dat is lastig, want dan moet een gebruiker dus weten waar het op de kaart ligt en zelf zoomen en schuiven tot hij het vindt. Volgens ESRI is dit euvel opgelost in de komende versie (9.3), maar ze hebben dus minstens 12 versies verbruikt om er achter te komen dat dit essentieel is!

Er zijn nog meer tegenvallers:

  • Selectie tools (zoom, pan, selecteer een vlakje) zitten in de web-interface achter menuutjes en kosten teveel muiskliks om ze comfortabel te besturen
  • Java is een ondergeschoven kindje. ESRI gokte op Microsoft .NET, dus de Java tooling komt altijd een stap later, is minder stabiel en (vooral) gebrekkig gedocumenteerd.
  • De architectuur is een strict gestructureerde, maar dan wel 400 lagen diep (zucht).

Verschillen met Google

Voor ons project hebben we uiteindelijk gekozen voor Google Maps, de tegenvallers hierboven speelden een belangrijke rol in die beslissing. Google Maps is in bepaalde opzichten ‘anders’ dan de rest.

Google is een service

Het is een Javascript/HTML gebaseerde dienst die (grofweg) een plaatje met wat javascript voor je levert. ESRI en concullega’s leveren je een schaalbare server-applicatie en een DBMS, alsmede stand-alone clients voor de PC. De ESRI-tools kunnen overweg met zo’n beetje alle kaartdata, Google Maps API accepteert alleen haar eigen formaat.

Google is niet alleen een tool, maar de service omvat ook kaartdata (satelliet, wegen) en een zogenaamde Geocoder; die service converteert een huisadres naar lengtegraad-/breedtegraadcoördinaten die je kunt visualiseren (meer uitleg over geocoding). En omdat het Google is, hoef je je geen zorgen te maken over bereikbaarheid of schaalbaarheid - hoe populair je site ook.

Google beperkt de ‘customization’ van kaartinteractie, want de kaartinteractie is op basis van de javascripts die zij voor je genereren. De bestaande interactietools zijn simpel en razendsnel vergeleken bij server-based ESRI-tools. Dat is trouwens geen oneerlijke vergelijking: javascript is browser-local en daardoor veel sneller, maar dat krijg je bijna niet voor elkaar met ESRI-tools.

ESRI is een toolbox

Het belangrijkste probleem is dat een toolbox een paar essentiele dingen mist: een geocoder bijvoorbeeld. Die moet je eerst kopen (kaartdata van adressen en lokaties) of als webservice abonnement kopen (kosten per query).

Dus nu blijkt eigenlijk dat ESRI en Google allebei tekortkomingen hebben. Wat bepaalde dan onze keuze?

Creatief omgaan met Google Maps API

De wereld staat niet stil. Meerdere programmeurs ondervinden de mogelijkheden van Google Maps, maar lopen ook al snel tegen de beperkingen aan. Steeds meer open source ‘hacks’ om daar omheen te komen verschijnen dus en Google lijkt die niet tegen te werken.

Een mooi voorbeeld is GeoServer, een open source kaartserver die je bijvoorbeeld ‘bovenop’ de kaart van Google legt. Dit geeft krachtige mogelijkheden, zonder merkbaar snelheidsverlies. Een ander project, OpenLayers, lijkt meer op Google Maps zelf.

Al met al dus genoeg ontwikkeling in het Google-kamp en stilte in het ESRI-kamp.

Open source kaartdata

Maar de vraag blijft: hoe kom je aan je kaartdata? Dat hangt natuurlijk af van wat je GIS moet tonen. Voor straatadressen kun je met Google toe. Steeds meer overheidsinstanties en hobbyclubjes openbaren andere GIS-kaartdata met een open source-licentie. Dat schept ongekende mogelijkheden.

Conclusie

Wij gingen voor Google Maps vanwege ontwikkelgemak, stabiliteit en gebruiksgemak. Ingewikkelde dingen kunnen niet met Google Maps en vereisen ESRI (e.d.), maar er is weinig dat je niet toch al met een open source ‘uitbreiding’ op Google Maps kunt doen. Als je werkt met .NET liggen de zaken omgekeerd, maar Finalist is van het Java gebeuren.

Volgende keer laat Aran zien hoe je je eigen GIS applicatie bouwt die foto’s van je vakantiereis koppelt aan de route op de kaart.


2 reacties »

  1. met betrekking tot het stukje “Creatief omgaan met Google Maps API”: een pakket als Geoserver levert geen “hack” op Google Maps. Wat Geoserver doet is plaatjes leveren van een bepaald stuk van de wereld, op een bepaald zoomniveau. Google biedt uitgebreide mogelijkheden om deze 3rd party plaatjes te combineren met een Google Maps (of andere) onderlaag. Geen hack, maar gewoon by design. Je kan zelfs de hele Google-kaart gewoon weglaten en vervangen door iets anders, een andere wereld of zelfs een panorama ofzo.

    Als laatste is ook OpenLayers geen hack op Google Maps, het is een alternatief, net als Yahoo Maps. OpenLayers heeft als voordeel dat het opensource is, terwijl Google Maps dat niet (echt) is. Toch heeft Google Maps van de drie de meest uitgebreide, nette en best gedocumenteerde API, iets wat in een flinke JS omgeving toch wel essentieel is.

    Rikkert - maart 11, 2008 14:28

  2. Op A List Apart verscheen vandaag een - naar mijn idee - interessant artikel over mapping op websites:

    http://alistapart.com/articles/takecontrolofyourmaps

    Marcel de Graaf - april 8, 2008 20:23

Reageer

RSS feed for comments on this post · TrackBack URI