Archive for the ‘GeoData’ Category

Voorproefje 2

vrijdag, november 11th, 2011
BAG=# select nummeraanduiding.identificatie, openbareruimtenaam as straat,
huisnummer, postcode, brt_2010.gm_naam as gemeente, omschrijvi as provincie,
bu_naam as buurt, wk_naam as wijk
from verblijfsobject, nummeraanduiding, wijk_2010, brt_2010, provincies2003, openbareruimte
where postcode = '2629JD' and huisnummer = 12 and hoofdadres = nummeraanduiding.identificatie
and st_within(geometrie, brt_2010.the_geom) and wijk_2010.wk_code = brt_2010.wk_code
and st_within(geometrie, provincies2003.the_geom) and gerelateerdeopenbareruimte = openbareruimte.identificatie;
  identificatie  |      straat       | huisnummer | postcode | gemeente |  provincie   |            buurt             |      wijk      
-----------------+-------------------+------------+----------+----------+--------------+------------------------------+----------------
 503200000122340 | Molengraaffsingel |         12 | 2629JD   | Delft    | Zuid-Holland | Bedrijventerrein Technopolis | Wijk 29 Ruiven

Je mag uiteraard in de comments raden wat dit zou kunnen worden.

Voorproefje

donderdag, november 10th, 2011
BAG=# SELECT X(ST_Transform(geometrie, 4326)), Y(ST_Transform(geometrie, 4326))
FROM verblijfsobject, nummeraanduiding 
WHERE postcode = '2629JD' and huisnummer = 12 and hoofdadres = nummeraanduiding.identificatie;
        x         |        y         
------------------+------------------
 4.38628456387679 | 51.9934935616238
 4.38628456387679 | 51.9934935616238
(2 rows)

Time: 200.766 ms
BAG=# SELECT X(ST_Transform(geometrie, 4326)), Y(ST_Transform(geometrie, 4326)) 
FROM verblijfsobject, nummeraanduiding 
WHERE postcode = '2629JD' and huisnummer = 14 and hoofdadres = nummeraanduiding.identificatie;
       x        |        y         
----------------+------------------
 4.387109892279 | 51.9937080752974
 4.387109892279 | 51.9937080752974
(2 rows)

Time: 1.878 ms
BAG=# SELECT X(ST_Transform(geometrie, 4326)), Y(ST_Transform(geometrie, 4326)) 
FROM verblijfsobject, nummeraanduiding 
WHERE postcode = '2265CA' and huisnummer = 7 and hoofdadres = nummeraanduiding.identificatie;
        x         |        y        
------------------+-----------------
 4.40486441005266 | 52.089716521293
(1 row)

Time: 52.008 ms

mirror.openstreetmap.nl gebruik hem!

woensdag, november 9th, 2011

Vandaag ben ik uren opzoek geweest naar een bestandje wat ik gewoon op mijn hardeschijf thuis had staan. Een bestandje met een PD licentie, wat toch totaal niet online te vinden was. Mooi is dat. Om dit soort dingen te voorkomen probeer ik alle geodata die is vrij gegeven voor hergebruik altijd als eerste op onze Nederlandse OpenStreetMap mirror te krijgen.

De mirror is te bereiken via http://mirror.openstreetmap.nl/ het heeft gegevens van Rijkswaterstaat, het Kadaster, Provincies. Eigenlijk de data die je soms wel eens in een Nationaal of Provinciaal Georegister tegenkomt, maar waar je het liefste een kopietje van wilt hebben om even mee te spelen in qgis.

Zelf ben ik nu met de BAG bezig. In de BAG zitten woonplaatsen, maar geen wijken en buurten. Die data heeft het CBS wel. In de BAG zitten ook geen provincies. En provincies? Die schijnt niemand te hebben, maar de overheid denkt er wel over na. Bestuurlijke grenzen dus, ook gewoon op de mirror.

Zoals Linus Torvalds het ooit mooi zei:

Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it šŸ˜‰

Wil je ook een bestandje dumpen op de mirror voor hergebruik. Weet je ons op IRC of de mailinglijst wel te vinden šŸ™‚

Durven denken over een gelaagd OSM model

donderdag, mei 26th, 2011

Het moment zal er ooit een keer komen dat OpenStreetMap wisselt van het vertrouwde CC-BY-SA naar een ODbL achtige structuur. Zelfs die structuur gaat nogsteeds uit van het geograbbelton model. Laten we alles importeren (lees: dumpen) in OpenStreetMap, want alleen dan kan iemand er wat mee, toch?

