Bij één POI/één gebouw mag je eventueel alle tags inclusief het adres op de outline zetten (CTRL-SHIFT-G), maar voeg dan de tag entrance=main toe bij de ingang[6]. Je mag er van uitgaan dat de BAG panden beter zijn gepositioneerd dan de Bing beelden, verschuif dus niet zomaar de BAG panden.
Je kunt overwegen om de bestaande node met aanvullende gegevens (zoals amenity etc etc.) middels CRTL-SHIFT-G samen te voegen.
Ook kun je overwegen om deze nieuwe node dan weer samen te voegen op de pandcontour (alleen als het pand 1 adres heeft) voeg dan entrance=main toe op de positie waar de ingang zit.
De handleiding is echt noodzakelijk om de stappen goed te doorgronden, en te doorlopen. Alleen al om de logica te ontdekken van de stappen die gedaan worden. Maar zeker ook om de import op een zo eenduigig mogelijke manier te voltooien.
Ik verzoek de BAG uploaders dan ook om zich allereerst te houden aan de handleiding. Mocht in de handleiding noodzaak bestaan om aangepast te worden is dit zeker wenselijk zodat een ieder hier ook naar kan werken.
Heeft hier niks mee te maken, kwam dat tegen en voordat ik daar wat verander (bag) dacht ik er moet misschien veel teruggezet worden, niet eerst bag aanvullen en dan terugzetten leek mij geen goed idee.
Dacht ik al wel dat het niets met BAG te maken had, er zijn veel gebieden waar multipolygonen incompleet zijn heb ik gemerkt. In het begin had ik de gedachte dat dit door de BAG upload zou kunnen komen vandaar dat ik het op dit draadje had gezet om alle zekerheid te hebben dat de plug-in het niet zou veroorzaken. Ook zag ik dat je in dit gebied nog geen BAG upload had verricht, dit gaf al aan dat het niet door de BAG import kon komen.
Bag geeft commercial op de gebouw
Node binnen gebouw geeft building=office met naam bedrijf.
Zet je de bedrijfsnaam op pand of aparte nieuwe node binnen gebouw.
Ik zit hier een beetje mee te worstelen, ook nog met een service wasstraat op node binnen pand en de garagenaam op de node
En dan?
Zo van die praktische overwegingen.
Schematisch schetsje/plaatje zou het inzichtelijk maken met een grote acculade welke bag data waar beslist moet blijven staan en andere twee keuze en welke ander aanvullend of reeds bestande tags aan welk mag worden toegevoegd.
Van wat je zo tegenkomt.
zo is er source BAG, maar wat als je iets anders aan die node aanvult verander je dan de source.
Klopt, je krijgt een waarschuwing tijdens valideren (building inside building), als op een bestaande node ook een tag building=* aangebracht.
Je kunt (staat in de handleiding en een aantal posts hierboven vermeld door mij) de nodes en het pand met CTRL+SHIFT+G samenvoegen op de pandcontour.
Zorg dan wel dat je één waarde gebruikt voor de building=* tag, ik zou adviseren om de waarde van BAG aan te houden voor building=
Ook bij overkappingen bij tankstations kun je overwegen om building=roof te gebruiken (deze overkappingen staan (volgens mij) nooit in de BAG), maar omdat de foutmelding kan komen omdat er een weg doorheen loopt kun je building=roof + layer=1 te gebruiken.
Ook kun je hiervoor een andere oplossing gebruiken die geen waarschuwing in de validator geeft :
Maak dan op de kruising van de roof extra nodes aan waar de weg(en) kruisen. (gebruik evt. J(oin) node to way)
Ik heb het filmpje zojuist bekeken. Vakkundig hersteld zie ik wel. De fix is een mooie optie. Het gebied rond de Herault wat gerepareerd is en het gebied rond het water Aquabest ben ik nooit bezig geweest, en lijkt me ‘oud zeer’ van de kaart.
Onderstaande wordt niet geschreven als negatieve kritiek, maar als opbouwende kritiek om voor allen alert te zijn op problemen die achterblijven als validatie niet of niet goed genoeg zijn uitgevoerd. Het is niet de bedoeling op persoonlijk iemand aan te spreken. De persoon zelf wordt geacht om te kijken wat zijn veroorzaakte problemen zijn.
In onderstaand voorbeeld heb ik een willekeurig BAG gebied middels de mirror gedownload, hierop heb ik de validator losgelaten. @florisje: Zou je deze stukjes willen downloaden om de validator de check op los te laten? (Je zou natuurlijk net als ik heb gedaan een groter stuk via de mirror kunnen downloaden.)
100 duplicated nodes worden gevonden als error melding. Deze nodes (zoals al eerder vermeld) worden vermoedelijk door in bug in JOSM veroorzaakt, en kunnen dan ook vrij snel worden verholpen door de “fix” button te gebruiken. YouTube instructie
Building insdide building: Positie 1:
Dit voorbeeld is een veel voorkomende waarschuwing die niet gewenst is volgens de handleiding (lees BAG import)
Rechtsonderaan zit een ribbe waar een extra node opstaat, deze veroorzaakt de waarschuwing.
Wij moeten ons als BAG uploaders verantwoordelijk voelen voor door ons veroorzaakte problemen. YouTube instructie
positie 2
Dit voorbeeld gebeurt regelmatig als een bestaande node voorzien is van een tag building=*
Bij de validatie wordt dan een melding gegeven dat er building inside building aanwezig is. De node is immers geen building. De tag building hoort alleen op de pandcontour te staan. YouTube instructie
positie 3
Mooi voorbeeld van een polygon waar een dubbele tag building in staat.
Deze polygon bestaat uit een inner en outer. Normaal gesproken is het niet verstandig om op deze contouren tags te plaatsen. In dit voorbeeld is dit wel gebeurt. YouTube instructie
Dit staat aangegeven in de handleiding bij STAP2 G als:
Let op bij samenvoegen op een multipolygon, zet in dit geval de extra informatie niet op het pandcontour maar open de relatie en voeg daar de aanvullende tags toe.
Self intersecting ways: Deze positie
Dan zit er een stukje aan een gebouw wat een losse lijn is, en geen verbinding aan het eind heeft. De eigenschappen van een building is juist dat het een gesloten geheel is. Vandaar dat we deze waarschuwingen moeten oplossen. YouTube instructie
@florisje, ik heb bovenstaande niet opgelost, dat laat ik aan jou over. Wel heb ik filmpjes gemaakt met oplossingen als naslagwerk voor uploaders die dezelfde problemen hebben en zich afvragen: “Hoe zit dat ook al weer?”
super dat je de tijd hebt genomen om er naar te kijken! ik kan wel wat hebben hoor, dus de waarschuwing was niet nodig
de nabewerking stap heb ik inderdaad nog niet heel consequent gedaan. bijna alle uploads gaan goed, de 100 duplicated nodes die je hebt gevonden kwamen doordat ik die volgens mij vanuit de trein heb geupload en er gaar wifi was
maar ik zal nu even stoppen met nieuwe gebieden inlezen en eerst de nabewerking doen.
ik voeg veel building passages toe (tip: voeg de knop toe op de werkbalk) maar bij deze specifieke vermoed ik dat hij in het gebouw ernaast zit, dus ik wou er nog even langs fietsen
Building insdide building: dat was echt een hele lastige, vooral door het pleintje. ik ben daar een paar keer opnieuw begonnen. bedankt voor de tip.
positie 2: deze node heb ik met opzet zo gelaten. het probleem is niet door de BAG import veroorzaakt. Ik ken dat pand als de Hema, die node heb ik ook samengevoegd met de BAG adres node. ik vermoed dat deze office node misschien op de 1e verdieping zit. ik zal er binnenkort eens langs lopen.
positie 3: die was ook tricky vanwege het combineren van oud en nieuw, maar ik heb hem nu opgelost. rendering is ook meteen een stuk mooier!
Self intersecting ways:
ik kreeg die inderdaad niet weg, dus dacht: laat maar zitten… gelukkig ben jij er nog
toen ik hem later nog ergens tegen kwam heb ik hem wel opgelost, en het kan iets makkelijker dan in jouw filmpje:
selecteer het gebouw met het frutseltje
shift + selecteer de node in het midden waar het eigenlijk zou moeten stoppen
toets P voor ‘split way at current node’
gooi daarna het losse stukje weg.
nogmaals bedankt voor de feedback, schroom niet om meer te geven.
ps. heel gemeente haarlem gaat deze week niet meer lukken, maar de binnenstad zit er al in!
Inmiddels is de handleiding op STAP 2D iets gewijzigd.
De controle op volkstuinen en industriele complexen is uitgebreid met controle op tribunes. Deze gebouwen zijn namelijk niet (altijd) opgenomen in de BAG en zouden verwijdert worden als je hier niet handmatig (in de OSM) laag bag=conversie toe zou voegen. Deze tag voeg je namelijk toe om later (na het mergen van de ODS laag naar de OSM laag) weer te verwijderen.
Mocht je niet helemaal begrijpen wat er wordt bedoeld, kijk dan naar de YouTube instructie in de handleiding.
Ook is de regel omhoog gebracht, omdat anders het gevaar er in zit dat je eerst de 3dshapes verwijdert voordat je bag=conversie hebt toegevoegd.
De BAG bevat over industriële complexen en volkstuinen minder info dan 3dShapes: check handmatig industriële complexen, volkstuinen en sportcomplexen (tribunes). Voeg daar zonodig de tag bag=conversie toe. Voeg bij opslagtanks de tag man_made=storage_tank toe. YouTube instructie Volkstuinen herken je aan landuse=allotments, industriële complexen aan landuse=industrial.
Nadat mijn eerste import op de BAG-workshop 8 maart, mede door de hulp van PeeWee, gelukt was, aan de slag in mijn eigen woonomgeving.
Ik had in eerste instantie een groot gedeelte van een buitengebied met veel kassen geselecteerd, maar kreeg te veel foutmeldingen naar mijn zin via de Validator.
Dus maar wat kleinere woonwijkjes geselecteerd met beperktere foutmeldingen en deze kunnen afmaken.
Inmiddels een wat grotere woonwijk, maar daar komen de nodige crossing buildings en building in buildings. Dus dat allemaal eens rustig zien op te lossen.
Op voorhand de volgende vragen:
na mergen van de ODS BAG naar OSM Bag zie ik bij diverse appartementen dat de adresnodes vanuit BAG als een wolk in het pand staan en niet op een rij of andere groepering. Doe ik iets fout of vergeet ik iets te doen.
In het gebied wat ik wil aanpakken staan veel kassen(complexen). Deze bestaan vaak uit een woonhuis, een loods en de kassen zelf. In de BAG staat dit vaak als 1 coomplex getekend en veelal met alleen de woonfunctie en soms in combinatie met industriële functie. Als ik hier niets aan doe komt het gehele complex als 1 pand in OSM vermoed ik. Dat is niet de bedoeling. Hoe zouden jullie dat aanpakken.
Als ik de polygon teken van het gebied wat ik wil aanpassen, sla ik deze laag op (in de plugin/ods-bag map). Deze overschrijft dan de vorige polygons.osm. PeeWee had een polygons.osm laag waar alle polygongebieden in staan welke hij aangepast had. Hoe krijg ik dat samengestelde lagenoverzicht.
Je doet hier niets fout. Als de gemeente de ingevoerde BAG-adres nodes (van apartementen/flats etc.) op elkaar heeft gestapeld, zet de plug-in deze netjes naast elkaar. Mocht het zijn dat het een wolk vormt, zal dit de invoer van de gemeentelijke data kunnen zijn. Je kunt (als je weet hoe de adressen verdeelt zijn over het pand) de functie Distribute nodes (SHIFT-B) gebruiken (in JOSM).
Als BAG data verbetert zou moeten worden, kun je middels het BAG terugmeldformulier melding maken, zodat ook de BAG data aangepast zou kunnen worden. In het geval van gebruiksdoel weet ik niet hoe gemeentes hier mee omgaan. Daar zou iemand anders op kunnen reageren.
Ik sla mijn polygons op als verzamel polygons.osm (en maak af en toe een backup van dit bestand)
Als ik met een nieuw gebied begin, open ik dit polygon bestand.
In de BAG staan de nodes vaak precies op elkaar. De plug-in trekt ze een beetje uit elkaar, zodat ze eenvoudiger te kunnen editen. Voor de precieze locatie van de nodes zal je ter plekke moeten gaan kijken. De BAG garanderen alleen dat ze in het juiste pand zitten. In Utrecht-CS/Hoog-Catharijne werd ik daar ook niet erg vrolijk van.
Als er nu meer informatie in OSM staat, probeer ik dat te houden. De mooiste oplossing vind ik om de delen (zoals het woonhuis) apart te labelen met “building:part=house”. Helaas doe de mapnik renderer daar op dit moment nog niet zo veel mee.
Als het goed is, wordt het polygons.osm bestand uit de plugins/ods-bag map automatische geopend in een aparte laag zodra je ODS-BAG activeert. Weet je zeker dat het bestand de juiste naam heeft (polygons.osm) en in de juiste directory staat (met een s achter plugins.).
Goed punt. Tijdens de beta test is hier ook over gemaild en de meningen zijn wat verdeeld denk ik. Op zich is er iets voor te zeggen dat een Dr. vervangen wordt door een Doctor (als je weet dat dit zo is) omdat dit meer en betere informatie is dan alleen een Dr. . Aan de andere kant kunt je zeggen dat we mappen wat we zien en als er Dr. op het straatbordje staat waarom dan Doctor mappen? Idem voor de voorlettes van personen.
Zaterdag had ik daar ook nog een kleine discussie over met 1 van de workshop aanwezigen. Ik denk dat het goed is hier in dit forum (apart draadje?) verder over te discussieren.
Ik zit er nog een beetje dubbel in. Ik map vaak wel de “bedoeling” van de wegbeheerder als iets overduidelijk is. In dat opzicht is het te verdedigen dat een P.J. Troelstralaan gemapt wordt met een name=Pieter Jelles Troelstralaan. Dat was volgens mij de bedoeling maar dan wordt zo’n naambord zo lang ;). Aan de andere kant ben ik voorstander van het mappen wat we zien.
Wat mij betreft houden we de afspraken in de handleiding aan zoals in STAP 4B wordt uitgelegd:
Na -in principe- circa twee dagen is de OSM inspector van Geofabrik bijgewerkt. Verbeter dan met de adresweergave van OSM inspector (nodes with addresses -> street not found) de mismatches tussen adressen en straten. In principe is de BAG naam juist. In OSM worden straatnamen echter voluit geschreven. Volg in die gevallen de OSM notitie en verander dan de adresnodes. Bijvoorbeeld: Dr. -> Doctor, Burg. -> Burgemeester, Prof. -> Professor (zie Name_finder:Abbreviations#Nederlands_-_Dutch voor een complete lijst met afkortingen). Je kunt in twijfelgevallen het NWB raadplegen via http://pdokviewer.pdok.nl
De straatnaambordjes zouden kunnen afwijken van de BAG, dit zou betekeken dat de gemeentes in de loop der tijd deze bordjes zou moeten vervangen. Volgens mij is dit ook zo vastgelegd in de BAG.
Op deze manier houdt je ook eenduidigheid in OSM, waar ook ieder bij gebaat is. Het lijkt me geen vooruitgang als iedereen op zijn eigen manier de correcties op de inconsistenties van de straten gaat uitvoeren.
Overigens hoef je niet te wachten tot de OSM inpector nieuwe data heeft om deze inconsistenties op te lossen.
Je kunt de handige plug-in “FixAdresses” installeren om de afwijkende straten op te sporen. Ik zal een filmpje maken om te laten zien hoe goed deze tool kan werken. Het lost overigens de problemen niet op, maar is wel zeer handig.
Ik zou bijvoorbeeld niet weten wie A.J. is het is al jaren in de volksmond A J
Dan volgens Name_finder:Abbreviations#Nederlands
dr. zou doctor zijn
en
DR. zou Dokter zijn
het o en e verschil
Hiermee zeg ik dat de handleiding en Name_finder:Abbreviations#Nederlands elkaar tegenspreken.
het bewust schrijven door Bag van “dokter” met kleine letters en " e ". Terwijl het straatnaambord DOKTER M. PLASVER is al (rond 1990 gebouwd)
(wijk verder dan zie je rond 1994 De Hoek, en is men begonnen met kleine letters.)
het gaat om wel niet hoofdlettergebruik de - De - doctor - Doctor
en dan
puntgebruik AJ - A.J.
(kijkend met een scheef oog naar routerings zoeken)
leidend zou de Bag moeten zijn, meen ik, dat je een voorvoegsel voluit schrijft kan ik me indenken omdat je ze ook zo uitspreekt.
Maar er zijn ook afkortingen initialen die alleen letter(s) blijven.
Het filmpje, hoe je het hulpmiddel FixAdresses kunt gebruiken om de straat inconsistenties op te lossen, is inmiddels klaar.
Dit hulpmiddel kan je helpen bij het opsporen van afwijkingen in de adresnodes en de straatnamen. (met dank aan Harry voor zijn tip!:))
Nadat je dit hulpmiddel gebruikt zou hebben, is het nog wel noodzaak om een aantal dagen later OSM inspector te raadplegen om te controleren of de straten matchen met de adres nodes.
Let wel op als je de een (lange) straat wil aanpassen. Gebruik het filter en gebruik ook zoek functie. Zorg dat je zoekt in de selectie!
Hetzelfde geldt als je de adresnodes van een straat in één keer wil gaan aanpassen. Ook hier geldt gebruik een filter en zoek in de selectie!
Gebruikte filters:
(“highway”="")
-type:node
landuse=
Mochten er mensen zijn die betere filters hebben hou ik me hiervoor aanbevolen!