Binders Full Of TIGER Deserts

The U.S. has binders full of TIGER deserts.

Let me explain. Back in 2007, we imported TIGER/Line data from the U.S. Census into OpenStreetMap. TIGER/Line was and is pretty crappy geodata, never meant to make pretty maps with, let alone do frivolous things like routing. But we did it anyway, because it gave us more or less complete base data for the U.S. to work with. And so we worked. And worked and worked. Fixing spaghetti highways. Reclassifying and arguing about reclassifying. Connecting and disconnecting. And now, four years and change later, we have pretty maps!

Eat that, TIGER! (check it out)

But we don’t all live in Epcot Center (actually, I don’t think any of us do really) and there’s lots of places where we haven’t been taking as good care of the data. Vast expanses of U.S. territory where the majority of the data in OSM is still TIGER as it was imported all those years ago.

The TIGER deserts.

I want those all to go away, but there’s only so many folks mapping here in the U.S., so we may want to prioritize a little bit. So I wanted to look at the TIGER desert phenomenon a little closer. In particular, I wanted to look a the parts of TIGER deserts that cover towns, and even cities. That’s where people actually do live, and that’s where OSM data is most valuable.

So I set out to identify those the only way I know how: using ArcGIS. The thing is: this kind of job has ‘raster analysis’ plastered all over it, and I just don’t know how to do that using FOSS4G tools. So maybe I’ll just explain what I did in ArcGIS, and then you all can chime in with smart comments about how to do this in PostGIS, R, GRASS, QGIS or whatever free software can do this magic. If you don’t care for all that, just scroll to the bottom for the results.

I created a shapefile first with all OSM highways with TIGER tags in Florida using C++ and osmium. (There’s some good example code to get you started if you’re interested.)

Then, with that loaded into ArcMap, I first created a 5km grid with the predominant (in terms of way length) version number as the cell value.

A second grid for the neighborhood way density:

I reclassified the version grid generously – all cells with 1 or 2 a the predominant TIGER way version got true / 1, the rest false / 0. For distinguishing between built-up and boondock cells, a threshold of 1.8 looked good after some tweaking.

And finally some simple map algebra to combine the two variables into the final result grid:

So there we are folks – TIGER deserts and TIGER ghost towns in Florida:

TIGER deserts in Florida

TIGER ghost towns in Florida

Hmm. I hope we can figure out a way to improve this analysis so the situation does not look quite so bleak. GIS does not lie though – these are the 5km cells that have a reasonably high way density and TIGER way versions that are predominantly 1 or 2.

So let me know folks – 1) Is this a good approach for identifying TIGER ghost towns and if not, what is? and 2) how do you do this using FOSS4G tools?

A Look At Stale OpenStreetMap Data

Lazy people go straight here and here. But you’re not that person, are you?

The Wikimania conference is around the corner, and it’s close to home this year – in Washington, DC. DC already has a lot of resident geo geeks and mappers. With all the open, collaborative knowledge minded people in town, there is huge momentum for an OpenStreetMap Mapping Party, and I am excited to help run it! The party is taking place on Sunday, July 15 – the unconference day of Wikimania 2012. (There will  also be lots of other open mapping things going on, do check the program. The entry for the mapping party is kind of sparse, but hey – it’s a mapping party. What more is there to say?)

The question of where to direct the eager mappers quickly arose. In the beginning, that would have been an easy one as the map was without form and void. Nowadays, with the level of maturity of the map and the community OpenStreetMap has reached, it can be a lot harder. DC, with all its past mapping parties, well curated data imports and active mapping community, looks to be handsomely mapped. To pick a good destination for a mapping party requires a look under the hood.

A good indicator for areas that may need some mapping love is data staleness, defined loosely as the amount of time that has passed since someone last touched the data. A neighborhood with lots of stale data may have had one or more active mappers in the past, but they may have moved away or on to other things. While staleness is not a measure of completeness, it can point us at weak areas and neighborhoods in that way.