Deze mentaliteit is al jaren achterhaald. Niet omdat iets in OpenStreetMap staat kun je er een kaartje van maken renderen, maar doordat OpenStreetMap de ontwikkeling van render en (webbased) visualisatie heeft gestimuleerd. Ondanks dat OpenStreetMap is begonnen als crowd-sourced verzamelmodel van geografische data zal niemand ontkennen dat anno 2011 veel van de bron data afkomstig is uit officiĆ«le bronnen. Of het nu gaat om landsgrenzen, antennes, sloten en rivieren of volledige bebouwing uit participerende kadastra, je mag er vanuit gaan dat ook die data bij de bron wordt onderhouden. Dat wij met z’n allen deze data kunnen verbeteren waar nodig is prachtig, maar zouden we niet willen participeren om samen met een leverancier te komen tot en betere bron? Onder zijn voorgestelde licentie?

Ik denk dat, dat laatste van cruciaal belang is om crowd-sourced initiatieven niet als Don Quichot tegen commercie en politiek te gaan vechten, maar een level playing field te creƫren waar niemand het gevoel heeft dat hij voor niets werkt en aanpassingen of suggesties serieus worden genomen.

Vandaag heb ik gesproken met een aantal OpenStreetMap insiders of wij de BAG in OpenStreetMap zouden willen hebben. Ik zit zelf niet te wachten dat we alle geometrie inladen, waar ik veel meer op zit te wachten is de mogelijkheid om te zeggen: we hebben een nieuwe bron in een losse tabel, die kunnen we gebruiken om te renderen, en in OpenStreetMap kun je extra data aan die bron linken of aanpassingen doen waarbij de bron in tact blijft en wijzigingen eenvoudig door de eigenaar kunnen worden gevolgd.

Helaas lijkt OpenStreetMap meer een Microsoft strategie te adopteren: embrace and extend. Ik heb niet het idee dat AND ooit wat heeft kunnen doen met wat ze aan ons hebben gedoneerd, terwijl dat best had gekund. Wat kunnen we doen om van een kul discussie als een ‘database licentie model’ voor ‘onze’ data af te stappen en te gaan denken aan hoe we zo veel mogelijk verschillende datasets kunnen combineren tot 1 kaart? Wat voor infrastructuur hebben we daar voor nodig? Hoe verspreiden we dat?

Update:

OpenStreetMap met BAG

OpenStreetMap met BAG (met dank aan: Milo van der Linden)

Omdat je de competitie in de gaten moet houden

woensdag, december 22nd, 2010

Vandaag zat ik weer eens lekker op Google Maps om wat te geocoden, en het viel me opeens op dat er complete straten waren verdwenen. De sloten er niet uit zagen etc. Wat mij nog niet opviel en Peter wel is dat Tilburg nu in het Markermeer ligt en dat die opeens uitgemalen is. Ik zie best toekomst voor Google šŸ™‚ Is weer eens wat anders dan Station Heerlen binnen de stadsgrenzen van Maastricht, wat je op Bing kunt zien.

Bing en 3dShapes

dinsdag, november 30th, 2010

Naar aanleiding van de vrijgave van Bing luchtfoto’s voor OpenStreetMap, waarover eerder deze week is bericht, wil ik namens het 3dShapes importteam graag even stilstaan bij de consequenties voor deze import.

Het is natuurlijk geweldig dat we gebruik kunnen maken van de Bing luchtfoto’s om OSM mee te verrijken! Daar moeten we zeker gebruik van maken. Desondanks zou ik graag enige terughoudendheid willen vragen bij het tracen van landuse features in gebieden waar 3dShapes nog niet is geĆÆmporteerd. Onder landuse worden vlakken verstaan, zoals bos, gras, water, etc. Gebouwen vallen hier niet onder. Ik zal hieronder uitleggen waarom we dit vragen.

Op dit moment zijn we halverwege met de landuse import van de 3dShapes data. We streven ernaar om de import voor volgend voorjaar, wanneer het recreatieseizoen in alle hevigheid zal losbarsten, af te ronden. Dit zal dus naar verwachting in de loop van maart 2011 gebeuren. Tijdens de import moeten we ook een keus maken over wat te doen met de bestaande landuse data. Tot op heden is er vooral sprake van de kwalitatief mindere AND data en de vrij slechte Yahoo luchtfoto’s (als je al het “geluk” had om in een gebied te werken waar ze aanwezig zijn). 3dShapes is hier een duidelijke verbetering. In gevallen waar gebruikers de landuse data aanzienlijk hebben verbeterd en/of veel werk hebben verricht, treden we in contact om te overleggen wat er met zijn data moet gebeuren.

