Idee om wat met BAG te gaan doen

Jan ā€¦ helemaal mee eens. We delen gelukkig wel de conclusie dat je niet zomaar ā€œPOIā€ achtige info uit (open)KVK kunt gebruiken om te concluderen dat daar ook die activiteit plaats vindt.

Dedicated import account

Ik ben begonnen met een tweede -dedicated import- account waarmee ik nu de BAG gebouwen importeer Ć©n de bestaande gebouwen opschoon:
http://www.openstreetmap.org/user/ligfietser_BAG/edits

In praktijk valt deze werkwijze reuze mee, je moet alleen in de gaten houden met welk account je de boel upload, maar afsluiten van JOSM hoeft helemaal niet. Onder hetzelfde account en in dezelfde changeset met het uploaden schoon ik de oude gebouwen meteen op (muv de gebouwen met extra tags). Zodoende kan de oude situatie hersteld worden mocht er iets misgaan.

Het toevoegen van extra tags op zoā€™n BAG pand (bijv amenity=school) doe ik nadat ik de zaak heb geupload. VĆ³Ć³r het uploaden van deze wijzigingen even in JOSM bij de instellingen de gebruikersnaam veranderen van user_BAG naar user (het is dan makkelijker om hetzelfde wachtwoord te houden dan hoef je die niet telkens opnieuw te typen, maar dat moet iedereen voor zich bepalen).

Voordeel van twee accounts is dat ik hiermee tegemoet kom aan de richtlijnen van de DWG en dat men bij latere updates snel terug kan vinden welke panden onbewerkt afkomstig zijn uit het BAG (met de user=username_BAG) en welke evt zijn bewerkt (user=username).

Om het proces een beetje uniform te laten verlopen is mijn voorstel om bij imports van BAG data dit te doen onder de naam username_BAG.

Op talk heb ik de parameter -Djosm.home= ter sprake gebracht. Als je twee shortcuts maakt om JOSM op te starten, kun je makkelijk wisselen. Je loopt kans dat je nl. vergeet om de settings aan te passen.
Uiteraard vond iemand het niet handig, omdat je dan de rest van de preferences moet synchroniseren. Dat hangt natuurlijk af hoeveel je ze gebruikt. Je kunt ook beginnen met de prefs dir naar de 2e lokatie te kopieren. Dan valt dat wel mee.

Ligfietser: het aanpassen van de tags na de import is inderdaad iets dat je beter met je eigen account kunt doen en niet met je BAG-account. Op die manier kun je de import en integratie beter scheiden.

V.w.b. je conventie: dat wijkt af van mijn eigen conventie _! :open_mouth: Jeeminee, wat nu? Discussieren op tagging? Dan loop je zelfs nog kans dat mensen daar serieus op ingaan :stuck_out_tongue:

Eens, jullie hebben hierin gelijk.

Prima voorstel. Zou je dat account eigenlijk ook niet moeten gebruiken om de vnl 3dShapes panden te verwijderen? Ik denk dat als je de import van BAG wilt terugdraaien (om wat voor reden dan ook) je ook het verwijderen van de 3dShapes data wilt terugdraaien.

De Geo-freaks hebben ook hier een oplossing voor :smiley: Anders komen objecten wel uit in de buurt van Parijs (oorsprong RD stelsel, de ā€œfalse originā€ noemen ze dit), of in de bocht bij Afrika (0,0 lat/lon). Je kunt niet zomaar verschillende kaartlagen over elkaar leggen zonder ze te herprojecteren. Veel software doet dit automatisch, als je de instellingen goed hebt staan. Ook kun je herprojecteren in veel databases (PostGIS, Oracle).

@Peewee het wissen doe ik ook onder de import naam omdat die twee handelingen onlosmakelijk aan elkaar verbonden zijn.
@Frank: sorry hoor maar in jouw tekst lees ik iets van xxx_import en ook sebas had het in een prive mail over username_BAG dus vandaar die naam; _ kan ik nergens vinden, waar haal je die vandaan?

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 :wink:

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 :wink: ) . 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 :wink: 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 :wink: 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. :slight_smile:

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.