I did a staleness analysis for a selection of DC nodes and ways. I filtered out the nodes that have tags associated with them, and the ways that are not building outlines. (DC has seen a significant import of building outlines, which would mess up my analysis and the visualization.) And because today was procratination day, I went the extra mile and made the visualization into a web map and put the thing on GitHub. I documented the (pretty straightforward) process step by step on the project wiki, for those who want to roll their own maps, and those interested in doing something useful with OpenStreetMap data other than just making a standard map.

Below are two screenshots – one for DC and another for Amsterdam, another city for which I did the analysis. (A brief explanation of what you see is below the images.) It takes all of 15 minutes from downloading the data to publishing the HTML page, so I could easily do more. But procrastination day is over. Buy me a beer or an Aperol spritz in DC and I’ll see what I can do.

About these screenshots: The top one shows the Mall and surroundings in DC, where we see that the area around the Capitol has not been touched much in the last few years, hence the dark purple color of a lot of the linear features there. The area around the White House on the other hand has received some mapping love lately, with quite a few ways bright green, meaning they have been touched in the last 90 days.

Similar differences in the Amsterdam screenshot below the DC one. The Vondelpark area was updated very recently, while the (arguably much nicer) Rembrandtpark is pale purple – last updates between 1 and 2 years ago.

Note that the individual tagged nodes are not visible in these screenshots. They would clutter up the visualization too much at this scale. In the interactive maps, you could zoom in to see those.

As always, I love to talk about this with you, so share your thoughts, ideas for improvements, and any ol’ comment.

Dataverkenning AppsForNoordHolland: INSPIRE

The Dutch province of Noord Holland and Dutch open data advocates HackDeOverheid are holding an open data app competition, with a coding event happening next week at a very special venue. I was asked to shed some light on the geospatial data sources made available, which is what this post in Dutch is about. More info at the website.

Komende zaterdag vindt aan het andere einde van de wereld – nou ja, voor mij dan – de eerste publieke bijeenkomst code event in het kader van Apps For Noord-Holland plaats. De provincie Noord-Holland en een handvol andere overheden en semi-overheden hebben databronnen opengesteld waarmee we aan de slag kunnen.

Veel van die data is geografisch – de gegevens hebben betrekking op een specifieke plek; een punt, een lijn, een vlak. De wereld van de geodata is een beetje een aparte; als je met geodata wat wil aanvangen moet je een klein beetje weten van de specifieke bestandsformaten en zaken als coordinaatsystemen en projecties. Daar zijn gelukkig uitstekende bronnen voor, waarvan ik er in de loop van deze dataverkenning een paar zal geven.

Kijkend naar de beschikbare databronnen ligt bij de meeste voor de hand wat je kunt verwachten: zwemwaterkwaliteit, bedrijventerreinen, wegwerkzaamheden. Ik neem er in deze verkenning een beetje een obscure uit: INSPIRE. Eerst maar eens proberen om in een paar zinnen uit te leggen wat INSPIRE is. Daarna gaan we naar de data kijken. En passant geef ik wat tips voor (open source) software om het bekijken en verwerken van geodata behapbaar te maken – ook voor niet-GISsers.


In 2007 heeft de Europese Commissie de INSPIRE-richtlijn vastgesteld. Hierin wordt bepaald dat alle lidstaten landsdekkende, actuele data beschikbaar moeten stellen over 34 thema’s, die een breed spectrum beslaan van geografische namen tot geologie. Het doel van INSPIRE is om de beleidsvorming over mileu-gerelateerde thema’s te ondersteunen, maar de gegevens zijn in principe voor iedereen beschikbaar. Niet allemaal tegelijk trouwens; de thema’s die onder Annex I vallen moeten eind volgend jaar beschikbaar zijn, maar de thema’s die onder Annex III vallen uiterlijk pas in 2019. Daar kopen we dus nog even niks voor, maar de lidstaten beginnen al wel met Annex I-thema’s over de brug te komen. Bijvoorbeeld dus Noord-Holland, waar we nu naar aan het kijken zijn.

