Geometrie van BAG-import lijkt niet te kloppen?

Ik ben een beginneling met OSM. Wat is de goede aanpak bij het volgende?

Over deze locatie: OpenStreetMap

De geometrie van de gebouwen, de perrons en de perkjes op het station lijkt helemaal niet te kloppen. Is het wenselijk dat ik dat herstel, of rij ik dan een project in de wielen? En als er zo’n project is, hoe kan ik dat vinden?

Zo te zien komen die gegevens uit een BAG-import. Je ziet hier een soort parallellepipidums, terwijl dat in werkelijkheid rechthoeken moeten zijn.

De plattegrond van de gebouwen is uit elkaar getrokken, de zuidelijke gevel klopt aardig, de noordelijke gevel is vertikaal omhoog en naar rechts getrokken.

Ik gebruik Vespucci voor edits onderweg. Bij de eigenschappen van nodes zie ik allerlei informatie over treinnummers en zo. Die heb ik niet uitputtend gecontroleerd, maar het lijkt verouderde informatie.

In Organic Maps zie ik die vervorming niet:

De vraag is dus of ik hier iets te herstellen is.

Voor zover ik weet heb ik dat uit elkaar trekken niet zelf gedaan. Maar ik ben nieuw met Vespucci en OSM, dus ik sluit het ook niet uit. Ik zie het nergens terug, en ik weet dus ook niet hoe ik het ongedaan kan maken.

In dit topic zie ik dat BAG-imports niet perfect zijn. Maar in het BAG zelf klopt de vorm van het stationsgebouw vrij aardig. Dus zie je op die site andere coordinaten dan in de export/import?

Een hoop vragen.

Hoi RuleVR en welkom op het forum

Het lijkt fout te zijn gegaan in changeset 176675233

Ik denk dat het het beste is om het even terug te draaien en de correcte wijzigingen los toe te voegen.

Ik ben zelf niet zo bekend met Vespucci maar we zien vaker ongewenste verschuivingen ook bij andere editors zoals ID. JOSM heeft meer ingebouwde beveiliging om dit tegen te gaan.

1 Like

Inderdaad is changeset 176675233 de boosdoener.

Ik heb die changeset reverted en de vijf camera’s weer teruggezet.
Misschien kun je nog even controleren of die weer op de juiste positie staan ?

De trein serie nummers staan op de routerelaties en niet op de nodes.
Op de nodes die je waarschijnlijk bedoelt staan bijvoorbeeld de nummers van de seinen.
Zo staan aan het W einde van het perron de seinen 902 en 904.

Veel succes met verder mappen.

1 Like

Bedankt! De camera’s kloppen inderdaad. Ik zie nu ook waar het fout moet zijn gegaan. Die witte vlekjes zijn 2 camera’s op een paal op het perron, bij de wc’s. Je ziet de schaduw van de paal. Die camera’s wilde ik erin zetten…

…maar dan selecteer je onvermijdelijk de rand van een ander object (scrub). Ik kreeg die camera niet op de goede plek. Dacht dat ik voldoende undo had gedaan, maar blijkbaar niet. Hm. Beter opletten voortaan.

En ik ga me maar eens inlezen in JOSM .

Nogmaals dank, mensen!

3 Likes

Het terugdraaien van mijn verkeerde edits heeft blijkbaar niet gewerkt voor 1 bepaald zoom level van de CyclOSM-layer. De andere layers zijn wel goed.

https://www.openstreetmap.org/#map=19/52.140442/5.242925&layers=Y

Het zit niet in de browser cache, die heb ik gewist, en dat maakt niet uit. In TOR-browser (die geen history bewaart) zie je het probleem ook.
Maar in andere layers lijkt alles in orde. Wat kan hier aan de hand zijn? De correctie is al een tijd geleden, is CyclOSM traag met updaten?

Ik zie het ook en ik had deze kaart op die plek nog nooit geladen. Het is inderdaad alleen zoomlevel 19 waar de oude data in wordt gerenderd. Misschien zit er een foutje ergens in de achtergrond met updaten tiles voor dat zoomlevel. Het kan ook een cache-issue zijn aan de serverzijde.

In MapComplete is het ook niet goed, op meerdere zoomlevels.

Ik ben benieuwd hoe je ziet dat het zoomlevel 19 is.

Wat is nu de aangewezen weg om dit opgelost te krijgen?

Dan gebruikt MapComplete waarschijnlijk gedateerde tiles. Mogelijk is het daar wel een geval van lokale cache en kun je de cache van de app leeggooien (ga er even vanuit dat het Android is).

Zoomlevel 19 leid ik af uit de URL (#map={zoom}/{lat}/{lon}).

Anders is het denk ik gewoon een kwestie van wachten, geen idee hoe je dit zelf kunt oplossen

1 Like

Ok, bedankt. Ik heb het als issue gemeld in de github-repo van MapComplete. Meer zou ik nu ook niet weten.

A post was merged into an existing topic: BAG-importverzoeken

De geometrie in de BAG en BGT zijn niet het zelfde…
De BAG registreerd het bovenaanzicht en dan niet alleen wat je ziet maar ook onder de grond.
De BGT registreerd de geometrie op het maaiveld. Dus dat is al een verschil.
Verder worden in de BAG alleen panden opgenomen die aan bepaalde voorwaarden voldoen zoals bv.

  • 4 muren
  • een dak
  • moet afsluitbaar zijn
  • gemakkelijk toegankelijk voor een “normaal” mens (dwz normale deur en minimale sta hoogte)

De BGT registreerd in principe alles wat op het maaiveld zichtbaar is.

Verder is er ook nog een verschil in wanneer iets geregistreerd wordt.
In de BAG is dat binnen 4 werkdagen nadat de bouwvergunning is afgegeven. De definitieve geometrie moet binnen 6 maanden na oplevering zijn aangepast.
In de GBT moet het pand binnen 18 maanden na oplevering van het pand geregistreerd zijn.
Overigens houden veel gemeenten zich niet aan de BAG termijnen en sommige gemeenten hebben ook hun eigen interpretatie van wat in de BAG moet en wat niet.

Waarschijnlijk is deze specifieke geometrie in de BAG de omtrek van de parkeergarage onder het pand.

Ik zie in de BGT-viewer overigens alleen een braakliggend terrein.
Jij bedoeld waarschijnlijk het beeld wat je ziet in verbeter de kaart…
Maar waar die info vandaan komt weet ik eigenlijk ook niet.

Nee ik bedoel de bgt layer in de ID editor

Hmm, zou goed kunnen dat er een parkeergarage onder zit. De geometrie in OSM klopt alleen nog niet met wat in de bag staat. Kan jij deze bijwerken? Dan kan ik daarna met building parts aan de slag om het 3d goed in osm te krijgen.

Gedaan achavi - Augmented OSM Change Viewer [attic]

1 Like