Goed om te weten dat er in Eindhoven al iemand actief is met imports.
In Best is een groot deel al geïmporteerd.
Enkele straatnamen recht moeten trekken, en aangezien er alleen maar 3dshapes aanwezig waren gaat het vrij vlot zonder veel data over te moeten hevelen naar nieuwe shapes.
Dat dokter doctor verhaal is wel erg interessant. Hier hebben we ook van die straten…
Ik vraag me af of dit wel duidelijker word zo. Als je kijkt op: http://www.openstreetmap.org/relation/164224#map=17/51.51102/5.39651
zie je dat er heel veel huisnummers bij elkaar in een wolk staan op de kaart, lelijk gewoon.
Hoe kan ik dit nu netjes maken? kan er bijvoorbeeld ook een notatie gevormd worden zoals 1-9 ipv 1-3-5-7-9, maar dat een nummer midden in de reeks wel te vinden is in een zoekmachine?
Nu Nederland zo langzamerhand steeds meer voorzien wordt van adresgegevens vanuit de BAG kan ik met m’n eigen dorp natuurlijk niet achterblijven 
Kan iemand de plugin beschikbaar stellen zodat ik eens een poging kan gaan wagen?
Hoe switchen jullie gemakkelijk tussen je normale en BAG account? In JOSM kun je (indien je OAuth gebruikt) niet zien wat je huidige username is.
Er is zo te zien wel een ticket voor om dit in JOSM op te lossen http://josm.openstreetmap.de/ticket/2710, maar is deze nog niet gepland voor een release.
@ Cavit fraai grafiekje dat je hebt gemaakt op http://wiki.openstreetmap.org/wiki/BAGimport !
@ Allroads, Cavit, stevebeer ik heb in de handleiding even een draai gegeven aan Dr of dr, in die zin dat het dus twee kanten op kan
Eens dat het wolkje niet fraai is. Een stuk van de oplossing is om de huisnummers zoveel mogelijk te groeperen bij de ingang van appartementen. Maar ook weer niet teveel bij elkaar: we hebben bij de betatest een stevige discussie gehad met de DWG, omdat de adresnodes op elkaar lagen in de BAG. In JOSM was dat geen probleem, maar de DWG wil dat de adressen op de hoogste (2 à 3) zoomniveau’s in Id en Potlatch zichtbaar zijn om te bewerken. Omdat het simpel moet blijven voor beginners (ook een DWG eis) is het ook niet echt een oplossing om de notatie …;…;… toe te passen. Dat wordt bij veel adressen namelijk onwerkbaar voor beginners. Dus is het even roeien met de riemen die we hebben. Eén troost: de adressen zijn alleen op de hoogste zoomniveau’s van Mapnik te zien 
@ Allroads: in de handleiding heb ik bij voetnoot 1 opgenomen dat ik te mailen ben voor de plugin
Leuk om te horen Sander! Kun je mij op osmned@gmail.com een mailtje sturen, dan reply ik die met de plugin als attachment
Ik gebruik geen OAuth, dus ik switch via edit → preferences → connection settings
Cheers, Johan
Hoi Stevebeer,
Lelijk ja, maar dat vindt ik als cartograaf ook van die blauwe stippen in bv stedelijke gebieden, bij zoom 15 valt de kaart weg en zijn slechts de blauwe stippen in beeld. Ik vraag me af of dat niet electronisch onder een level gestopt kan worden, de routeplanner kan er dan toch mee rekenen en met inzoomen tot 19 kan een mens het op het oog ook wel vinden. Of een minder prominente kleur blauw bij verschillende zoom levels.
En nog een reden waarom ik die losse adres nodes maar niets vind. De locatie van de nodes heeft niets met de werkelijke locatie van de adressen te doen. Het enige dat de locatie van de nodes vertellen is dat het gebouw waarbinnen ze liggen een bepaald adres bevat. Helemaal nu blijkt dat de import tool moedwillig de nodes gaat verplaatsen is de preciese locatie al helemaal niet meer volgens de werkelijkheid. Ik ben en blijf dus een voorstander om adres gegevens als attributen van een gebouw te zien. Een adres is net zo hard een eigenschap van een gebouw als bijvoorbeeld het aantal etages. En je gaat ook geen node met building:levels plaatsen binnen een gebouw; die tag zet je ook op het gebouw.
Wat betreft adressen vind ik de methode die in 2010 bij de BAG-import van Nijmegen is gebruikt het mooist. Daar zijn alleen losse nodes gebruikt as het niet anders kan. In eenvoudige gevallen zoals een huis met een enkel nummer is daar het nummer een attribuut van het gebouw.
Bedankt, ik zal dit regelmatig bijwerken, afhankelijk van hoe snel de import gaat.
Allereerst: Ik ben het met je eens dat het er soms niet mooi uitziet. Vooral niet in gemeentes die alle nodes op een plek zetten. Maar dit is een probleem van de renderer, niet van de data. Andere layers laten een rustiger beeld zien.
Dit probleem lost zich vanzelf wel op als er meer adresgegevens in OSM komen en meer mensen hier over klagen. Het is niet ondenkbaar dat er een renderer komt die zelf deze ‘samenvatting’ maakt.
De locatie van de nodes heeft wel degelijk iets met de locatie van de adressen te maken:
Vrijwel in alle gemeentes waar ik heb geïmporteerd is de locatie van de adres node een redelijk indicatie van waar de ingang van een gebouw is. Dit is de grote meerwaarde van een losse adres node. Daarnaast kun je bij meerdere POI in 1 pand, die nu netjes verdelen over de adres nodes.
In Haarlem is de node die het dichts bij de straat meestal de begane grond, hoe verder van de straat, hoe hoger de verdieping.
We uitgebreid gediscussieerd over wat we met de adres nodes gingen doen, misschien kan Johan je nog iets meer over de historie daarvan vertellen.
De import is een vrij ingewikkelde procedure. Ik ben er inmiddels vrij handig in geworden dus als je hier even laten weten om welk dorp het gaat, kan ik hem ook voor je inlezen?
Vraag over multipolygon gebouwen. Ik heb nu de tags meestal op relatie zitten maar het valt me op dat sommige tools (zoals vizicities) daar niet meer overweg kunnen.
Wat is nu de juist manier?
Hier een voorbeeld:
Huisnummer staan ook ‘los’ van gebouwen. Een gebouw kan meerdere huisnummers hebben en huisnummer meerdere gebouwen (lees:BAG nummers). Net zoals dat je een restaurant als losse node plaatst. Een gebouw kan immers meerdere functies hebben. Net zoals een woning die gesplitst wordt. Dan krijg je ineens meerdere huisnummers. Bovendien is het voor de routing wel erg handig dat je het huisnummer bij de broevenbus hebt. Dan hoef je niet een complete flat rond te lopen maar weet je bij welk portiek je moet zijn. Ook bij grote kantoorpanden erg handig. Een etage is een fysieke eigenschap van het gebouw, dat is iets heel anders.
Mail is verstuurd.
Bedankt voor het aanbod, maar liever doe ik eerst zelf een poging. Ik heb de handleiding al doorgenomen en het lijkt te doen. Indien het bevalt wil ik de rest van het eiland langzaamaan ook aanpakken.
Via het OSM [profiel](Sander | OpenStreetMap H) van een mapper kun je nagaan waar deze mapper woont, mocht je een oogje in het zeil willen houden.
Wel even een username_BAG acount aanmaken. Ongetwijfeld neem je stappen van de handleiding in acht.
Begin in het begin met kleine stukjes.
Veel succes.
Voel je vrij om mee te doen. Voorlopig denk ik niet boven de Noord-Brabantlaan te werken, maar verder Gestel en Stratum in te gaan.
Dus (ook aan Cavit): claim rustig een stuk Eindhoven dat je wilt doen.Ik heb eventueel een .osm met gebieden die ik heb gehad.
Momenteel ben ik nog steeds in Best bezig.
Ik schrijf de import gebieden weg in een polygons.osm bestand. Mijn doel is eerst alles binnen de stads/dorpsgrens van Best te doen.
Dit werk ik wijk voor wijk af. Mocht ik het daarna nog steeds leuk (of verslavend vinden) kijk ik ook naar andere plaatsen.
//offtopic, het werken met 2 monitoren is ook erg handig. Al mijn info vensters staan op mijn laptop scherm, en het werkvlak op een full-HD externe monitor die ik er boven zet. Dat is prettig meters maken 
Ik ben een plattelander, willen jullie rekening mee houden bij het trekken van polygonen, tussen twee dorpen dat het aansluitend is.
Ik zie dat veelal een dorp gepakt wordt met een stuk platteland, en dat er huizen tussen de twee polygonen vallen die niet wordt meegenomen.
Lastig om zonder kennis van gebruikte polygonen die tussengebieden aan te pakken.
Ben nu gekomen tot stap 2C.
Wat doen jullie indien de panden elkaar overlappen? De gegeven opties in de handleiding zijn niet toereikend. Ik heb nu een paar gevallen:
- pand (formaat “fietsenhok”) staat getekend midden in pand (woonobject)
- pand staat grotendeels overlapt met ander pand dat 80 jaar recenter is (gezien bouwjaar), dus waarschijnlijk schuur herbouwd
- exact overlappende ways waarvan het ene slechts pand is en de andere een verblijfsobject met gezondheidszorgfunctie
Ik ben sterk geneigd om respectievelijk fietsenhok te verplaatsen naast het gebouw en oudste pand weg te laten en panden samen te voegen (met BAG ID’s gescheiden door puntkomma)? Ofwel, naar beste inzicht aanpassen zodat het bij een volgende BAG update alsnog rechtgetrokken wordt.
Doen jullie terugmeldingen en hebben jullie daar al resultaat van gezien in BAG? Het formulier is nou niet echt het meest gebruiksvriendelijke om in te vullen.
Is het trouwens bewust dat de voorloopnul(len) van de BAG ID’s zijn weggelaten? De BAG Viewer en BAG Web (geraadpleegd als cross-check) willen perse 16 cijfers hebben.
Ik voel een workshop aan komen in de regio Best om die opstelling eens in werking te zien
Goed punt. Gertjan en ik hebben het ergens ‘back in’ december gehad over het opslaan van de polygonen op een centrale server. Mits de gebruikers van de plugin dat wel willen. Iets voor een volgende update Gertjan 
In alle drie de gevallen kies ik voor SHIFT-J waarbij ik alle ref:bag waarden bewaar, evenals alle bouwjaren. En met behoud van de gezondheidszorgfunctie in het derde geval.
Ik heb nog geen terugmelding gedaan, een paar anderen volgens mij wel
Het kan zijn dat de BAG viewer en BAG web afwijken van de BAG database. Volgens mij verwijdert de plugin geen voorloopnullen
Cheers, Johan
Hier verschillen de meningen nog over. Zelf ben ik geen voorstander van het samenvoegen van geometrieen. Daarmee introduceer je iets waarvan je bij voorbaat zeker weet dat het niet klopt. Dan kan je in mijn ogen nog beter beide panden laten staan, zodat je in ieder geval geen informatie weg gooit en laat zien dat er iets nog niet helemaal klopt.
Over de 3 gevallen:
Ih het eerste geval durf ik tegenwoordig het kleine gebouw (formaat fietsenhok) rustig weg te gooien.
Het tweede geval zou ook een verbouwing kunnen zijn. Met bij het grotere en nieuwere gebouw building=construction. Dan zou ik net als Sander het oude gebouw weggooien.
In het derde geval zou ik ook net als Sander het gebouw zonder gebruiksfunctie weggooien.
Gertjan
Het lukt mij niet om de plug-ins opendataservices en ods-bag te installeren. Wanneer ik opendataservices en ods-bag aanvink in de plug-in links en JOSM opnieuw start, krijg ik de volgende meldingen:
Could not load plug-in opendataservices. Delete from preferences?
Could not load plug-in ods-bag. Delete from preferences?
JOSM versie 6891, Java versie 1.6.0_30, opendataservices versie 0.4.10, ods-bag versie 0.4.10.
Weet iemand wat ik hier aan kan doen?