Kaartservice schmaartservice

Je kunt de data volgens opgave hier bekijken in een interactieve kaartservice. Een beetje geduld is wel gevraagd, ik moest ruim 10 seconden wachten op mijn kaart. Verplaatsen en inzoomen gaat daarna wel wat sneller.

Zo’n kaartservice is geinig om de data even snel te bekijken, maar er zit geen legenda bij en je kunt de data vanaf hier ook niet downloaden of verder gebruiken. Laten we deze webpagina dus maar laten voor wat-ie is en de data downloaden op de datapagina. Ongeduldig? Hier (32MB .zip) is een directe link.

Als we het ZIP-bestand uitpakken krijgen we een brij aan bestanden. Tijd voor een spoedcursus SHAPE – dat is het formaat waarin we deze data geleverd krijgen.


SHAPE-bestanden – formeel ESRI Shape naar de softwarebouwer die het formaat heeft ontworpen als uitwisselingsformaat voor geodata – kunnen door alle GIS-software worden ingelezen. Het is daarmee een universeel uitwisselingsformaat. Met GIS-software bedoel ik dan de software die professionals gebruiken. Google Maps en Google Earth kunnen er niet rechtstreeks wat mee. Dat is meteen ook een van de belangrijkste beperkingen. Tegenwoordig komen formaten als KML en GeoJSON meer in zwang onder de neogeografen. Omzetten is gelukkig niet zo’n probleem, dat zien we straks.

De naam ‘Shape-bestand’ is eigenlijk misleidend. Een ‘Shape-bestand’ bestaat uit minimaal drie bestanden die onlosmakelijk met elkaar zijn verbonden, en nog een stuk of wat optionele bestanden:

  • Data.SHP – hierin zit de eigenlijke geodata: lijnen, punten, vlakken (‘e’en soort per Shape-bestand).
  • Data.DBF – hierin vind je de ‘attributen’, de metadata voor elk object. Voor een bestand met landgebruik zou je hierin bijvoorbeeld een veld ‘type’ kunnen aantreffen met waarden als ‘industrie’, ‘winkels’, ‘wonen’. De attributen worden opgeslagen in het oeroude Dbase-formaat met alle beperkingen (veldnamen maximaal 8 karakters bijvoorbeeld) van dien.
  • Data.SHX – dit bestand is een index op de objecten in het SHP-bestand, vergelijkbaar met een index op een gewone database. Dit bestand zorgt ervoor dat het bevragen van de data efficienter gaat.

Verder is er nog een hele ris optionele bestanden behorend bij ‘een Shape-bestand’ die vooral door specialistische software worden gebruikt. Ik laat die even voor wat ze zijn, behalve eentje die belangrijk is om iets van te begrijpen:

  • Data.PRJ – dit bestandje bevat een zogenaamde projectiestring, waarin wordt gedefinieerd hoe de driedimensionale aarde op een tweedimensionaal vlak wordt geprojecteerd. Er bestaan honderden verschillende projecties en bijbehorende coordinaatstelsels. In Nederland wordt het RD-stelsel gebruikt. Wereldwijd kom je meestal ‘Plate Carree‘ of ‘Spherical Mercator‘ tegen. Het omrekenen tussen projecties is meestal een van de eerste struikelblokken voor mensen die voor het eerst met geografische data werken.

En dan nu de data…

Goed, hehe, zullen we dan nu eindelijk eens naar de data gaan kijken? De eerste vraag is hoe dan. Met Google Earth kun je alvast geen Shape-bestanden openen. Gelukkig biedt de open source-wereld een hele goede oplossing: Quantum GIS, of kortweg Qgis. Dit gratis pakket kan 80% van de dingen die grote dure GIS-pakketten van vele duizenden euroos kunnen. Bij die 80% hoort zeker de functionaliteit die wij nodig hebben. Ik ga een paar dingen laten zien:

  • Qgis downloaden en installeren
  • Data Inladen
  • Classificeren
  • Projectie instellen
  • Exporteren in een bruikbaar formaat

