Interessante werkwijze. Lijkt ook wat op de manier waarop in Spanje gebouwen/panden worden geïmporteerd, nl uiteindelijk met gegenereerde .osm bestanden. Daar worden de handmatige handelingen in een server-side tool met API gedaan. De .osm bestanden worden per gemeente(-polygoon) gegenereerd, en vervolgens in een HOT Task Manager opgenomen met daarnaast net als hier een een handmatige JOSM import/werkwijze, met alleen aantal standaard Plugins (TODO, Building etc) want het oog van de mapper is altijd nodig…
Naar zoiets zouden we hier ook kunnen toewerken en dan bijv op basis Wijk/Buurt polygoon. (Ik denk even hardop).
Andere discussie is of parkeervakken: Landuse of Landcover zijn. Ik beschouw ze (in map5topo) als Landuse, de functie, net als bijv boomgaarden…Landcover is het materiaal, de pure aardbedekking, maar pff ook bij BGT/BRT loopt dit doorelkaar…Dan ben ik weer roepende in de landcover=sand :-). Denk in OSM weer ok, amenity ruikt naar Landuse.
Amenity gebieden zijn functioneel, net als landuse dus, lijkt me. Dan beschouw ik de landuse die foutief gebruikt wordt voor landcover als, nou ja, foutief dus. Een historische vergissing. Parkeervlakken kunnen kunnen over een andere landuse of natural heen liggen, en hebben zelf een surface (of erven die misschien van waar ze op liggen?)
Recent weer eens een stukje Oosterhout bijgewerkt op basis van een BGT import.
Toen wilde ik ook nog de Cingelloop bijwerken m.b.v. BGT maar daar moest het script verder voor worden bijgewerkt nog niet alle waardes in de tabel waren geïmplementeerd en er ging iets fout met python (nieuwe versie/ander dataformaat?) maar dat is ook opgelost.
Verder had ik ook de WTD | Waterdeel laag nodig voor het water. Maar nu zit ik nog met één dingetje, ik mis wat objecten, aangeven met een rode pijl:
Nu vraag ik me af wat het probleem is, de kans is klein (maar niet nul) dat de scripts een fout maken maar waarschijnlijker is het dat ik andere bestanden/lagen moet meenemen.
De waterkant weet ik inmiddels, die zou moeten zitten in Ondersteunend waterdeel (OWT).
De stukken gras langs de weg vindt ik vreemd, voor een eerdere conversie zaten die gewoon in begroeidterreindeel. Zijn de zwarte lijnen in BGT Omtrekgericht hier misschien niet gebaseerd op BegroeidTerreindeel (BTD) maar op Wegdeel (WGD)? Of is dit iets voor verbeterdekaart.nl/? Of … toch een foutje in het script?
Gerelateerde vraag: Is er een BGT detail viewer ergens online? De download viewer geeft niet voldoende detail
Dat is het ondersteunend wegdeel. In dit geval “berm- groenvoorziening”. Ik heb me ook wel eens afgevraagd waarom dat geen “begroeidterreindeel” is maar heb (nog) niet uitgezocht hoe dat precies zit. Ik gebruik een postgis dump van geotoko die eenvoudig met Qgis te visualiseren is. Voor OSM-ers die daar mee willen werken zijn er (zo goed als) gratis mogelijkheden om de postgis dumps te krijgen.
Berm, dat is een onderdeel van landuse=highway, elk onderdeel is een area:highway=*, bij berm is dat area:highway=verge, landcover=grass.
Talud, waar we al eerder een topic over hadden, is onderdeel van de sloot, bij veel water onderlopende, het water normaal dat taggen we als natural=water, de talud kijkend naar de highway is eigenlijk area:water=slope landcover=grass.
Berm begroeiing daar zou men ook area:highway voor kunnen gebruiken als het een afscheiding is. Met de gebruikelijke tags.
Middenberm daar is ook een Engelse term voor, daar kan ik zo niet opkomen.
Hm… als je het echt vergelijkbaar wil hebben dan zou het area:waterway=bank zijn, denk ik?
Slope, als je het hebt over waterstromen, is dacht ik de Engelse term gradiënt waarmee het water daalt. De zijkanten van waters heten banks.
Maar ik ben bang dat zulke tagging niet echt aan gaat slaan.
area:highway slaat ook al niet echt aan.
Ik gebruik het zelf af en toe, voor de centrale eilanden (inclusief de truck apron) van rotondes. Dezelfde rondlopende way geef ik dan tegelijk een barrier=kerb linksom.
Median (US), of central reservation (UK). Dus area:highway=median of area:highway=central_reservation. Ik zou hier voor de eenvoud van =median kiezen.
berm-groenvoorziening, op de Slinge Rotterdam groenvoorziening, Clingellloop Breda berm.
Ik zou wel eens willen zien hoe de bermverdeling is over NL en ja, daar lijkt me BGT - IMGEO - PostGIS Dumps een optie voor, ik ga een aanvraag doen.
Tegelijk denk ik dat de huidige conversie flow m.b.v. ogr2osm best redelijk werkt maar uiteindelijk toch moet worden omgeschreven met een tussenstap in een PostGIS DB om wat spatiële dingen te doen dus een eigen import van de BGT lijkt me ook op z’n plaats.
Mooi dat je een aanvraag doet voor die BGT dump. Dat helpt enorm voor de beeldvorming. Ik ben het met je eens dat goed is om wat spatial hadelingen te verrichten in postgis. Ik ben nu bv bezig om een aantal vlak geometrien te ontdoen van inner polygons die in feite BGT panden zijn. En wegdelen samen te voegen zoal bv voorsorteerstroken die in BGT aparte polygonen vormen. Daarnaast moeten geometrien versimpeld worden omdat het anders een overdaad aan nodes zou opleveren. Ik heb ogr2osm inmiddels ook aan de praat en dat ziet er veelbelovend uit.
Gisteren leerzame video-call met @PeeWee32 waarin hij zijn aanpak presenteerde om vanuit BGTLean tabellen in PostGIS via verschillende SQL bewerkingen, om uiteindelijk met ogr2osm.osm bestanden te genereren en die in JOSM aan te wenden. Uiteraard nog zonder echte “edits”. Ik was onder de indruk! Kende ogr2osm ook niet.
In deze “processing-keten” zijn er vele ontwerp-beslissingen te nemen, ook nog over de stap-volgorde. Meerderen van ons hier zijn hiermee bezig geweest. Ik noem er een paar:
bundelen van BGT vlak tabellen, bijv ‘…terreindeel’ en ‘ondersteunend…deel’
samenvoegen aan elkaar liggende polygonen met zelfde attributen
generaliseren geometrie met behoud topologie
op welk moment van RD naar WGS84?
wat te doen met BGT Panden? Gaten dichten?
BGT attributen naar OSM tags mapping
aanpak relatieve hoogteligging
(BGT Puntobjecten: nog eens niet over gehad, maar zou eenvoudiger zijn: bomen, zendmasten, windturbines etc. ) . En wanneer je .osm bestanden kunt genereren:
welke objecttypen zijn zinvol, bijv alleen Water en Landuse/Landcover?
onderhouden, scripts, docs etc, in bijv een GitHub project, NLExtract bijv?
opdelen, bijv per CBS Buurt, of een (API) service?
werkverdeling, met bijv HOT Taskmanager of misschien MapRoulette?
edit strategie in JOSM (behoud BGT ref id’s!)
Daarnaast een ‘service’ bijv QGIS project voor alle mappers om kennis te maken/in te zien waar BGT inhoudelijk over gaat.
Veel onderwerpen. Vereist m.i. een projectmatige aanpak. We dachten aan een project-groep vanuit OSM-NL, te starten met een of meer video-calls voor degenen die mee willen doen.
