Eigenlijk helemaal mee eens, want op welke tag(s) slaat de source? Soms zie je ook nog amenity:source, maxspeed:source, … of source=3dShapes;Bing;survey. Dan denk ik dat het taggen van sources ook wat ver is doorgeslagen. Hoe/wat/waarom staat inderdaad ook in de changeset comment.
Zijn wel leuke statistieken uit te halen bij [source=BAG | Tags | OpenStreetMap Taginfo]](source=BAG | Tags | OpenStreetMap Taginfo]) filteren op start_date.
Wel erg veel huizen gebouwd in het jaar 1005. Via OverpassTurbo te zien dat ze allemaal (op 1 na) uit de binnenstad van Amsterdam komen. Postcodegebied 1005 zijn Amsterdamse postbussen. Of moet het 1905 zijn (wegens herbouw nav grote brand in 1904). Er is vast iets misgegaan ergens, maar wat?
Ik ben ook wel nieuwsgierig of hier al over is nagedacht of zelfs al aan gewerkt wordt. Eventueel wil ik hier ook wel een steentje aan bijdragen. Een optie toevoegen aan de plugin waarbij bestaande BAG panden niet in de ODS laag terecht komen en verwijderde BAG panden in de OSM laag gemarkeerd worden met tag “bag=verwijderd” (zodat ze handmatig met een filter verwijderd kunnen worden) zou al een aardige eerste stap zijn om kleinschalige handmatige updates mogelijk te maken zodat bijvoorbeeld gemakkelijk en vrij frequent de voortgang in een nieuwbouwwijk kan worden verwerkt zonder teveel last te hebben van reeds ingevoerde BAG panden die er al wel staan.
Uiteindelijk denk ik dat toegewerkt kan/moet worden naar een geautomatiseerd script dat maandelijks heel Nederland doorloopt en bij conflicten bijvoorbeeld automatisch Notes aanmaakt (en op termijn zelfs terugmeldingen naar BAG kan doen) zodat wij enkel nog gericht corrigerende acties hoeven te doen. Want we zijn nu wel met z’n allen druk bezig om de initiele BAG in OSM te zetten, ik denk niet dat we iedereen zover kunnen krijgen om periodiek (niet maandelijks en zelfs niet jaarlijks) heel Nederland steeds maar weer onder handen te nemen. Daar gaat op de lange duur gewoonweg geen animo voor zijn.
Door aan de DWG te laten zien dat we ook voor de beoogde BAG updates niet alleen goede ideeen hebben (die heeft iedereen tenslotte), maar ook de tools om het daadwerkelijk voor elkaar te krijgen levert wellicht ook een stuk meer “krediet” op voor onze manier van taggen en dat indien de ref:BAG ook daadwerkelijk actief gebruikt wordt en een essentieel onderdeel is van het Nederlandse deel in OSM het ook gemakkelijker toegestaan gaat worden.
Wellicht voor de DWG het import plugin handleiding ook in het Engels vertalen zodat ze beter kunnen zien wat we allemaal uitspoken met OSM en daarmee meer begrip van hun kant voor onze werkwijze. Ook is dit wellicht goed voor kennisdeling naar andere landen toe waar ze ook aan de slag willen gaan met hun lokale BAG equivalent. Er is toch best een werkwijze bedacht die tot op heden best goed blijkt te werken en ook redelijk uitgekristaliseerd is inmiddels.
Indien een tag met “ref” toch gevoelig blijkt te liggen zou de DWG eens na moeten denken over een generieke internationale tag voor dit soort koppelingen (ondanks dat ze het liever niet willen), bijvoorbeeld building:ref, external_ref of iets dergelijks met waarden als bijvoorbeeld : (BAG:0123) of ::>id>. Nu krijg je wildgroei vanuit diverse kanten terwijl dat best gestandaardiseerd kan worden. Steeds meer overheden maken steeds meer gegevens openbaar, dus het gaat toch op een gegeven moment wel opduiken in OSM. Dan kun je in mijn ogen beter nu al regels en standaarden maken om het in goede banen te leiden ipv steeds maar nee blijven roepen.