Daarmee zou je genoeg bagage moeten hebben om deze – en ook andere – geodatabronnen te beoordelen en naar je hand te zetten.

Qgis downloaden en installeren

Quantum GIS is er in smaken voor Windows, Mac en Linux. Je kunt de nieuwste versie oppikken van Er is geen automatische update-functionaliteit, dus als je Qgis vaker gaat gebruiken moet je af en toe eens terugkomen voor de nieuwste versie. Mijn ervaring is dat dat wel de moeite waard is.

Installeer Qgis volgens de instructies en starten maar.

Als eerste zie je een leeg scherm. Geen wizard of niks. Je bent meteen in het diepe van een GIS-pakket. Links is ruimte voor de kaartlagen. In een GIS wordt een kaartbeeld altijd opgebouwd uit lagen. Achter elke laag (layer) gaat een dataset schuil. Dat kan een bestand zijn of een database-tabel. Lagen kunnen elkaar overlappen – dat is zelfs heel gebruikelijk. We zullen zo zien hoe dat uitpakt. Laten we maar wat lagen gaan toevoegen.

Data inladen

Een GIS kent twee soorten lagen: raster en vector. Rasterlagen bestaan uit plaatjes; vectorlagen bestaan uit geometrische definities van lijnen, punten en vlakken. Photoshop versus Illustrator. Shape-bestanden zijn altijd vectorlagen. Kies dus uit het menu Layer → Add Vector Layer…

Je kunt meerdere lagen ineens toevoegen, zodat je in een klap alle zestien Shapes uit de INSPIRE-dataset van Noord-Holland op je scherm hebt – wel snel maar visueel wordt het nogal een zootje. Voor nu beginnen we er dus maar eens met eentje: DPDATA_geluid_prov_wegen.shp. Door het glanzende gebrek aan databeschrijvingen moet ik wat aannames doen op basis van de bestandsnaam. Ik denk dat het gaat om geluidscontouren van de provinciale wegen.

De kenner weet dat het hier om Noord-Holland gaat, maar verder zijn we nog niet zo gek veel wijzer. We kunnen een paar eenvoudige trucjes uithalen om iets meer over de data te weten te komen. Ten eerste kan je dubbelklikken op de naam van de laag in de linkerhelft van het scherm. Je krijgt dan een informatievenster met verschillende tabs, waaronder de attribuutvelden en de metadata. Ook kun je afzonderlijke objecten inspecteren; zoek naar het pijltje met ‘i’ in de knoppenbalk bovenaan en selecteer een object in de kaart. Je krijgt een venster met de attributen voor dat veld. Een addertje onder het gras is hier dat je alleen objecten kunt selecteren van de actieve laag – dat is de laag die links geselecteerd is.

Dit is allemaal leuk en aardig, maar bij een grote hoeveelheid data zoals we hier hebben krijg je er met deze tools nog geen gevoel bij. Het al genoemde gebrek aan beschrijvende gegevens bij de data noopt tot wat meer grasduinen in de data. Dat brengt ons bij de volgende stap: wat orde in de chaos aanbrengen.


Laten we eens gek doen en alle lagen ineens inladen. Dat duurt even – althans op mijn laptopje. Eenmaal ingeladen kun je zien dat Qgis alle lagen een willekeurige kleur heeft gegeven. Aangezien lagen elkaar overlappen zie je niet eens alle data, maar het is al een beste soep.

Met de vinkjes naast de lagen kun je individuele lagen zichtbaar en onzichtbaar maken. Je kunt lagen in de lijst ook verslepen naar een hogere of lagere positie; ze worden dan ook in de kaart verder bovenop of onderop getekend. Maar daarmee wordt het alleen maar een anders uitziende chaos. Het toverwoord om daar een einde aan te maken is classificeren!

