@Cartinus, volgens mij zijn de woorden “better” niet afkomstig van Frederik Ramm.
@Johan,
Volgens mij zet Frederik Ramm op dit moment nog geen kwaad bloed.
Net zoals je zegt, hij dreigt met het terugdraaien. Maar zegt tegelijkertijd dat hij terugdraaien wil voorkomen.
Hebben we zijn mail destijds niet (goed) ingeschat? Dat is de vraag op dit moment.
Hij was wel duidelijk in zijn standpunt dat er eerst concensus op punt 1 en 3 moest worden bereikt.
Persoonlijk denk ik dat een hertagging naar een nieuw te bereiken consensus een grote revert zal voorkomen.
Ik ben benieuwd of zulk een grote revert wel goed zal gaan ivm andere mutaties na de imports.
Zou Frederik ervaring hebben met zo’n terugdraai aktie? Of zou hij voor de (mogelijke) causaliteit instaan.
Nee dat zijn de woorden van Paul, die echter expliciet gequote worden door Frederik.
Het is heel makkelijk van alle heren in de DWG om consensus te eisen en dan vervolgens helemaal niet meer te reageren als Johan om argumenten vraagt. Het niet gebruiken van externe ID’s is bijvoorbeeld een stokpaardje van Frederik waar in de praktijk een hoop OSM’ers anders over denken.
Bovendien is het reverten van de hele import een veel te groot wapen als de enige tekortkoming de aanwezigheid is van drie tags die de heren niet aanstaan. Als die drie tags er echt niet in zouden mogen, dan is het een stuk simpeler om die drie tags weg te halen.
Frederik heeft hééél veel ervaring in het terugdraaien van exports en andere mass edits. http://www.openstreetmap.org/user/woodpeck_repair. Ik denk echter niet dat het bij iedereen buiten Nederland is doorgedrongen hoeveel handwerk en nacorrecties er bij deze import worden uitgevoerd.
Ik had ook nog niet gereageerd op de mail van Frederik. Wat mij wel buitengewoon irriteert is dat als je vragen stelt (Frederik) en daar een antwoord op krijgt (johan) het vervolgens ruim 2 maanden stil blijft.
Als je vind dat je tot een community hoort moet je communiceren en niet 2 maanden later er op terug komen en gelijk als een dictator dreigementen gaan uiten. Als er iets niet in een community hoort is het dat wel. Het gaat om concensus, niet wat één persoon vindt. Maar omdat ik me er zo aan ergerde leek het me goed niet meteen te antwoorden.
Daar heb ik ook al over nagedacht. Hoe maakt hij onderscheid tussen de BAG imports, de BAG imports met heel veel verbeteringen aan bestaande zaken, en de verbeteringen doorgevoerd na een import.
Ik doe alle drie de manieren (eigenlijk 1+3 of 2), afhankelijk of ik aan een aantal blokken werk en die eerst af wil maken met één grote nacontrole, of in een verloren halfuurtje nog maar eens een stukje.
In de (mijn) situatie van 2 gaan er een heleboel verbeteringen verloren, die lang niet altijd ook maar iets met de BAG te maken hebben maar rechtstreeks uit de validatie komen.
Daar ben ik ook erg benieuwd naar. Kan iemand aan mij uitleggen wat de verschillende inzichten en alternatieven zijn op dit punt 3
(svp even los van de consequenties, en los van de onhandige toon & toming van Frederik. Overigens eindigt Frederik wel met “please explain”, dus dat is sowieso handig om te doen)
Ik ben bezig met een reactie in twee stappen. Eerst een procesmatige vanuit mijzelf (hij valt mij aan op het proces), volgend weekend een meer inhoudelijke. Morgen stuur ik het concept van de eerste toe naar dit forum ter becommentariëring, ik wil die maandag- of dinsdagavond posten naar de import lijst cc de DWG. Ik organiseer aanstaande vrijdag 21:00 een Hangout voor de NL community, dan kunnen we -naast het forum- discussiëren over de tweede reactie.
Tip: mocht je nog niet zijn geabonneerd op de importlijst, meld je dan even aan. Kan altijd als backup van pas komen.
Een revert zal zeker niet doorgevoerd worden, ik zie de import dan ook graag in vol tempo doorgaan. Het grootste risico is dat we met een bot de ref:bag, de source en de source:date moeten gaan verwijderen. Want dáár gaat de inhoudelijke discussie over. Die gaat ook niet over het gebruik van de ref op zich.
In het verleden zijn er talloze imports geweest waarbij een voor beginners onherkenbare identificatie werd geplakt op nodes, ways en relations. Zoals onze eigen AND import. Die worden aanvankelijk aangebracht met een reden (vast wel eens nuttig), maar zijn achteraf nooit nuttig gebleken. Zo verwijder ik overal waar ik werk de AND_nosr tags. Vanuit die ervaring wil de DWG geen identificatienummers hebben.
De sourcetags vinden zij (alhoewel, in ieder geval Frederik) niet nodig omdat de source op de changeset staat.
Ik vind het vooral vervelend voor imports in het algemeen. Ik heb nog wel wat ervaring in politieke omgevingen, maar je moet het voor je hobby maar leuk vinden om een manier te vinden om om te gaan met het gedrag vanuit sommige DWG leden. Een van onze zuiderburen heeft in november vorig jaar al verzucht: “Thank you for doing the effort of trying to jump through all the hoops DWG are imposing. Personally, I’d have given up a long time ago… Thruth is, I didn’t even try, as I knew in advance it was a hopeless endeavour (I had been reading too much talk-fr, I guess).”
De ‘you’ was in dit geval een andere zuiderbuur die poogde een import door de importlijst te krijgen.
OSM mist volwassenheid op diverse fronten, waaronder een betere (meer transparante) manier om besluiten te nemen en een governance structuur.
Ik wilde er niet over beginnen want dit is één van mijn stokpaardjes in alle projecten die ik doe en gedaan heb en alle bestuurs- en beheersmodellen die ik in de afgelopen 25 jaar gezien heb (ik word echt een oude lul).
Er hoort een scheiding te zijn van uitvoering en macht zoals als zo’n 300 jaar geleden beschreven in de trias politica, en al eeuwen daarvoor benoemd.
In ons geval simpel gezegd: In elk ICT-systeem moet de “admin” die alle uitvoerende rechten heeft, niet de besluitnemer zijn. De admin heeft de “uitvoerende macht” en controleert, voert uit, adviseert, en corrigeert na besluitvorming door het “gerechtelijke orgaan” dat niet die uitvoerende macht heeft.
Frederik Ramm heeft allebeide, en in dit geval is alles ook nog verenigd in één persoon. Dat is ook waarom ik het dictatoriaal noemde.
Ik begrijp wel dat het zo gegroeid is en dat Frederik waarschijnlijk uit puur idealisme gedreven wordt, maar de situatie is niet correct.
Ik ga er echter ook van uit dat het niet zo’n vaart zal lopen maar het zet bij mij wel de stekels omhoog.
Ik ben het inhoudelijk meestal met Fred. Ramm eens (ook wat importen betreft) en heb grote waardering voor zijn inzet, maar in dit geval merk ik dat zijn interventie me mateloos irriteert. (En ik ben niet eens een van de mensen die aan de import werkt.) Daarom zal ik niet reageren en wacht rustig af wat Johan en anderen bedenken.
De laatste keer dat ik op talk (dus niet talk-imports) een uitgebreide discussie gezien heb over externe refs was er geen community consensus dat we ze nu niet moeten gebruiken. Vooral ook omdat de tegenstanders geen enkel alternatief aan weten te dragen voor het koppelen van OSM met externe data. Diezelfde mensen vinden namelijk dat OSM ID’s niet extern gebruikt zouden moeten worden. Dat zou betekenen dat de enige mogelijkheid tot koppelen complexe geo- en vormvergelijkingsalgoritmen zijn. Dat was voor veel mensen niet goed genoeg
@hvdwolf
Volgens de meest luidkeelse OSM’ers in de wereld is het niet alleen historisch zo gegroeid, maar zelfs heel goed dat de uitvoerenden aan de macht zijn. Daar hebben ze zelfs een woord voor “DoOcracy”. Ik zie daar voorlopig dus geen verandering in komen.
Weer wat geleerd. In de eerste link die ik tegen kwam (http://www.communitywiki.org/cw/DoOcracy) stond: “…A new campmate may grumble…”: Ben ik dat?
en ook: “…Older and wiser heads will say…”: Ben jij dat?
Wat mij betreft zouden ‘source=BAG’ en ‘source:date=’ verwijderd mogen worden, ik zie dit toch enigszins als ‘overbodige ballast’.
Juridisch gezien is ‘source=BAG’ volgens mij niet nodig, omdat (als ik het goed heb) de BAG-gegevens vrijgegeven zijn onder de publieke domein-licentie, waarbij een verwijzing naar de bron niet noodzakelijk is. En is het nu zó belangrijk om op ieder gebouw aan te geven dat het afkomstig is van de BAG? Overigens: momenteel is het de op twee na meestgebruikte tag: https://taginfo.openstreetmap.org/tags.
Wat is eigenlijk de precieze reden geweest van het toevoegen van 'source:date=’? Op dit moment zie ik daar niet zoveel positieve waarde van, maar misschien wordt het wel belangrijk wanneer de gegevens bijgewerkt worden.
Anders ligt het met ref:bag, wat natuurlijk zeker van belang zal zijn bij eventuele toekomstige bijwerkingen van de gegevens. Heeft iemand een idee hoeveel de kans is dat dit ook daadwerkelijk gebruikt gaat worden? Dus hoe groot de kans is dat de actualiseringen van de BAG ook daadwerkelijk bijgewerkt gaan worden in OSM?
Misschien erg voor de hand liggend; maar het voor iedere OSM gebruiker mogelijk maken een nieuwe versie (per datum X-Y-Z) te kunnen importeren met een relatie aan het bag:ref object? En geen decentrale lijst vormen met OSM-IDs en BAG-IDs zodat updaten vrijwel onmogelijk wordt. De BAG wordt maandelijks gepubliceerd. Alle data met bag:ref en een oude source:date zou dus langsgelopen moeten worden.
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.
Even een hele korte reactie op die “ik zou het jammer vinden jullie BAG import terug te draaien”: dat moet 'ie eens proberen. Ik heb genoeg moeite gedaan om de gebieden erin te krijgen die ik erin heb gekregen, en als ik naar andere mappers kijk is het niet eens zo gigantisch veel. Toch heb ik er behoorlijk mijn best op gedaan en ik vind de data heel nuttig (heb het zelf ook gebruikt). Als dat terug wordt gedraaid denk ik niet dat ik OSM verder nog wil supporten. Met deze post bereik ik waarschijnlijk enkel mensen die dezelfde mening hebben als ik, maar ik moet het toch even kwijt. Dreigen dit terug te draaien, wat een schaamteloze steek onder water.
Ik merkte het inderdaad. Mijn BAG zat er wel in, maar de wegen-update niet meer. Ben door de stad heen gereden op de terugweg van iets en kwam er toen achter dat het helemaal niet bijgewerkt was -.- Achja. Misschien dat ik de tijd vind een custom map erin te gooien, en anders wacht ik het gewoon rustig af. Heb weinig tijd voor OSM dezer dagen.
Ik vind de discussie steeds leuker worden (en dat bedoel ik absoluut niet cynisch!). De woorden van Harry over de trias politica komen bijvoorbeeld ongeveer 1:1 over met mijn ideeën. Jouw punt Sander over het nadenken door de DWG is een hele goede. Maar de DWG, of Frederik, (ik blijf dat onderscheid lastig vinden) zal dat niet gaan doen. Zie daarvoor deze posting van Frederik op een in mijn ogen logische oproep van Graham Jones: https://lists.openstreetmap.org/pipermail/talk/2011-June/058626.html. “Be warned that tagging is a field where consensus has usually not been reached, or sought, in discussions and decision-making processes, and we have often hailed that as a strength of OSM.”
Het gaat hem niet om de vorm van de tag. Het gaat om de aanwezigheid. Hij wil die nummers gewoon helemaal niet zien, omdat hij denkt dat er toch niemand iets mee doet.
Tags met vreemde namen en lange nummers zouden ook verwarrend zijn voor nieuwe gebruikers. Dat de iD-editor die tags verstop in een uitklapbaar lijstje dat die beginnende editors gewoonlijk toch niet openen, zal wel niet terzake doen.
Als je je de brouha over de Franse kadaster import nog herinnert dan herinner je je mischien ook dat hij al die gedetaileerde gebouwen sowieso maar vervelend vindt. (Een rechthoekje is genoeg.) Daar wordt het maken van de Geofabrik extracten langzamer van … Zie: http://osm.gryph.de/2012/06/openbuildingmap/
De discussie heb ik gedeeltelijk gevolgd. Voor mij lijkt het hebben van een koppeling tussen BAG en OSM er belangrijk (met welke tag dan ook).
Hiermee zou het mogelijk moeten zijn om een lijst te maken van gebouwen die wel in BAG staan, maar niet in OSM. En andersom.
Je legt dan in feite wel de eis op dat elk gebouw in Nederland (dat in de BAG staat) ook via een BAG import (met de juiste tags) ingevoerd moet worden.
Een gebouw dat iemand getekend heeft met building=yes en verder niets zal dan vervangen worden door een nieuw gebouw met de BAG tags.
Zelf lijkt me dat geen probleem.
