OpenStreetMap logo OpenStreetMap

Changeset When Comment
80469755 about 5 years ago

Bedankt voor het melden. Dit pand heeft waarschijnlijk (korte tijd) onterecht als 'in gebruik' in de bag gestaan. Inmiddels heeft het daar ook de status 'gesloopt'. Zie: https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=0848100000008813&geometry.x=161789.2084&geometry.y=392575.0422&zoomlevel=6&objectId=0848100000008813&detailsObjectId=0848010000006580
Ik heb het pand weer van osm verwijderd.
Mvg

77596479 over 5 years ago

Sorry hiervoor.
Van wat ik me kan herinneren was dit gebied nog al een zooitje toen ik er aan begon, veel dingen waren slordig ingetekend op osm, maar ook de BAG klopte niet helemaal. Ik heb geprobeerd hier kaas van te maken en omdat het betreffende gebouw op PDOK één geheel lijkt heb ik denk ik geconcludeerd dat de BAG hier klopte.

Om dergelijke problemen te voorkomen kan je een note tag toevoegen. Bijvoorbeeld: 'note:BAG=aangepast aan de hand van survey' of iets dergelijks.

Ook kan je bij het splitsen van gebouwen het BAG pand intact laten en de verschillende onderdelen als 'building:part=*' inteken. Ik durf echter niet te zeggen of dat in dit geval een handige oplossing is.

78432086 over 5 years ago

Ik heb het e.e.a. aangepast.

Ik deel je standpunt dat niet alle wegen binnen de bebouwde kom residential moeten zijn. En dat AND niet fout hoeft te zijn.
Mijn logica hier was dat informatie die ik uit recente luchtfoto's haal betrouwbaarder is dan informatie van een import uit een tijd toen de highway=residential tag nog niet bestond.
Omdat alle wegen op unclassified stonden heb ik geconcludeerd dat in de afgelopen 12 jaar niemand naar de classificatie gekeken heeft. Daardoor voelde ik me (misschien iets te) vrij om enigszins rigoureus te werk te gaan.
Als ik deze logica doortrek dan gaat uiteraard locale kennis voor op informatie die ik uit PDOK haal, dus van daar mijn opmerking dat je je vrij moet voellen mijn werk weer aan te passen.

Ik hoop dat deze kwestie hiermee naar tevredenheid is opgelost.

Mvg

78432086 over 5 years ago

Bedankt dat je even meekijkt! In de gehele bebouwde kom hier stonden alle residential wegen op unclassified. Deze misclassificatie is afkomstig van de AND import. Daarom heb ik de wegen die volgens PDOK nog het meest op woonstraten leken op residential gezet.
Mocht vinden dat in bepaalde gevallen unclassified toch geschikter is voel je dan vrij dit weer aan te passen.

75349418 over 5 years ago

Ik heb het weer gerepareerd

74502161 over 5 years ago

Bedankt voor het opletten en herstellen. Ik kon me er niks van herinneren, dus ik heb het even nagezocht.
Nu blijkt dat de fout is ontstaan doordat de JOSM validator een automatische fix aanbied voor objecten met een beschrijvende naam. (die fix is om de naam te wissen)
Ik zal eens bij de JOSM ontwikkelaars aankaarten of dat niet aangepast moet worden.
Mvg

76411898 over 5 years ago

Geen probleem. Ik heb ze voor je teruggehaald.
mvg

76411898 over 5 years ago

Beste E,

Bedankt voor je werk aan de bag-update. Ik heb echter het vermoeden dat je iets te enthousiast was met het verwijderen van adres nodes.
Het gaat om de adressen Zwettestraat 13 en 15 en Toutenburgstraat 11. Allen binnen het zelfde pand: osm.org/way/302251154

Dit zijn nevenadressen. Nevenadressen worden om de een of andere reden niet in door de bag-plugin gedownload, maar bestaan nog wel gewoon. Nevenadressen zijn een soort secundaire adressen die bijvoorbeeld worden gebuikt als een pand een achteringang aan een andere straat heeft

In het algemeen worden adressen die door de gemeente ingetrokken zijn weergegeven als een rood kruisje op de bag-update achtergrond laag. Andere adressen kun je meestal beter ongemoeid laten.

Tenzij je een andere reden had voor het verwijderen van deze adressen stel ik voor ze weer terug te plaatsen. Laat maar weten of dit zelf doet of liever aan mij over laat.

Met vriendelijke groet, de vries

75067509 over 5 years ago