Classificeren is het afhankelijk maken van de stijl (vulkleur, lijn, arcering) van de waarde van een van de attributen. Stel, je hebt een attribuut ‘hoogte’, dan kun je die laag classificeren zodat lager gelegen gebieden groen ingekleurd worden en hoger gelegen gebieden bruin. Je kunt op twee manieren classificeren: op individuele waarden – nuttig bij beschrijvende attributen, zoals type (denk aan wonen, industrie, winkels), of op intervallen voor numerieke attribuutwaarden zoals hoogte of bevolkingsdichtheid.

De magie schuilt in het venster met lageneigenschappen dat we al eerder tevoorschijn toverden. Hierin vind je de tab ‘Style’, die standaard op ‘Single Symbol’ staat. Als we eens kijken naar de laag met geluidscontouren die we al eerder bij de horens hadden, dan leent die zich uitstekend voor een classificatie in intervallen. Roep de eigenschappen voor die laag op, selecteer de ‘Style’ tab en selecteer ‘Graduated’ in plaats van ‘Single Symbol’. Verander ook de instelling ‘mode’ van ‘Equal Interval’ in ‘Natural Breaks’. Klik nu op ‘Classify’ en de voorgestelde classificatie op basis van de gemaakte instellingen komt tevoorschijn. Als je deze bevestigt wordt ook het kaartbeeld bijgewerkt en zie je een fraai kleurverloop. Zoom eventueel een beetje in om het beter te zien.

Misschien denk je ‘allemaal Spielerei’ – maar dat is het zeker niet! Een goede visualisatie van de data is essentieel om een idee te krijgen van het verhaal dat de data vertelt. Dat verhaal is de basis voor jouw gouden app-idee en heeft bijna altijd een verrassende plotwending. Die ontvouwt zich pas als je wat gaat spelen met de data, combineren, visualiseren. Dat is wat we nu doen. Dit is het resultaat van mijn grasduinsessie van eerder vandaag:

Hier kun je dit resultaat als Qgis-project downloaden. Als je dat bestand kopieert naar je map met INSPIRE-Shape-bestanden en opent in Qgis krijg je als het goed is precies deze visualisatie op je scherm. Als het niet werkt moet je waarschijnlijk paden aanpassen in het projectbestand. Zoek naar dergelijke regels:


Vervang waar nodig. Maar ik denk dat je die tijd beter kunt besteden aan zelf prutten met de data eerlijk gezegd.

Projectie instellen

Goed, terug naar het saaie werk. Als je goed hebt opgelet heb je misschien gezien dat de Shape-bestanden van de provincie Noord-Holland geen .PRJ-bestanden hebben. Foei Provincie! Hoe kunnen we zonder berschrijvende gegevens of .PRJ-bestand nu weten welke projectie de bestanden hebben? Dit is essentiele informatie bij een geodatabestand.

De context en mijn ervaring vertellen me dat de provincie het Nederlandse RD-stelsel heeft gebruikt, maar dat had er best ergens bij mogen staan. We moeten dit nu eerst aan Qgis vertellen, voordat we opdracht kunnen geven om de data naar een andere projectie om te rekenen en te exporteren.

Ook dit gaat in het venster van de laag-eigenschappen – ja, we moeten dit per laag instellen. Dit gaat met de instelling ‘Specify CRS’ in de ‘General’ tab. Stel daar in dat de laag in ‘EPSG:28992 – Amersfoort / RD New’ (sic) is gedefinieerd.

Exporteren in een bruikbaar formaat

Hier gaat het uiteindelijk allemaal om! We willen de data in zo’n formaat dat we er in onze webapplicatie, Android- of iPhone-app wat mee kunnen aanvangen. Mijn geinformeerde gok zegt dat het Shape-formaat niet voldoet, maar bijvoorbeeld KML wel. Laten we dus proberen de data naar dit formaat te exporteren.

