Is het iemand al gelukt om die GML bestanden van de top10 om te zetten naar een ander formaat zoals bijvoorbeeld een shapefile?
Ik heb even zitten spelen met ogr2ogr (www.gdal.org), voor sommige ‘lagen’ in de GML lukt het me, zoals gebouwen en het terrein (landgebruik). Die krijg je er alsvolgt uit:
ogr2ogr -sql “SELECT * FROM Gebouw” 40_west_gebouw.shp 40_west.gml
Maar voor bijvoorbeeld de wegdelen lukt het me niet, dit komt volgens mij omdat deze uit een meervoudigegeometrie bestaan (zowel punten, vlakken en lijnen).
Rutje, kijk hier eens:
http://lists.osgeo.org/pipermail/dutch/2012-January/000293.html
Je hebt minimaal versie 1.8 nodig van OGR.
Frank
fsteggink,
Bedankt voor je reactie. Ik gebruik de nieuwste versie van OGR, dus daar zit het probleem niet in. Ik heb weinig ervaring met PostGIS, dus dat probeerde ik eigenlijk te vermijden.
Als ik, zoals uitgelegd in die mailinglist, de GML data importeer in een PostGIS database zit ik volgens mij nog steeds met hetzelfde probleem met betrekking tot het maken van een shapefile.
Het commando struikelt nog steeds over de meervoudige geometrie.
ogr2ogr -f “ESRI Shapefile” 01_oost_wegdeel.shp -sql “SELECT * FROM Wegdeel” PG:“dbname=‘top10’ host=‘localhost’ port=‘5432’ user=‘postgres’ password=‘****’”
Ik vraag me ook af of de stap via PostGIS echt noodzakelijk is.
Met OGR lukt het me overigens inmiddels wel om een specifieke geometrie te selecteren. Kijken welke geometrieen er in een gml zitten kan met:
ogrinfo -ro 01_oost.gml -sql “SELECT DISTINCT ogr_geometry from wegdeel”
Daarop filteren zou dan moeten kunnen met:
ogr2ogr -sql “SELECT * FROM Wegdeel WHERE ogr_geometry=‘POLYGON’” 01_oost_wegdeel_polygon.shp 01_oost.gml
Dit geeft echter een foutmelding:
“Can’t create fields of type StringList on shapefile layers”
Door het toevoegen “-splitlistfields” zou je een StringList moeten kunnen op delen naar individuele strings. Als ik dat doe draait ogr2ogr zonder foutmeldingen, maar krijg ik een compleet lege Shapefile.
Edit:
Zelfs wanneer je alle attributen weglaat (dus “SELECT FID” ipv “SELECT *”) resulteert het zonder foutmeldingen in een lege shapefile, die StringLists hebben daar dan weinig mee te maken lijkt me.
Is dit uiteindelijk niet tegelijk het einde van het mappen?
Als men er straks in slaagt om de kadasterkaart om de zetten in de openstreetmapkaart staat alles erop. Niets dat zo gedetailleerde beschrijving van nederland als het kadaster lijkt me?
Die gedachte was er ook na de import van de AND data. Blijkt dat er toch altijd weer iets nieuws is om te mappen.
Indoormapping bijvoorbeeld: http://opengeodata.org/openstreetmap-and-indoor-maps-part-22-the-map
Het kadaster heeft geen fiets- en wandelroutes, om maar eens wat te noemen.
Met de kaart van het kadaster zou het gemakkelijker moeten zijn om informatie toe te voegen op plekken waar geen mapper bezig is.
Ook is de informatie behoorlijk oud mbv paden in de bossen en stukken bos die omgezet zijn in open stukken.
Het is vergelijkbaar met de 3dshapes.
Het lijkt erop dat dit soort informatie amper wordt bijgehouden.
Ben het met je eens dat er altijd wel wat te mappen valt, maar wij waren het op de borrel gister in Utrecht ook wel eens (dacht ik) dat de AND import veel actieve mappers heeft ‘weggejaagd’. Aan de andere kant hadden we wel ineens jaren eerder een bruikbare kaart in NL, dat is ook wat waard.
Aangezien ik pas sinds vorig jaar iets met openstreetmap doe, kan ik hier niets over zeggen.
Wel dat de 3dshapes toevoeging (en de garmin openfietsmap) voor mij de aanleiding waren om mijn omgeving in kaart te brengen.
Als ik met een ‘leeg vel’ had moeten beginnen, was ik hier nooit mee aan de gang gegaan.
Het plan was om de wandelroutes in te voeren, maar het is ‘iets’ uit de hand gelopen omdat de onverharde paden/wegen vrijwel afwezig waren bij de gelopen routes.
Nu heb ik sinds dit weekend een gecombineerde wegen+topo kaart op de garmin gps met alle gemarkeerde wandelroutes.
En bij mij in de omgeving staan de bospaden er allemaal op en zijn de niet aanwezige paden ook weg op de kaart.
Want er zijn mensen (zoals ik) die OSM juist interessant vinden omdat er al een behoorlijk kaart is. Ik had een kaart nodig voor een langafstand wandelpad, ontdekte dat ik zelf dingen moest invoeren (ontbrekende fiets- en wandelpaden). En van het een komt het ander … . Ik ben er dus nog.
Dezelfde geldt voor de 3dShapes import: ik wilde al een tijd meer informatie op de kaarten die we gebruiken voor het wandelpad want voor wandelroutes is het erg handig om gebouwen e.d. als herkenningspunten te gebruiken. Maar ik zag geen mogelijkheid dat zelf te doen (boeren zijn niet erg gesteld op mensen die hun velden gaan nameten met een GPS). Uitstekende import wat mij betreft.
Er is nu eenmaal veel meer te doen dan dat we aankunnen.
Edit: Ha, JanWandelaar was me voor!
Misschien was mijn vorige post niet helemaal volledig. Ik ben me zeer bewust dat er verschillende types mappers zijn. De één mapt graag daar waar nog vuurspuwende draken leven en de ander wil graag de bewoonde wereld verbeteren, of beide natuurlijk.
Begrijp ik. Ik neem aan dat je ook genuanceerd hierover denkt. Een nieuwe wijk vlakbij was bijna geheel afwezig in OSM voordat ik er aan begon. Het geeft zeker een kick om dat in OSM te zien renderen. Maar het is ook leuk om de kleine reparaties te doen: er is echt nog genoeg te doen.
Er zijn mensen met een grote staat van dienst binnen OSM die imports en dergelijke acties resoluut afwijzen (b.v. op de lijsten talk, osmf, legal) wegens de veronderstelde negatieve effecten op ‘mappers’. Ik wilde alleen aangeven dat het niet waar hoeft te zijn dat het zo negatief uitwerkt. De tot nu toe aangedragen ‘argumenten’ zijn gewoon niet bewezen.
Ik map zelf alleen op basis van wat ik met eigen ogen heb gezien en vastgelegd (dat geeft nogal wat last, nu we bezig zijn met de ‘grote reparatie’).
Even voor de duidelijkheid voordat ik verkeerd begrepen wordt, ik ben ooit gaan mappen omdat ik me er aan kon irriteren als dingen op een kaart niet klopte of ontbraken en je er niets aan kon doen. Ik ben dan ook voorstander van de meest accurate kaart, en met een kadaster import wordt de kaart beter dus daar ben ik natuurlijk voor. Ik vroeg me alleen af wat er dan nog over bleef, maar al wordt de niet bestaande perfecte kaart van nederland gecreeerd dan ben ik voor want dat is uiteindelijk het doel.
Wat is de verwachting, dat deze data in OSM geimplementeerd is.
Waarbij de huidige ingetekende wegen/paden met hun specifieke tags blijven bestaan.
Ik kijk dan vooral naar de tracks en path uit TopoNL.
Is het verstandig tot die tijd geen wegen paden meer in te tekenen?
Ik zag op wikipedia toevallig deze kaart staan:
http://nl.wikipedia.org/wiki/Bestand:Helmond-topografie.jpg
Het is dus mogelijk de data om te zetten.
Het lijkt mij het beste als implementatie door de lokale mappers gebeurd die de situatie het beste kennen (ook met betrekking tot overzetting tags ed)
Daarvoor zou de data kunnen worden overgezet in een makkelijk te gebruiken formaat. Probleem is vrees ik dat veel mensen geen idee hebben hoe waaronder ik niet.
Is het niet handig om een instructie te maken hoe je deze kadaster data implementeert in osm?
Misschien ga ik ietwat te snel, daarom een algemenere vraag, hoe ver is men hiermee, gaat er nog iets met deze data gebeuren. Wie weet hier meer van?
EDIT: Misschien heb ik toch niet zo’n haast meer met implimentatie, zie opeens dat helmond zuid in februari en helmond-noord in april wordt geupdate: http://www.kadaster.nl/pdf/zakelijk/BRT_Leveringskalender_TOP10NL_februari_2012.pdf http://www.kadaster.nl/pdf/zakelijk/BRT_Leveringskalender_TOP10NL_april_2012.pdf En zou daar toch even op wachten, desalnietemin zou ik graag weten wat de laatste ontwikkelingen zijn. Wie weet er meer van?
Die kaart is door Jan Willem van Aalst gemaakt. Hij heeft van veel meer Nederlandse steden soortgelijke kaarten gemaakt. Zie hier voor een overzicht. Hierbij is gebruik gemaakt van het NLExtract project. Dit is ervoor bedoeld om de BRT (Top10NL), BAG (basisregistratie adressen en gebouwen) en data uit toekomstige basisregistraties gemakkelijker om te zetten naar een formaat dat gemakkelijker elders gebruikt kan worden.
In theorie is het altijd mogelijk data te converteren en in OSM te uploaden. De vraag is of je dat ook wilt / moet. Want wie neemt de verantwoordelijkheid hiervoor op zich? En kunnen degenen die zich wagen aan het op deze manier verversen van de kaart dit wel aan? En wie controleert dit? Kortom, vele haken en ogen die mij er niet bepaald toe aanzetten om na te denken over een concrete oplossing.
Ik zie het dus niet zitten om met een gecentraliseerde oplossing op de proppen te komen. Daarvoor is de hoeveelheid data te groot. Misschien komt er “vanzelf” een oplossing. Een lokale mapper verzint iets slims wat goed werkt en vervolgens aanslaat. Dit wordt dan door anderen opgepakt en verder uitgebreid. Zoiets moet groeien.
Aan de andere kant moet je je afvragen of je dat wilt. Als je koste wat kost OSM wil synchroniseren met de BRT, wat is dan de unieke, toegevoegde waarde van OSM? Dan kun je net zo goed alle landuse wegmikken uit OSM. Wordt de Benelux-dump gelijk een stuk kleiner 
Tenslotte heeft de Top10NL een CC-BY licentie. Er is nog een discussie gaande of de OSM-attribution voldoende is, aangezien in OSM geen garantie is dat tags (zoals de source-tag) blijven bestaan.
@Allroads: deze discussie moet je er zeker niet van weerhouden om nieuwe wegen, wijzigingen, etc. in OSM aan te brengen. Ga gewoon door! In de Kadaster-data zit ook niet alles. Verder is het ook qua nauwkeurigheid ook niet beter dan OSM. Dat zal ook niet gebeuren. (Over een paar jaar zal een andere basisregistratie in de lucht zijn. Dit is de BGT, de Basisregistratie Grootschalige Topografie. Ik denk niet dat deze heel snel als open data beschikbaar zal zijn, o.a. vanwege de torenhoge investering die meespeelt. Maar wie weet…)
Frank
Ik weet niet of ik het hier helemaal mee eens ben.
Hoe dan ook zou het niet mogelijk zijn om een achtergrond kaart op basis van het kadaster zoals dat bij de bing fotos het geval is in te laden of bijvoorbeeld een systeem waarbij je de data in blokjes van bijvoorbeeld een halve kilometer bij een halve kilometer inlaad in josm en schapes dan kunt overnemen of weggooien, zeer lokaal.
Het punt is dat als een mapper die data wil gebruiken, 99% van de mappers niet weet hoe en dat is toch zonde.
Het is prachtig om allerlei technische hulpmiddelen te gebruiken, maar het is de bedoeling om te mappen wat we in werkelijkheid waarnemen. Zo heb ik in mijn woonplaats diverse fiets- en voetpaden gemapt. Laatst keek ik op de kaart en was er een fietspad veranderd in een voetpad op basis van Bing foto’s. Toen ik naar het bewuste pad fietste, zag er een bord fietspad en geen voetpad. Dus heb ik het weer veranderd. Een ander voorbeeld is een script waarmee sommige mensen werken en dan doodleuk de knooppunten gaan verplaatsen zonder de werkelijkheid te kennen.