Maar het is toch juist handig om de term BAG in de accountnaam te hebben omdat er meerdere mensen met BAG bezig zijn. Die zijn dan makkelijk te herkennen. En als je straks klaar bent met de import van BAG dan neem je gewoon een nieuwe accountnaam voor de volgende database die je in OSM importeert 
Ok. Dan blijft bij het invoeren van de BAG data alleen nog het overzetten van tags van het oude (3dShapes) naar het nieuwe (BAG) pand over. Je kunt je afvragen of je dat ook niet onder de BAG account moet doen. Het is immers geen data die jij ooit in OSM hebt ingevoerd (al zullen die er ms ook wel bij zitten). Als later iemand je aanspreekt waarom je een pand een bepaald tag hebt gegeven kun je in ieder geval zien dat het met de BAG import te maken had. Als we het hier over eens zouden worden dan hoeven we sec voor de BAG import alleen maar het BAG account te gebruiken en niet je eigen account. Wel zo makkelijk lijkt me.
Daar ben ik het niet mee eens. Er van uitgaande dat een mapper in zijn eigen gebiedje importeert, neem ik aan dat als jij een bepaalde tag van het 3dshapes pand verplaatst naar het BAG pand, je dat ook doet met lokale kennis.
Dan heeft die tag dus niets met de oorspronkelijke BAG data te maken (het komt ook niet uit die database) en dient dus ook niet met die dedicated account te gebeuren.
Laat ik een voorbeeld geven van wat ik gedaan heb. Ik heb in een aantal wijken in Leusden oude panden door BAG vervangen. Daarbij oude tags overgezet op nieuwe BAG panden. Daar zaten bv een aantal scholen bij (building=school, name=*). Ik weet wel dat dat een school is maar wat precies de naam is…? Die tags heb ik gewoon overgezet zonder te verifieren of die school ook echt zo heet of niet, dus inclusief evt spelfouten… Het is mi ondoenlijk om een wijk of stad aan te pakken als je echt alles moet gaan controleren dat anderen hebben toegevoegd. Ik vergelijk de situatie voor en nadat ik een wijk heb aangepakt. Daar is qua tagging niets veranderd behalve dat het ene pand vervangen is door het andere. Dat lijkt mij juist de bedoeling van de actie om 3dShapes panden te vervangen door BAG. Niet meer en niet minder. Als die mapper ook nog eens de boel wil opschonen (graag zelfs want je ziet soms wel rare dingen) dan kan dat toch gewoon daarna onder zijn eigen account?
Ik heb ook eens in bv Amsterdam wat bekeken maar daar zie je bv tags als alt_name:es=* Ik ben benieuwd hoeveel lokale mappers weten of dat juist is.
Kunnen we het lokale mappers die bereid zijn oude panden te vervangen door BAG wel aandoen om deze extra controle van alle tags uit te gaan voeren? Ik ben bang dat het dan wel heel lang gaat duren voordat we klaar zijn.
edit: misschien moet de dedicated account niet alleen het woord BAG bevatten maar meer : replace_old_building_with_BAG_data_without_deleting_info… (Ok is wat lang maar de bedoeling is duidelijk ) . Op huidige 3dShapes panden zie ik ook allerlei tags die later zijn toegevoegd maar de source is nog steeds 3dShapes.
The source wel maar de user is een andere mapper dan 3dShapes. Als je allerlei tags gaat toevoegen uit OSM is het niet meer de oorspronkelijke BAG data en daarom wilde ik een verschil maken tussen het dedicated import account en je eigen OSM account. Als je aan een gebouw gaat editten die een ander getagd heeft met een spaanse naam, doe je dat toch ook uit eigen naam zonder vaak te verifiëren of die Spaanse naam klopt?
Volgens mij heb je helemaal geen zin om twee accounts te gebruiken maar het wordt nu eenmaal opgelegd dus moeten we ook de voordelen ervan benutten, als je weer alles op een hoop gooit kan je tzt niet meer zien wat oorspronkelijk een bag tag was en wat een mapper heeft toegevoegd.
Je kent met goed. Ik ben liever lui dan moe maar ik begrijp heel goed het nut van een aparte account als je BAG wilt invoeren. Dat is het punt niet. Waar het om gaat is dat ik er moeite mee heb dat een lokale mapper alle tags zou moeten contoleren die hij gaat overzetten van oud naar nieuw. Als je dat toch gaat doen dan snap ik dat je dat eigenlijk niet onder speciaal import account wil doen (al heb ik daar niet heel veel moeite mee maar goed). Ik stel dan ook voor om:
Alle tags (exclusief addr: etc wat al in BAG zit) over te zetten met je eigen account zonder alles te verifieren. In de changeset dan wel aangeven dat je dat op die manier gedaan hebt. Voorstel: “transfered old building tags to new building”
Alle lokale tags blijven toch gewoon liggen op dezelfde plaats? Alleen het gebouw eromheen vervang je, dus in feite komt dat op hetzelfde neer als een weg editten waar meerdere mappers aan hebben geedit. Als ik een fietsstrook toevoeg aan een weg en jij hebt er een maxspeed tag opgezet ga ik echt niet verifiëren of dat zo klopt, ik neem gewoon aan dat jij je best hebt gedaan.
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: