Idee om wat met BAG te gaan doen

Er stonden inderdaad adressen op deze bunkers, zowel op de bunkers waar het overzetten wel goed is gegaan als op de bunkers waar het niet goed is gegaan.
In de adres-verwijderings-stap deselecteer ik altijd net zo lang, tot er alleen tags in staan die beginnen met addr.
Waar het precies mis is gegaan heb ik helaas niet kunnen achterhalen.

Hoi, de reactie van Richard

op de vraag van Johan is correct. de situatie is op Zuidkamp bijzonder, 70 - 80 % van de gebouwen zijn in 40 - 45 als gecamoufleerd boerenhuis (bunker) gebouwd. Zeker 20 stuks zijn al 60 jaar als woonhuis in gebruik, lastig met muren van 0,60 en een dik betonnen plafond, maar op de boven verdieping is het goed wonen. De andere zijn bij defensie in gebruik geweest tot de ontmanteling van het vliegveld. Dit verschijnsel cq bouwstijl komt bij meerdere in die periode gebruikte vliegvelden voor. Maar kan ook in steden voorkomen, de beste oplossing was hergebruik, neem de loods van CeBo in Velsen http://www.openstreetmap.org/#map=17/52.46019/4.57701
en de oude torpedobunker, nu oefenruimte voor bandjes. http://www.openstreetmap.org/#map=18/52.45475/4.58187 Hebben de buren nooit last van de muziek.
BAG werk van Florisje, complimenten !

Ik vroeg me dus af of er overeenstemming over moet worden bereikt op een of andere manier. Als hier verder niemand (negatief) op reageert zal ik dat beschouwen als een stilzwijgend instemmen en zal ik je voorbeeld volgen door ze ook gewoon maar toevoegen.

Een vraagje op Richards verzoek loop ik zijn revert nog even na. Dat brengt mij tot het volgende,
een specifiek pand stamt uit 40 - 45, het is getooid met node en adr etc met de later aangebouwde serre, de tags op het pand horen bij het origineel zonder aanbouw. Na de scheiding vraag ik mij af wat nu, de aanbouw draagt alle kenmerken van het monument ?
Alle specifieke kenmerken er af halen ? Maar de node hangt op het oudste deel van het pand ?.

Ook ik zou het mooi en handig vinden als de BAG-laag vaker bijgewerkt zou worden. Volgens mij geldt dit echter niet alleen voor de lagere zoomniveaus, maar voor alle.
Is het mogelijk om deze kaart vaker te vernieuwen?

De code om verouderde tiles opnieuw te renderen is nog lichtjes in herontwikkeling. Tot die tijd kan ik de tiles wel wissen, maar gezien de lange rendertijd krijg je dan wel een tijdlang de 404 tiles te zien.

Misschien is het handig om een extra filter (building=yes -source) te gebruiken voordat de 3dShapes panden verwijderd worden.
Het eerste filter in de handleiding is namelijk ingericht op het behouden van warm aangebrachte tags die na de 3dShapes import zijn toegevoegd.
Je kunt je voorstellen dat er ook mappers zijn, die gebouwen hebben aangebracht, zonder dat deze in de 3dShapes hebben gestaan.
Er zijn dus voorbeelden te bedenken dat er een gebouw met 1 tag “building=yes” aangebracht is door een mapper. Meestal zul je zien dat de ODS/BAG laag (inmiddels) is voorzien van een gebouw op deze positie. In zo’n geval is het niet zo erg dat een gebouw met 1 tag verwijderd wordt.

Helaas wordt deze door het filter gezien als “te verwijderen item”, meestal is het een “onbelangrijk” gebouwtje, maar wie bepaald dat…
De uploader heeft niet voor niets zijn energie gestoken in het aanbrengen van het gebouw(tje)

Het is visueel ook te ontdekken of deze 1-taggige gebouwen zijn aangebracht.
Als je het 1e filter in de handleiding gebruikt om 3dShapes panden te vinden, welke geen warm aangebrachte tags bevatten, zul je in je dialoogvenster Tags/Memberships de maximaal 5 tags (voorheen 3) tegenkomen die verwijdert zouden mogen worden.

Indien bij “source” een waarde “different” verschijnt, betekent dit dat niet alle tags zijn voorzien van dezelfde 5 (of 3) tags in de rest van de selectie.

Als je dan met het trekvenster value de waardes van source gaat bekijken zul je vaak zien dat het alleen maar 3dShapes zijn. Zie plaatje 2 ► 3dShapes (426)