Er is nog meer aan de hand: naast het juiste bestandsformaat is ook de juiste projectie essentieel! Als je jezelf geen gedonder op de hals wilt halen later bij het coden van je app – en gedonder met projecties, dat wil je niet – dan zorg je nu voor de juiste projectie van je data. De brave borsten van de provincie hebben keurig de Nederlandse RD-standaard aangehoden voor deze dataset – overigens niet in overeenstemming met de INSPIRE-richtlijn, maar dat vlug terzijde. Wij willen voor onze app graag de Google-standaard Spherical Mercator (of de oude standaard Plate Carree, de procedure is hetzelfde).

Selecteer eerst de laag die je verder wilt gaan gebruiken en vervolgens uit het menu Layer → Save as…

Hier kiezen we een doelbestand, KML als uitvoerformaat, en we specificeren de projectie als ‘Google Mercator’. Gebruik de zoekfunctie – het is een lange lijst met projecties! Geen wonder dat het, ook voor ervaren GISsers, een bron van verwarring blijft.

Druk nu op OK en je KML wordt gebakken!

Open het resultaat in een ander programma – bijvoorbeeld Google Earth – om te testen of het allemaal een beetje klopt:

Let niet op mij – ik moet nog iets instellen met fonts geloof ik. Maar het gaat erom dat de data klopt! Merk op dat de fraaie kleurtjes etc. niet mee zijn gekomen. Dat kan misschien wel maar daar gaat het niet om. Jouw app zal de data misschien helemaal niet willen laten zien, maar bijvoorbeeld gebruiken als onzichtbare drempel terwijl je je met je telefoon door het land verplaatst, of om een waarde te berekenen op basis van je huidige lokatie. En als je wil visualiseren, zal jouw kaartframework daar weer eigen voorzieningen voor hebben.

Mooi werk! We hebben nu KML-data in een projectie waar we allemaal wat aan hebben.


Pfoe. Het is uitgedraaid op een hele GIS-tutorial. Dat was helemaal niet de bedoeling maar wel leuk om te doen! En volgens mij ook nuttig. Met deze skills kun je een heleboel veel voorkomende uitdagingen met geodata te lijf. Veel succes komende zaterdag en daarna met de App-competitie!

Meer informatie

  • Een handleiding voor Qgis vind je hier.
  • Als je eens een projectie moet opzoeken, dan doe je dat op
  • Andere open source GISsen die ik ken zijn GRASS, gvSIG en uDig, maar ik gebruik zelf het liefste Qgis vanwege stabiliteit en toegankelijkheid. Een nog grotere lijst vind je hier.
  • Wil je geodata snel en makkelijk op het web beschikbaar maken? Kijk dan zeker eens naar de OpenGeo Suite. Deze link is naar de gratis Community-editie maar er is ook een Enterprise-editie met support enzo.
  • Over projecties kun je eindeloos lezen. De documentatie van Google Earth bevat een toegankelijk verhaal over projecties en datums (daar hadden we het nog niet eens over gehad…)

Gemeentegrenzen uit OpenStreetMap

OpenStreetMap is de vrije wereldkaart waaraan iedereen kan bijdragen. De geodata is vrij beschikbaar volgens een Creative Commons-licentie. OpenStreetMap (OSM) bevat allang niet meer alleen straten, maar is uitgegroeid tot een veelzijdige repository van vrij beschikbare geodata. Het is alleen nog niet zo makkelijk om er uit te pakken wat je nodig hebt.
Het standaard exportformaat van OpenStreetMap is een eigen XML-formaat. Dit is met allerlei open source tools, die beschikbaar zijn via de OSM-wiki op of de subversion-repository op
Dit artikel illustreert hoe je de actuele Nederlandse gemeentegrenzen uit de live OSM-database haalt en deze importeert in een PostGIS-database.

