Ach, ik was in een melige bui, vandaar de smilies. 
Dat lijkt me prima. Je moet erop kunnen vertrouwen dat anderen hun werk goed hebben gedaan. Verder ga je natuurlijk ook niet onder normale omstandigheden alle info checken. Dat is geen doen.
V.w.b. het gebruik van de accounts: bij 3dShapes hebben we in principe alleen het 3dShapes account gebruikt voor de daadwerkelijke import. Het omtaggen en het verwijderen van oud landuse (AND) hebben we met onze eigen accounts gedaan. Toen hadden we nog niet het probleem dat grote hoeveelheden bestaande data verwijderd moeten worden, wat nu aan de hand is met de 3dShapes gebouwen. Op zich zie ik geen probleem om dit met je BAG-importaccount te verwijderen, mits het versie 1 is en (dus) laatst gewijzigd is door 3dShapes. Dan kun je er ook van uitgaan dat er geen extra tags aanzitten. Bijgewerkte gebouwen kun je beter met je eigen account behandelen. En wanneer je constateert dat iemand behoorlijk veel de gebouwen gewijzigd heeft en/of tags heeft toegevoegd, neem dan contact op om hem/haar op de hoogte te stellen van je plannen en vraag of hij het resultaat wil controleren o.i.d.
Wat je allemaal doet onder het import account is afhankelijk van wat je als doel ziet van het account.
Wil je de mogelijkheid hebben om de import terug te draaien, dan moet je alle drie de stappen (import, tags kopiëren, oude gebouwen verwijderen) met het import account uitvoeren. Wat je vervolgens met je eigen account doet, zijn de “indirecte” correcties, zoals zorgen dat de wegen tussen de gebouwen door lopen en niet er dwars doorheen. Een andere “indirecte” correctie is bijv. de weilanden verwijderen waar nu een nieuwbouwwijk staat.
Wil je het import account alleen gebruiken voor het makkelijk terug vinden van ongewijzigde BAG data, dan moet je alleen de import zelf met het import account doen.
Ik geloof niet dat dat tweede het doel is wat de mensen van de DWG voor ogen staat.
Goeie vraag. Wat mij betreft is het doel als volgt:
Het verrijken van OSM met panden en adressen uit BAG. Gevolg: als BAG oude panden vervangt (meestal 3dShapes) dan zullen we die oude panden moeten verwijderen. De relavante tags van die panden willen we niet verwijderen uit OSM en dus zullen we die over moeten zetten op de BAG panden.
Nog korter: BAG panden invoeren, relevante tags van oude panden overzetten op het BAG pand en daarna dat pand verwijderen.
Wat mij betreft zijn AL deze acties het doel van de import account.
Dat kunnen we denk ik oplossen door eerst de BAG data (zonder overgezette tags) te uploaden en pas daarna de tags over te zetten en te uploaden. Door de laatste actie wordt het versienummer opgehoogd en is altijd te zien wat de oorsproonkelijke BAG data was. Bij de laatste actie zou je ook nog eens in de changeset aan kunnen geven dat het alleen om het overzetten van tags gaat.
Heren, er is wel sprake geweest van de invoering of het gebruik van JOSM en BAG. Maar van P2 is dacht ik geen nog geen sprake geweest, ben ik in de war of komt dat pas na de invoering en verwerking in beeld ?
Hendrik
Of zijn er ook dames actief en is heren niet op zijn plaats ?
Potlatch is helaas ongeschikt voor het massaal importeren van gegevens uit het BAG (kan alleen door handmatig overtrekken, in tegenstelling tot Josm, dat veel meer mogelijkheden biedt).
Dus helaas gaat het 'm dat niet worden en zal je Josm moeten aanleren mocht je geïnteresseerd zijn om mee te willen helpen.
Mede dankzij Peewee en Noordfiets heb ik een webkaartje tbv de BAG kunnen maken: http://mijndev.openstreetmap.nl/~ligfietser/BAG/
De import is in deze regio op een laag pitje komen te liggen ivm de ontwikkeling van het kaartje met fietstags 
Graag wil ik mijn omgeving aan de hand van BAG-informatie bijwerken. Mijn woonplaats Nijmegen is inmiddels voorzien van de nodige informatie (in ieder geval huisnummers), wie kan mij (opweg) helpen met de naast gelegen gemeente Overbetuwe en Lingewaard / dorpjes Oosterhout (gld.), Slijk-Ewijk en Bemmel?
De bag4osm osmosis plugin die Gertjan ontwikkeld heeft doet het bij mij niet meer als ik panden met adressen wil exporteren, en ik heb zelf nog geen tool ontwikkeld om de data uit de BAG te exporteren voor OSM.
Als tijdelijke oplossing voor individuele panden pluk ik de GML voor de feature uit de WFS service Tijdelijke BAG WFS en converteer deze naar OSM formaat met ogr2osm. Hiermee heb je alleen de geometrie van het pand, maar niet diens tags. De WFS service heeft niet de attributen die door de osmosis plugin gebruikt worden, dus kan niet als alternatief daarvoor dienen. Ook ontbreekt de adres informatie, die pluk ik weer uit de WFS service INSPIRE Adressen WFS. Je hebt dan een losse adres node ipv dat diens tags aan het pand zitten.
Het is allemaal erg omslachtig en kan het eigenlijk niemand aanraden het zo te doen, al helemaal niet als je een hele wijk wilt doen. Misschien heeft Gertjan een update voor ons?
Mijn werk aan de bag4osm plugin waar Sebastic het over heeft ligt al een tijdje stil. Hij kan nog niet overweg met het nieuwste BAG database model van nlextract.
De laatste tijd ben ik bezig met een plug-in voor Josm die BAG data rechtstreeks van een WFS server kan halen. Dit werk inmiddels goed, maar het resultaat geeft soms nog wel veel validatie-fouten. Dat hangt af van de betrouwbaarheid van de BAG data die de gemeente levert. Een veel voorkomende fout betreft overlappende panden. Er kan dus nog veel verbeterd worden aan de plug-in. Anderzijds is het proces al wel eenvoudiger dan wat Sebastic beschrijft.
Inmiddels heb ik MrCruiser al vast een stukje Nijmegen-Noord toegestuurd om mee aan de slag te gaan.
Gertjan
Het was even zoeken, hoe JOSM precies werkt, maar door de Youtube-uitleg van PeeWee heb ik het eerste blokje huizen op de kaart weten te krijgen! http://www.openstreetmap.org/browse/changeset/15789940
Smaakt naar meer 
Dat ziet er goed uit. Je ziet nu ook meteen dat de Spanjestraat ws een beetje uit het lood ligt. Ik heb vorig jaar een paar youtube filmpjes gemaakt om met andere betrokkenen even te overleggen hoe dit in het plan past. Je moet deze zien als een test al kunnen ze je wel op weg helpen. Ik heb het in zo’n filmpje bv ook over de associated street relaties maar die moet je gewoon negeren. Als Gertjan weer wat verder is dan pakken we de draad weer op om het proces te beschrijven. Succes met het vervolg.
Die mogen genoemd worden, deze zijn erg verhelderend. Een daarvan is hier te vinden:
Ik weet niet of het helpt maar de Nederlandse overheid heeft een informatieproject ontwikkeld om overheidsdata publiek aan te bieden. Deze dienst heet PDOK (www.pdok.nl) en bevat o.a alle huisnummers, woonplaatsen en panden als wms of wfs service. Misschien helpt deze informatie.
Bedankt voor de tip. Ik denk dat de meesten die hier regelmatig komen dit al wel wisten maar … beter een keer te veel dan te weinig gemeld.
Groet PeeWee
OSM inspector heeft een handige tool om te checken of de BAG data correspondeert met de straatnamen:
http://tools.geofabrik.de/osmi/?view=addresses&lon=5.42800&lat=52.19527&zoom=18&opacity=0.95&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads
In BAG zitten fouten. De meest hinderlijke is het verkeerd-om nummeren van straten.
Zie Soest, Bunder. Mijn TomTom gebruikt kaarten, die ook door BAG worden gevoed. Dus stond ik aan het verkeerde eind van de straat bij nummer 1… De leverancier van de kaarten in den Bosch zal het wel een keer bijwerken.
Hetzelfde overkomt me in Florence in mei 2013. Museo Garbello staat in een straat op nummer 4. Google Maps zet het museum bij de Dom neer, aan het andere eind van die straat. GoogleMaps heeft dit, na controle, binnen enkele dagen hersteld.
Als het PDOK een kind van BAG is, komen daar dus de zelfde fouten in.
Ook in het Westland wordt door de gemeenten het GIS slecht bijgehouden. Daar liggen soms huisnummers 500 meter verder dan de TomTom aangeeft.
Ook de NO-polder heeft daar last van! Er zijn ambulance-chauffeurs, import, die een adres niet met hun TomTom kunnen vinden.
Probleem is, dat een gemeente een ingevoerde GIS informatie niet controleert en zo nodig corrigeert.
Vandaar dat onze gewaardeerde OSM Postbode “Pensacola” een duidelijke taak heeft: Handhaving van de orde in de huisnummering en corrigerend optreden. Waarvoor bij voorbaat dank!!
@Dick,
Dat is nu precies waarom we graag zien dat de BAG in kleine hapjes wordt geïmporteerd door mensen met lokale kennis. Die kunnen dan namelijk meteen de fouten eruit vissen.
Maar het BAG mag van mij best fouten bevatten! Mijn WOZ-waarde is prettig laag!! Ik piep niet… Buren wel, omdat ze aangeslagen worden voor een garage, die ze niet hebben…
Ik heb even naar dit specifieke voorbeeld gekeken, maar de plaats van de huisnummers van de PDOK-service komen exact overeen met wat ik zie op Google StreetView (dus de fysieke huisnummerbordjes op de foto’s)…