De resolutie van de Bing luchtfoto’s is zodanig goed dat door een ervaren mapper de nauwkeurigheid van de 3dShapes data gehaald kan worden. Juist vanwege de evaluatie en het opschonen van bestaande data is de 3dShapes import een moeizaam proces. Het zou jammer zijn dat er dubbel werk gedaan wordt, of dat het evalueren extra veel werk oplevert, omdat iemand fanatiek landuse heeft zitten overtekenen van Bing.

Ik zou ervoor willen pleiten om het tracen van landuse (dus bossen, gras, water, etc.) data vanaf Bing in een bepaald gebied uit te stellen, totdat de 3dShapes data is geĆÆmporteerd. Dit om de volgende redenen:

  • De ouderdom van 3dShapes data en Bing luchtfoto’s ontloopt elkaar niet veel: het is allebei meerdere jaren oud (zeg 3 tot 6 jaar). Dus actualiteit is geen reden om de voorkeur aan Bing te geven in plaats van 3dShapes.
  • Met de 3dShapes import hebben we een landsdekkende dataset tot onze beschikking. Dit kan nooit gehaald worden met het tracen vanaf Bing. Ons land is groter dan het lijkt šŸ˜‰
  • De 3dShapes data is ook consistent, in de zin van dat dezelfde classificatie voor dezelfde featuretypes wordt gebruikt (behoudens enkele onvolkomenheden in de data). Ook dit is veel lastiger te behalen door individuele gebruikers; ieder met een eigen kijk op de wereld.

Natuurlijk is er meer dan genoeg wat je wel zou kunnen doen, namelijk:

  • Data toevoegen en bewerken in de delen van Nederland waar al wĆ©l 3dShapes is geĆÆmporteerd. De 3dShapes data is natuurlijk niet heilig.
  • Punt- of lijnobjecten toevoegen en bewerken. Deze data zal niet door de import worden vervangen (m.u.v. hooguit het aansluiten van waterlopen, en dan nog in beperkte mate). Bijv. op veel plekken is de originele AND wegendata nog steeds onaangeroerd. Ga eens naar een willekeurige stad, zet de luchtfoto’s aan, en zorg dat de wegen op de juiste plek liggen en beter lopen.
  • Gebouwen toevoegen en bewerken. De import van 3dShapes gebouwen is al geruime tijd geleden afgerond. Alhoewel 3dShapes een mooie dataset is, zou de nauwkeurigheid van met name de gebouwen verbeterd kunnen worden. Dit was niet of nauwelijks mogelijk met de oude Yahoo luchtfoto’s.

Mocht je toch graag met Bing aan de gang willen gaan in een gebied waar nog geen 3dShapes geĆÆmporteerd is, dan is het ook mogelijk om een mailtje te sturen aan user:Ldp of user:fsteggink, om het gebied eerder te laten importeren.

Happy tracing šŸ™‚

De Nederlandse antillen

zondag, oktober 10th, 2010

Ex-antillen, gefeliciteerd!

10 Oktober 2010 (10-10-10) is een historische datum, het is de dag waarop het land “De Nederlandse antillen” ophoudt te bestaan. Vandaag worden St. Maarten en CuraƧao autonome landen binnen het Koninkrijk. Bonaire, St. Eustatius en Saba worden een soort van gemeenten van Nederland. Een soort, want geheel dezelfde rechten en voorzieningen zijn niet voor ze weggelegd.

Als Nederlandse OpenStreetMap gemeenschap ligt onze focus geografisch op dat kleine stukje land dat ligt ingesloten tussen de Noordzee, Duitsland en Belgie, toch zijn veel Nederlanders verbonden met de (voormalige) Nederlandse antillen. Ik ben al een paar jaar enthousiast bezig om Aruba in OpenStreetMap te krijgen. Ik ben heel benieuwd of er op de andere eilanden ook mensen actief zijn en zoek hulp en geodata.

Aruba

Ik ben al een aantal jaren actief met het in kaart brengen van Aruba. Twee jaar geleden ontving ik geodata uit 2005, ontstaan uit Ā CAD-tekeningen. De geodata was opgebouwd in kaartbladen en kent enkel lijnwerk.