De database

Het startpunt voor het zoeken naar specifieke informatie in de OSM-database is de Map Features-wikipagina: Deze pagina bevat een overzicht van alle gebruikte ‘tags’ voor objecten in de database. Gemeentegrenzen vallen onder de Administrative Boundaries: Hoewel de op deze pagina bijgehouden tabel met de indeling per land hier niet helemaal specifiek over is – er wordt gesproken van ‘boundaries for cities like Amsterdam but also smaller like Volendam and Lutjebroek’ – vallen de gemeentegrenzen onder admin_level=8. Op dezelfde pagina lezen we dat de modus operandi om administratieve grenzen in OSM te zetten is door gebruik te maken van ‘relations’. (OpenStreetMap kent slechts drie soorten objecten: nodes (punten), ways (lijnen) en relations (relaties tussen groepen van de andere twee types).)


We weten nu dat we alle ‘relations’ van het type ‘admin_level=8’ willen hebben. Er zijn verschillende manieren om een dergelijke abstractie uit de live-database te maken. De ene is een actuele dump van het gewenste gebied downloaden (deze zijn beschikbaar via ) en hieruit vervolgens met de command-line tool ‘osmosis’ ( ) een selectie maken. Een andere manier is om gebruik te maken van de OSM Extended API (OSMXAPI, spreek uit OSM-Zappy, zie ). De volgende URL levert dan de gemeentegrenzen op in OSM XML-formaat:[admin_level=8][bbox=3.35376,50.57484,7.22095,53.51513].


Het resulterende OSM-XML-bestand kun je importeren in een PostGIS-database met behulp van OSM2PGSQL:
Ervan uitgaande dat je al een spatial database hebt met de naam ‘postgis’ gaat het dan als volgt:

> osm2pgsql -H tm-sr -U postgres -W -d postgis gemeentegrenzen_081118.osm

osm2pgsql SVN version 0.55-20081118 $Rev: 10464 $

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Mid: Ram, scale=100

Reading in file: gemeentegrenzen_081118.osm
Processing: Node(110k) Way(2k) Relation(0k)
Node stats: total(110573), max(312315964)
Way stats: total(2579), max(28446793)
Relation stats: total(690), max(51805)

Writing way(0k)

Te zien is dat osm2pgsql vier tabellen aanmaakt (als deze al bestaan dan worden ze default leeggemaakt, let op dus!).
We maken ons even niet druk om spatial indexes en bekijken het resultaat:


Op de site van Cloudmade zijn ook ready-made shapefiles beschikbaar per land. In dit pakket zit ook een administrative shapefile, maar deze is niet goed:


Deze wat langere weg verdient dus nog steeds de voorkeur!
Overigens zijn de Nederlandse OSM-ers (waaronder ondergetekende) ook bezig met het invoegen van andere officiële en niet-officiële indelingen in de database. Denk aan COROP-gebieden, wijken en buurten, EGG-gebieden, politieregio’s, postcodegebieden en bebouwdekomgrenzen.

OpenStreetMap Mapping Party ‘Saendelft’

The Dutch like to live in new, modern homes with a garden front and back. This leaves the country with many a suburban jungle like the one depicted below. This also means steady jobs for surveyors with the commercial mapping companies – and many a free weekend spent mapping for a Dutch OpenStreetMap contributor.

leidsche rijn 1.jpg Continue reading

Turning OpenStreetMap into a WFS

Yesterday we discussed making OpenStreetMap data available as a data source for the Tripod project in which we @ Geodan S&R take part. For that to work, we need the data available as an OGC WFS service. This is a nice opportunity to explore the tool chain needed. In short:

  1. Getting the OpenStreetMap data
  2. Setting up a PostGIS database
  3. Getting the OpenStreetMap tools
  4. Importing the OpenStreetMap data into PostGIS
  5. Setting up deegree

That’s it. Let’s explore the different steps a little further. Continue reading