Maar schijn bedriegt, er staat duidelijk de waarde “different” dit betekent dat er ook andere waardes zijn. Ik ben er inmiddels achtergekomen dat dit “blanco” tags zijn.
In het voorbeeld van een gebouw met 1 tag is er geen waarde met source!
Om deze gebouwen in beeld te krijgen is het mogelijk om een (geïnviteerd) filter aan te brengen die deze gebouwen met 1 tag visueel laten zien.

Op deze manier kun je overwegen om middels de aan te brengen tag “bag=conversie” de gebouwen te behouden. (deze tag zal na de merging van layers weer verwijdert gaan worden.

Toch even een vraag: Of mogen deze blijven bestaan op OSM? Om in de toekomstige update imports deze gebouwen eerder in beeld te krijgen (omdat er een warme tag aangebracht is)

Misschien dat er nog andere (lees: betere) methodes zijn om gebouwen met 1 tag te behouden.

De afgelopen jaren heb ik ook regelmatig gebouwen met 1 tag toegevoegd aan OSM die.
Deze gebouwen zijn meestal gebouwd na originele aanmaak van de 3dshapes data. Of ze stonden nog op construction.
Als een gebouw in Bing zichtbaar is en er vrij nieuw uit zag heb ik deze met alleen building= in ingevoerd.

Soms waren het gebouwen in mijn omgeving die gebouwd waren maar nog nergens zichtbaar waren (voornamelijk in het buitengebied).

Deze invoer is niet zo nauwkeurig geweest als de BAG informatie en mag volledig vervangen worden.
Alleen evt. tags buiten het adres en building= moeten behouden blijven (naam bedrijf, website, greenhouse, etc.).

Ja maar dan zou het wel handig zijn als je ook reageert op mijn e-mail… (Even aangenomen dat hier niet meerdere johans zitten.)

In de wiki staat dat ik een of andere Johan moet e-mailen op osmned at gmail, dus ik dat gedaan maar in 4 dagen geen reactie. Ik had al eerder willen gaan BAGgen maar had nu eindelijk tijd om er eens goed voor te gaan zitten, dus ik neem die wiki handleiding voor me… blijkt dat ik eerst iemand moet gaan vragen om een plugin. Handig is dat. En dan vooral als mijn week vrij zo goed als om is en er nog steeds geen reactie komt. Ja zo kunnen mensen inderdaad meehelpen!

Er ging afgelopen week wat mis op het werk, ik zag je berichtje dus pas net, Pensacola. Ik begrijp dat je opmerking voldoende is beantwoord door Cavit?

Ik wil graag het onderwerp van “de parkeerkelder die als gebouw in de BAG terugkomt” nog eens aanstippen, slinger het rustig in een apart topic als je denkt dat dat beter is.

Een reeds geimporteerd voorbeeld (Utrecht) zie je hier:
http://www.openstreetmap.org/?mlat=52.07768&mlon=5.14334#map=18/52.07768/5.14334
Een groot vlak in OSM, maar in werkelijkheid 4 torens en een doorgaand fietspad (dat over het dak van de parkeerkelder loopt).

Een voorbeeld waar ik tegen aan ga lopen:
http://www.openstreetmap.org/?mlat=51.47674&mlon=5.54967#map=19/51.47674/5.54967
Een groot vlak in BAG, maar in werkelijheid redelijk smalle gebouwen, die in de volksmond dankzij hun vormgeving ook wel samen 'het oog van Nuenen" genoemd worden en wegen (plein) die er tussendoor (over het dak van de parkeerkelder) lopen.

Ik zou graag de vorm aanhouden zoals die zichtbaar is vanaf grondniveau. Er staat me iets van bij dat de plugin hier een vertaalslag maakt om te voorkomen dat meerdere gebouwen op elkaar in de OSM database terechtkomen (of zoiets dergelijk), maar hoe zat dat precies en is het dan ook mogelijk om deze techniek (tijdelijk) uit te schakelen, zodat de importeerder dergelijke constructies met wat extra aandacht net iets mooier kan importeren?

Ik ben al een paar dagen in Limburg bezig. Zie http://harryvanderwolf.dyndns.org/OSM/bagpolygons.php en https://wiki.openstreetmap.org/wiki/BAGimport_Intekenlijst

Er is een Keepright update van 18 april. In een gebied dat ik heb gebaggerd in Maastricht, staan veel fouten: “This node is not member of any way and does not have any tags”
http://keepright.ipax.at/report_map.php?zoom=19&lat=50.8325&lon=5.72
De nodes zijn echter verbonden met buildings. Kennelijk is Keepright van slag?
Het zou kunnen dat Keepright aan het updaten was terwijl ik aan het uploaden was ??? Gezien de datum zou dat wel kunnen.

In een gebied in Vaals staan een paar honderd losse nodes die wel fout zijn en weg moeten. Is daar een filter voor?

René.

Er is al redelijk veel over deze lege nodes gesproken. Deze zijn via de validator op te sporen en via de fix button op te lossen.
Deze procedure staat beschreven in de handleiding! Het is zowiso belangrijk om de handleiding af en toe stap voor stap uit te voeren. Er worden regelmatig verbeteringen aangebracht.

Okay, dus, kan iemand die benodigde ODS-BAG plugin sturen of is er geen hulp meer nodig?

De validator vindt deze lege node helaas niet.

De handleiding heb ik uitgeprint om aantekeningen bij te maken. Dan mis je uiteraard de wijzigingen. Ik zal hem online nog eens doorlezen.

Nu we het toch over de handleiding hebben. Het item over static_caravan is kennelijk niet helemaal duidelijk of uitvoerbaar. Ik heb een paar woonwagenkampen in het land bekeken die al gebaggerd zijn. (Den Haag, Emmen) Het hele perceel wordt als static_caravan getagd zonder aparte adres node. In de handleiding staat: alleen de opbouw opnemen in OSM. Moet je die opbouw van Bing sat overnemen en er een adres node opzetten? Gegevens van de opbouw overnemen was in de kampen die ik ben tegengekomen niet mogelijk omdat ze domweg niet getekend waren.

René.

de mail bleek in mijn spamfolder terecht gekomen te zijn. Luc heeft de plugin inmiddels.

De plugin verwijdert geen objecten. De benodigde info lijkt simpelweg slechts gedeeltelijk in de BAG aanwezig, als ik kijk naar de bron van de plugin die je via http://bagviewer.pdok.nl/index.html kunt raadplegen. Het enige alternatief lijkt me het ouderwetse handwerk voor de ontbrekende delen.

De validator in JOSM werkt betrouwbaar. Dus ja, Keepright is van slag. Ik heb net ff een test uitgevoerd op zo’n melding in Maastricht. De betreffende node die Keepright aangeeft met de melding ‘This node is not member of any way and does not have any tags’ is gewoon een node van een gebouw. Bij de volgende update van Keepright zou deze melding weg moeten zijn. Zo niet, dan moeten we een melding doorgeven dat Keepright onterechte foutmeldingen weergeeft. Onze zuiderburen hebben het geluk dat ze osmose (http://osmose.openstreetmap.fr/nl/map/) kunnen gebruiken, dat schijnt een betere variant te zijn van Keepright.

Als je ‘op’ Scheveningen kijkt kun je zien hoe ik het heb aangepakt. Ik gebruik Bing om de exacte pandcontouren te tekenen. Omdat het strand tussen de Scheveningse haven en het Kurhaus flink op de schop is gegaan heb ik daar geen actuele beelden van waardoor ik noodgedwongen de gehele contour heb laten staan, met een fixme en een verzoekje bij Mapbox om nieuwe beelden. Vanaf het Kurhaus tot de grens met Wassenaar kon ik wel de Bing beelden benutten. De adresnode staat daardoor op de contour. Ik moet nog 's een (tweede) keer langslopen om de ingangen goed te taggen met entrance=main.

Ik had ondergrondse parkeergarages eerst geïmporteerd als building=yes. Dat gaf inderdaad een niet al te mooi resultaat. Ik heb ze sindsdien getagd als amenity=parking; layer=-1; parking=underground; eventueel access=private als het bij een appartementengebouw hoort. En dat dan zonder building=yes.

Zie bijvoorbeeld hier in Terneuzen.

Ik vind dit er toch een stuk beter uitzien dan de nog niet door mij omgetagde openbare parkeergarage iets verderop.

Wat ik doe is het volgende:

  • Selecteer de building=static_caravan polygon.
  • Kopieer deze met ctrl-c en wis daarna de polygon.
  • Kijk op Bing naar de opbouw en teken deze na. Ik pak alleen de basisopbouw, want luifels en dergelijke vind ik er niet bij horen. Teken een lijn langs de lange kant en extrudeer deze met ‘x’ tot een rechthoek. Bij andersvormige gebouwen overeenkomstig handelen.
  • Plak hier de tags van de originele polygon op met ctrl-shift-v.

Als er geen opbouw zichtbaar is op Bing, dus een leeg perceel, plaats ik een losse node met de adres-tags.

PS: Zorg wel dat de Bing-laag goed ligt. Verschuif deze dus eventueel, door te kijken naar andere BAG-panden in de directe omgeving, tot deze goed ligt.