De data is verouderd. Ook zijn de lijnen niet overal netjes aangesloten. Geautomatiseerd importeren zoals met de 3DShapes is gebeurd is dus geen optie. Daarnaast bevat de geodata geen namen en is het dus niet mogelijk om de straten en paden van de juiste benaming te voorzien als je niet zelf op Aruba bent geweest, of op Aruba woont. Wat ik in ieder geval heb gedaan is de geodata van Aruba via een WMS server beschikbaar maken. De WMS server draait op mijn dogomaps domein. Er is een eenvoudige demo beschikbaar.

De WMS service gebruiken vanuit je editor

Voor Merkaartor kun je een WMS adapter aanmaken:

http://www.dogomaps.net/geoserver/wms?

Als je bovenstaande url gebruikt, dan zoekt en vind Merkaartor zelf de lagen. Je kunt het beste de laag Aruba kiezen, hierin zijn alle andere lagen opgenomen.

In JOSM kun je als Service URL opgeven:

http://www.dogomaps.net:80/geoserver/wms?SERVICE=WMS&FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=aruba& .

De WMS url voor het ophalen van de GetCapabilities is:

http://www.dogomaps.net/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities

Ik hoop dat dit initiatief anderen overhaalt mee te helpen met het verbeteren van de OpenStreetMap kaart voor Aruba! En hopelijk geeft het een goed voorbeeld voor de andere ex-antillen.

In ieder geval wil ik alle mensen op de eilanden feliciteren met de nieuw verworven vrijheid! Ik wens iedereen een fantastisch feest en een mooie toekomst.


Recreatieschap Achterhoek Liemers geeft data vrij voor OpenStreetMap!

donderdag, oktober 7th, 2010

Vandaag heeft het Recreatieschap Achterhoek-LiemersĀ de data aan de OpenStreetMap community vrij gegeven welke op recreatieschap.nl en op routenetwerk.nl te vinden is. Hier zijn alle routes in de Achterhoek en Liemers te vinden. Verder is er onder andere informatie te vinden over Recreatie gebieden en de startpunten van de routes.

Deze data wordt op deze sites continue up-to-date gehouden en wij zijn vrij om deze updates te verwerken in OpenStreetMap. Dus medemappers, we kunnen aan de slag met deze mooie routes!

Bedankt Recreatieschap Achterhoek-Liemers!

Onderweg.nl op OpenStreetMap

woensdag, september 22nd, 2010

De nieuwe site van Locatienet BV, onderweg.nl maakt gebruik van OpenStreetMap. Het combineert data uit het NDW als WMS overlay op een versimpelde achtergrondkaart.

Locatienet is (net als ieder ander slim commerciƫel bedrijf) benieuwd naar suggesties wat nog meer gedaan kan worden met de data. In een telefoongesprek gisteren werd ook nog een leuk feitje weggegeven.

De meetlussen komen in X/Y binnen, en moeten dus gekoppeld worden aan wegsegmenten. Momenteel wordt daarvoor een uittreksel van het Nationale Wegenbestand (NWB) gebruikt. Dat bestand is sterk verouderd, en het is dus bijvoorbeeld rond Eindhoven onbruikbaar. OpenStreetMap is veel recenter en dus geschikter, het idee is dan ook om de segmenten van OpenStreetMap te gaan koppelen aan de meetlussen.

3dShapes voortgang

zaterdag, augustus 21st, 2010

Effe een update over de 3dShapes landuse/water import. Het kan je vast niet ontgaan zijn dat deze data in delen van Nederland wordt geĆÆmporteerd. Afgelopen week heb ik de import rond Utrecht afgerond (n.a.v. de mapping party). Ik ga binnenkort verder met de import van landuse/water data tussen Utrecht en de Veluwe, gevisualiseerd in onderstaand kaartje:

Natuurlijk is het niet de bedoeling dat deze import zonder feedback plaatsvindt, dus ik zou graag willen horen (als reactie onder deze post of op het forum) of er landuse / water is waar ik rekening mee moet houden. Wegen, fietspaden, e.d. blijven sowieso ongewijzigd, omdat het lijnendata is. Vlakken die oorspronkelijk met de AND import zijn meegekomen, zullen in het algemeen worden verwijderd, maar met behoud van informatie. Als het vlak een naam heeft, zal ik er een toponym-tag aan toekennen, zodat de naam op de kaart zichtbaar blijft.

Verder heeft Ldp weer de import van 3dShapes in Zeeuws Vlaanderen opgepakt, en ook Rullzer en Theun zijn bezig.