Als je hebt kunnen bevestigen dat de BGT ergens correct is en je vindt de methode van geometrie importeren praktischer dan elk lijntje met de hand overtrekken, dan zie ik er ook geen probleem mee.
1 Like
Ik ben tegen al dat gekopieer. Ik zie in mijn omgeving dat veel gekopieerd wordt en dat vind ik niet iets om trots op te zijn.
Van mij hoeft dat dus niet.
Laatst meegemaakt: iemand had een opmerking op de kaart gezet dat een straatnaam niet klopt. Reactie van een mapper: âals je een probleem hebt met de straatnaam dan ga je maar klagen bij Verbeterdekaart.nl want daar kopiĂ«ren wij de straatnamen vanâ.
Wel heb je ooit 
@Friendly_Ghost als ik per gebied waarvan ik weet dat de BGT correct door een landmeter ingemeten is en de outline van de BGT omtrekgericht met een plug-in kan selecteren in plaats van dat ik het overtrek; dan maak ik daar graag gebruik van. Of je het als mass import zo moet doen; weet ik niet.
@Kogacarlo Als ik zie wat de kwaliteit van OSM in Nederland is vs in bijvoorbeeld Bangaldesh, en als dat mede gebeurt doordat we gebruik maken van werk dat door anderen al gedaan is (BAG/BGT/Mapillary) dan is dat wat mij betreft vooruitgang.
Dat je hierbij nog steeds kritisch moet zijn en dat je als mapper alsnog een kwaliteitsslag kan slaan door lokale survey prima; maar die basis informatie door anderen opgehaald scheelt een hoop extra.
Maar eens dat als daar fouten in gemaakt worden; en dat wordt opgemerkt; dan mag je daar wel netjes mee omgaan.
Dat was ik en dat was een vervolgopmerking op notes ( had dit fout gemeld: changesets) van andere berichtwisselingen met betreffende persoon, dus voorafgaand om uit te zoeken, wat wel correct is. Daarbij is ook gevraagd of het op bordjes staat. De zoektocht is dan een melding naar verbeterdekaart.nl. Waarheidsvinding, anders blijft het in de BGT ook fout staan, dan kan een volgende mapper, dit zo weer aanpassen. Aangegeven dat de betreffende persoon dit ook bij de Gemeente kan navragen, verbeterdekaart, dan krijgt hij ook gelijk persoonlijk antwoord en niet ik. Dat is niet gebeurd, inmiddels heb ik dat laatst zelf gedaan. We zullen het zien.
1 Like
Dat vind ik dus de verkeerde insteek. De BGT kan me wat. Wij zijn OSM, niet BGT. Wij nemen verantwoordelijkheid voor onze kaart en schuiven die niet af naar iemand anders.
De waarheid ligt misschien in het midden en daar hebben we zelfs tags voor, zoals
name=xxx
official_name=yyy
1 Like
@OttoR dank voor uitleg. Denk dat deze situaties geometrisch, iets voor @PeeWee32, te vinden zijn, waar BAG pand polygonen met een BGT vlak-object overlappen en er ârelatievehoogteliggingâ verschillen zijn. Siloâs, dacht ook luifels, etc zitten m.i. in BGT âOverigbouwwerkâ.
We hebben ons nog steeds te houden aan het âGround Truthâ principe, dus als de BGT iets anders zegt dan het naambordje ter plaatse, dan volgen we het naambordje ter plaatse, niet de BGT (al kun je nog wel de official_name tag toevoegen op basis van de BGT).
Maar als je de BGT over de luchtfoto houdt en je kunt zien dat de lijnen van de BGT overeenkomen met wat je met de luchtfoto ziet, dan zie ik er geen probleem in om dat over te nemen. Een nationale massa-import is vast een heel onpraktisch idee, maar de BGT kan ons wel wat dom klik- en sleepwerk besparen.
1 Like
Misschien is het een idee om met 1 niet te ingewikkelde objectsoort te beginnen, kijken hoe je daarmee klik- en sleepwerk kan besparen?
Bijvoorbeeld, als ik een JOSM laag zou hebben met alleen de watervlakken al getagd volgens OSM, dan kan ik in principe voor een niet al te groot gebied een zwik kopiëren naar de OSM-datalaag en met Polygoncutout inplakken. Dat had voor mijn polderwerk wel gescheeld, al had ik dan alsnog best veel moeten bijwerken aan bruggen en foute oevers. En vooraf een heleboel JBF-waterpolygonen weggooien, al kan dat ook achteraf op basis van de JOSM validatie.
2 Likes
Na de boeiende verdere uitleg, gisteravond, ben ik er nog meer van overtuigd dat een grootscheepse import meer problemen zou opleveren dan het oplost. Er zitten aan de meeste BGT-vlakken heel veel haken en ogen, met name omdat je domweg niet geautomatiseerd kan vaststellen of de BGT voor een specifiek vlak beter is dan het bestaande OSM-vlak. Het samenvoegen vereist gewoon gedetailleerde handmatige controle door mappers.
Het risiko van weggooien van zorgvuldig werk van mappers is ook groot. Bijvoorbeeld, stel je slaagt erin 10.000 objecten volautomatisch te importeren en te koppelen met een overall juistheid van 99%, dan nog trap je 100 mappers op de tenen en moet je alles nalopen.
Ik zie wel heel grote voordelen in een JOSM laag waarin alle BGT-objecten zitten, omgezet en samengevoegd in OSM-formaat met OSM-tags. Als mapper kan je dan een selectie maken die je naar de OSM-datalaag kopieert en daar inpast. Je hebt dan zelf de keuze hoe groot je het maakt, of je de bestaande objecten eerst weghaalt en er nieuwe voor in de plaats zet, je kan van tevoren zien of er problemen zijn en of het wel een verbetering is.
2 Likes
In aansluiting hierop (âJOSM Laag met BGT-objectenâ) Zoals ik gisteren in meeting noemde: OSM Spanje heeft een gestructureerd import proces opgezet, weliswaar voor Buildings (" Edificios"), maar de methodiek zou ook voor bijv BGT of andere imports kunnen werken, of in een variant hierop:
- offline/batch voorbewerking, resultaat:
.osmbestand per gemeente met tool CatAtom2Osm, een ETL (Python) vanuit (Atom) Download uit âSpaanse PDOKâ - in een specifieke OSM TaskManager zijn deze
.osmbestanden aanwezig, of je kunt zelf een .osm bestand genereren (Docker) uit de brondata. - mappers bewerken/importeren in JOSM met alleen standaard plugins bijv BuildingsTools en dus genoemde .osm files
Zo begrijp ik het althans, het gehele proces staat in de OSM Wiki beschreven. Een aantal van die import .osm files staan zelfs in GitHub. Ik ga het binnenkort proberen.
Voordelen m.i.:
- voorbewerking via âbatchâ in Open Source project ipv specifieke JOSM Plugin. Updates zijn gemakkelijker snel gemaakt, ipv steeds nieuwe Plugin-versies. Meerdere personen kunnen eraan werken, is goed testbaar.
- via Taskmanager is inzicht hoe de progressie is
- ook mappers buiten NL kunnen ermee aan de slag
Variant is om niet met .osm bestanden te schuiven maar een API om deze te downloaden (te genereren?), bijv op bbox, gemeente/woonplaats . En misschien is een Taskmanager ook wel veel overhead. Maar hopelijk inspireert de Spaanse Aanpak tot verdere ideeën.
1 Like
Ik ben nog steeds tegen het degraderen van mappers tot controleurs der BGT.
Laatst ging hier een hele discussie over bestek, met name over de vork.
Is het een idee om een âvorkâ te maken van OSM, dan kun je de gehele BGT daar in opnemen. Voor mijn part neem je het domein openstreetmap.nl daar voor.
Is zo maar een ideetje.
2 Likes
lijkt mij niet praktisch. Ik voel mezelf nog steeds een leerling machinist. Ik kom zowel in dorpen als in het buitengebied veel tegen dat globaal redelijk en bruikbaar is, maar in detail twijfelachtig. Het kost veel tijd en vooral veel detail-mappers om aan te vullen; hebben we beide onvoldoende. Of je maakt betere tools waarmee een mapper met gezond verstand veel sneller kan werken met de BGT als hulpmiddel; maar LOKAAL werkend.
Ik heb ook grote twijfel over een massale import, maar die JOSM laag van C10 en Just waarmee ik vooruit kan? Prima ben zeer benieuwd naar die test van Just. Zoals Peter E schrijft
Bingo, that nailed it 
1 Like
Inderdaad, zân laag lijkt me het simpelst te implementeren en precies te geven wat mij een goed begin lijkt.
Na het kopiĂ«ren van object van de BGT laag naar de edit laag kan je de nieuwe BGT outline gebruiken voor het bestaande object met behulp van More tools â Replace Geometry (Ctrl+Shift+G) uit utilsplugin2.
- Voor Replace Geometry moet je twee objecten selecteren, Ă©Ă©n nieuw (BGT), Ă©Ă©n bestaand.
- Het vervangt dan de geometry van het bestaande object door die van het nieuwe object
- Het voegt de tags van het nieuwe object aan het oude object toe.
- en gooit dan het nieuwe object weg
3 Likes
Replace Geeometry is zoân handige tool; dat ik telkens verbaasd ben dat het niet tot de standaard van JOSM behoort.
Ik gebruik het ook vaak om niet het bestaande werk van een mapper teniet te doen; terwijl ik vooral de geometrie aanpas omdat PDOK 8 cm / BTG duidelijker is.
Of als ik validatieslagen maak voor Mapathons van HOT; zodat de mapper nog steeds haar/zijn resultaten terug kan zien.
Even snel een nieuwe laag over het beeld (Shift+N), dan met de Buildin Tools plugin of the Mapathoner plugin de huizen correct invoeren, nieuwe laag weer mergen met de bestaande laag en dan replace per gebouw.
1 Like
Rectificatie van bovenstaande in die zin dat het niet letterlijk zo geschreven is. Ik heb een hele zwik berichten samengevat in een zin en tussen aanhalingstekens gezet. Het stond er dus niet letterlijk zo.
Sterker nog, niemand heeft het zo bedoeld. Blij dat je hier even op terugkomt!
Een manier om verschillen tussen BAG en BGT panden te vinden is om van beiden de oppervlakte te berekenen en kijken of verschillen zijn > x%. In BGT ligt BAG ID vast dus een sql join hoeft niet gemaakt te worden met een geo functie. Het betreffende pand valt ook in de selectie. Bij een verschil van 20% oppervlakte zijn er 76000 panden (als ik geen fout maak 
)
Oh nee?
De realiteit is in ieder geval dat mensen naar Verbeterdekaart worden gestuurd zoals hier en hier.
Sinds ik dit topic heb gelezen en dingen aan het bijwerken ben denk ik regelmatig, zou dat niet kunnen door een BGT object te gebruiken in plaats van het bestaande OSM object uit te lijnen of zelf overtekenen van de BGT omtrekgericht.
Mijn doel is om te beginnen was simpel, gewoon Ă©Ă©n OSM object vervangen door de BGT shape.
De eerste stappen heb ik gezet:
- Een BGT GML extract gemaakt via PDOK download viewer voor het gebied waarin ik geĂŻnteresseerd ben
- De BGT_extract.zip uitgepakt
- Dat levert 35 *.gml files op, de 6 grootste:
bgt_wegdeel.gml
bgt_pand.gml
bgt_begroeidterreindeel.gml
bgt_onbegroeidterreindeel.gml
bgt_vegetatieobject.gml
bgt_put.gml
Op basis van de openingspost begroeidterreindeel in QGis geopend, Open Data Source Manager (Ctrl+L) en daar onder Source bgt_begroeidterreindeel.gml als Vector Dataset opgegeven. Na âAddâ en inzoomen levert dat op:
Dat komt prima overeen.
NB: Bij de PDOK download kan je ook ook de download beperken tot begroeidterreindeel alleen.
QGis gebruikt onder water OGR on dingen te lezen, voor de volgende stap:
Commando:
> python3 -m ogr2osm -e 28992 bgt_begroeidterreindeel.gml
Using default translations
Preparing to convert 'bgt_begroeidterreindeel.gml' to 'bgt_begroeidterreindeel.osm'.
Warning 1: Unrecognized geometry type : -2147483648
Unhandled geometry, type 10
<repeated 2170 times>
Unhandled geometry, type 10
Splitting long ways
Writing file header
Writing nodes
Writing ways
Writing relations
Writing file footer
Daarmee krijg ik een .osm file en als ik die in Josm laadt dan zijn redelijk wat objecten daar maar niet het object dat overeen komt het het OSM object dat ik wilde bijwerken. Even gekeken wat dat type 10 is maar dat is type CURVEPOLYGON dus daar ook maar ondersteuning voor toegevoegd. Verder een SimplifyPreserveTopology toegevoegd om â3. Puntdichtheid BGTâ zoals genoemd in de openingspost te verlagen.
Verder op basis de tabel van de openingspost en de waarden die voorbij kwamen een translation subclass aangemaakt, die ook BGT objecten met een âeindRegistratieâ datum verwijderd.
Daarmee krijg je een .osm file:
Ziet er goed uit wat mij betreft.
Wel zie ik nog objecten die in OSM als Ă©Ă©n object horen bestaan regelmatig uit meerdere BGT objecten bijv. de twee rood geselecteerde objecten. Op te lossen met Josm Join overlapping Areas (Shift-J) maar BGT omtrekgericht heeft daar geen last van en die functionaliteit zou ook door het script gedaan moeten worden.
Daarna is het nog steeds te vraag wat een goede Josm werkwijze is. Je kan dat .osm bestand als aparte laag openen maar je wilt zeker niet die objecten zomaar opladen. Kopiëren naar een andere laag kan maar dan blijft wel de shape maar niet de locatie niet behouden.
Wat ik nu heb gedaan is in de nieuwe laag de bestaande OSM data downloaden, dan de objecten vervangen met Replace Geometry en dan de vier bijgewerkte objecten en drie nieuwe objecten geselecteerd en daarna Upload selection, resultaat.
Verre van een makkelijke werkwijze en ik denk te makkelijk om fouten te maken. Ik zou veel liever BGT objecten in de huidige edit laag laden of een object selecteren en dan âreplace by BGT geometryâ uitvoeren.
2 Likes
Lekker bezig
Als je in JOSM wilt plakken in een nieuwe laag en op de zelfde locatie dan kan dat met Ctrl+Alt+V.
1 Like