Beste Jaap,
Mijn excuses. Ik zie niet om welke gebouwen het zou gaan, maar ik ga er van uit dat je ze inmiddels weer verwijderd hebt.

mvg

74607243 over 5 years ago

Beste tvdbroek,

Het is inderdaad niet de bedoeling dat dergelijke informatie uit osm verwijderd wordt bij een BAG-update.
Ik kan in deze changeset echter niet vinden waar dergelijke informatie verloren is gegaan.
Wel heb ik adres gegevens van de omtrek van gebouwen verplaatst naar adres nodes om de de manier van mappen gelijk te houden met hoe adressen en gebouwen in de rest van Nederland gemapt worden.

Mocht ik iets over het hoofd hebben gezien en toch ergens informatie verwijderd hebben, dan hoor ik dat graag van je. Zou je me in dat geval een linkje kunnen sturen naar het betreffende osm object? Dan kan ik uitzoeken wat er mis is gegaan.

mvg

74826129 over 5 years ago

Hoi Byckel,
Excuses voor het overschrijven van je handwerk. Bij handmatig ingetekende gebouwen maak ik altijd een afweging of de geometrie vervangen moet worden of niet.
Ik meen mij te herinneren dat ik aan de hand van de 'latest mosaic' luchtfoto's had besloten dat de BAG variant niet slechter was wat jij ingetekend had.
Gezien de 'luifel' aan de voorkant van de loods de in de BAG staat ingetekend denk ik niet dat ik toen de juiste keuze gemaakt heb. Nogmaals mijn excuses.
Reverten ging niet helemaal probleemloos dus heb ik er voor gekozen om de geometrie van de romneyloods aantepassen aan de 'latest mosaic' luchtfoto. Ook heb ik een note:BAG toegevoegd om herhaling te voorkomen. Dit lijkt mij de beste oplossing.
Mocht je het hier niet mee eens zijn dan hoor ik dat graag, of voel vrij het zelf aan te passen.

mvg

69658662 almost 6 years ago

Dit is mij bekend ja. De BAG-update gebeurt met een JOSM plugin die helpt om nieuwe eigenschappen zoals bijvoorbeeld een gewijzigde start_date naar osm opjecten te kopiëren, daarnaast is het een hoop handwerk, zoals het vervangen van gewijzigde geometriën en het uitvoeren van validator checks.

Ik probeer altijd om (handmatig) te voorkomen dat de start_date naar roerend goed gekopieerd word. In de BAG heeft dit nl. geen start_date geloof ik. Maar soms glipt er wel eens iets tussen door.

Bedankt voor je melding ik zal het nog eens aankaarten bij de ontwikkelaar van de Plugin.

mvg

70881894 almost 6 years ago

Hoi Jaap, kan je je nog herinneren om welk pand het ging? Ik wil in deze buurt nl. nog wat bag panden updaten en ik zou het vervelend vinden als ik het in kwestie pand per ongeluk weer importeer.
mvg

70881894 almost 6 years ago

Bedankt voor het opmerken. Kan je laten weten om welk pand het gaat? dan kan ik herhaling voorkomen.

54393370 almost 6 years ago

I don't know, that was a long time ago, but looking at the history of this way, that tag didn't come from me. The tag was added in 2014 by richardbrinkman_BAG, which is an import account. So the tags were probably copied from what ever was there before the BAG-import.
This makes the source of this info flimsy at best so I don't think it's safe to just add leisure=sauna.

68797375 about 6 years ago

Nee, dat heeft niks met de BAG te maken. Echter als ik de BAG bijwerk pas ik meestal ook gelijk de wegen aan. (mbv PDOK)
Dit is gewoon een foutje dat aan mijn onoplettendheid te danken is.
Bedankt voor het opmerken en repareren.

mvg, (niet Jaap) de vries

65713418 about 6 years ago

dit?

65354649 over 6 years ago

Hoi R_S,

bedankt voor het opmerken. Ik heb de panden weer verwijderd en een note:BAG toegevoegd met een verwijzing naar deze changeset, zodat deze fout niet herhaald wordt.

Ben je er trouwens mee bekent dat je een terug melding kan doen via https://bagviewer.kadaster.nl/ als je een fout in de bagdata vindt?

mvg

61503273 over 6 years ago

Mijn complimenten voor hoe je deze rotonde hebt opgetuigd.

64854840 over 6 years ago

Hoi Jaap,

Bedankt voor je oplettendheid. Ik heb de panden verwijderd en er een note geplaatst om te voorkomen dat het opnieuw geïmporteerd wordt.

zie: osm.org/changeset/64873362

mvg