Verwijderen nutteloze AND en 3dShapes tags

Ik ben daar niet ingedoken, maar zou de herkomst bij grootschalig importen behouden moeten blijven.

Zeker, maar deze tags dragen daar niet echt aan bij. Het is altijd mogelijk de historie van een object terug te halen (bv met CTRL-H in JOSM). En het gaat ook niet om de source= tags. Bij de AND import is die nooit gebruikt. de tag source=3dShapes komt wel voor. Maar hoeft van mij niet weg, omdat die duidelijk is voor mappers. In tegenstelling tot bv. AND_nosr_r (als er iemand is die weet wat dat betekent hoor ik het graag)

3dshapes:ggmodelk is een tag die ik gebruik in mijn scripts voor de OFM, aub niet deleten.
Wb die AND tags is de importance level ooit gebruikt om wegen te downgraden die te hoog zijn gewaardeerd tijdens de import, bv secondary naar tertiary. Het zegt ook iets over de source, die tag ontbreekt, dus als je alles weggooit kan je niet meer zien waar die data vandaan kwam (tenzij je dieper in de history gaat graven). Ben het wel eens dat de meeste AND tags overbodig zijn.

De 3dShapes:note tag zou ik niet verwijderen. Hierin zijn opmerkingen geplaatst, bijv. wanneer twee vlakken op een bladgrens niet op elkaar aansluiten, bijv. omdat de geometrie of het type landgebruik afwijkt, of omdat het deel op het andere blad ontbrak. Dat laatste kwam vooral bij gebouwen voor, maar die zijn ondertussen al vervangen.

BTW de tag AND_c ook niet wegdoen, die gebruik ik om overbodige plaatsnamen weg te filteren op de OFM.
Vaak staat er op een landuse=residential tags als place=town en name=* en AND_c=nummer en zo kan ik die herkennen.

Ik heb ooit eens bij veel van die AND shapes de boundary=* omgetagd naar AND_boundary, idem voor place naar AND_place en name naar AND_name.
Die mogen m.i. allemaal weg, ik had die tags ook kunnen deleten maar wist toen nog niet of ze nog nuttig waren.

Hi It’s so funny,

lijkt mij een goed idee ! Zo zijn we, na een juste afweging, gelijk van de twijfel af ‘kan dit wel of niet weg’ die af en toe als vraag wordt opgeworpen. Blijft slechts het risico over dat onbewerkte stukken niet worden geschoond :frowning:

Ik ben voorstander van zo veel mogelijk op te ruimen van die AND import. Als we een beperkt lijstje overhouden van te bewaren AND tags dan is dat wat mij betreft winst. Opgeruimd staat netjes ;).

precies wat ik dacht.

Al deze onbegrijpbare tags zijn bovendien erg verwarrend en intimiderend voor beginnende mappers.

Ik ben het met je eens dat het voordelen heeft om direct te kunnen zie waar de gegevens vandaan komen, zeker als het om een import gaat. Vooral bij 3Dshapes zie ik daar het belang van in. De AND data is echter al zover aangepast en geïntegreerd in osm dat de oorsprong er nauwelijks meer toe doet. wat mij betreft weg ermee.

Ik kan er niks aan doen, maar ik moest hier aan denken.

Automatisch verwijderen van de nutteloze tags lijkt mij ook een goed idee.

De wiki zegt over AND_nosr_r:

Als ik alle reacties (inclusief een die ik per DM kreeg) samenvat, dan lijkt het geen probleem om alle AND_… tags te verwijderen met uitzondering van AND_c. De beide 3dShapes tags zouden behouden moeten blijven.

T.a.v. AND_c. Reden om die te behouden is het wegfilteren van namen op landuse=… De kwaliteit van onze boundaries is (vooral dankzij een zeer actieve Amsterdammer) erg hoog. Mijns inziens zouden de landuse=… volledig gestript kunnen worden van tags. Voorbeeld van de Zeeuwse gemeente Oosterland: Die kent op de way met landuse=residential ook de volgende tags: AND_boundary=town, AND_c=10001877, layer=-1, name=Oosterland, place=village. Daar zou dus alleen de tag landuse=residential van overblijven.

T.a.v. 3dShapes:ggmodelk. Voor mij een onduidelijke naam. Gelukkig is deze tag goed gedocumenteerd op http://wiki.openstreetmap.org/wiki/NL:3dShapes/Details. De op die pagina beschreven tags voor gebouwen negeer ik even omdat bijna alle 3dShapes gebouwen zijn verwijderd met de BAG import. De 3dShapes:ggmodelk tags die resteren kennen een unieke tag, bijvoorbeeld landuse=forest. Oftewel: ik zie het nut niet in van het bewaren van de 3dShapes:ggmodelk tag. @Ligfietser: graag uitleg waarom je deze tag in OFM nog nodig hebt. Plus de suggestie om, als het écht uniek zou zijn, de tag om te zetten naar een meer simpele naam.

T.a.v. 3dShapes:note. Deze naam vind ik op zich wel begrijpelijk. Gecombineerd met de argumentatie van fsteggink kan ik me voorstellen om deze tag te behouden.

Verwerking: een alternatief voor de methode die ik in mijn eerste berichtje op deze thread had beschreven is het verwijderen als Mechanical Edit. Daarvoor moet een pagina op OSM worden aangemaakt met een apart useraccount. Ik denk dat dat met ons relatief kleine land effectiever is dan alle JOSM gebruikers lastig vallen met deze verwijderingen onder hun eigen usernaam. Die verwijderingen zou ik dan op me kunnen nemen met een account als ‘It’s so funny_mechanical’.

Graag reactie!

Mijn zegen heb je (graag zelfs) maar wacht de reacties even af. Misschien ook een mailtje naar de mailinglist?

Je hebt gelijk, bij de gebouwen werd er onderscheid gemaakt in verschillende categorieën maar die zijn nu allemaal vervangen. Ik gebruik het ook bij polygonen die eerst waren getagd met natural=water maar later door iemand foutief heeft omgezet in waterway=canal of river. Als er zo’n 3dShapes:ggmodelk tag op zit dan weet ik dat het een polygoon is met natural=water. Nu is dit filter voor de OFM ook niet meer nodig nu mkgmap onderscheid kan maken in lijnelementen en gesloten polygonen, dus in feite is 3dShapes:ggmodelk niet relevant meer. Wat mij betreft mogen alle 3dShapes:ggmodelk waar geen source tag (meer) op staat omgezet worden naar source=3dShapes.
Dat lijkt me beter te kunnen met een mechanical edit, want dan wordt dit uniform over het hele land gelijk getrokken en niet toevallig waar mappers zitten die met JOSM bezig zijn.

Wb het strippen van alle landuse=* van alle tags, hiermee ga je zeker relevante informatie weggooien, niet doen!
Bv parken met een naam, wijken met een naam, namen bedrijventerreinen etc. En mogelijke andere relevante tags.
Of bedoel je alleen landuse=residential? Sommige residential polygonen hebben alleen betrekking op wijken of buurten, waarvan de naam wel moet blijven staan. Dus zondermeer overal de name weghalen lijkt me niet juist. Place tag bij landuse=residential mag m.i. wel weg.

Wat mij betreft mag AND_c ook weg als dit gepaard gaat met het (mechanisch) verwijderen van de name tag bij landuse=residential.
Dan hou je nog een aantal met name grotere plaatsen over waar men de AND_c tag al heeft gestript, maar daar kan men tzt handmatig de name tag verwijderen, zie http://overpass-turbo.eu/s/5ot

Volgens mij is er nu consensus over:

  1. het verwijderen van alle AND_ tags
  2. het strippen van landuse=residential waar een AND_c tag op zit tot uitsluitend de tag landuse=residential. Bij alle namen (soms te zien bij wijken/buurtschappen) waar nog geen losse node van is zal ik een losse place node aanmaken
  3. het omtaggen van 3dShapes:ggmodelk tot source=3dShapes
  4. het behouden van 3dShapes:note
  5. het omzetten door middel van een mechanical edit

Ik heb de account It’s so funny_mechanical aangemaakt voor deze omzettingsslag. Als er nog andere vrijwilligers zijn die willen helpen: welkom!

Als ik je goed begrijp bevat de OSM database polygonen die ten onrechte zijn voorzien van waterway=canal of waterway=river en corrigeer je die fout in OFM. Is er een reden te bedenken waarom die correctie niet in de OSM database doorgevoerd zou moeten worden?

Lijkt me prima zo’n mechanical edit die de boel een beetje opkuist. De reden voor die correctie was dat te pas en te onpas beginnende mappers die waterways gingen omtaggen omdat Potlatch alle vlakken met natural water als “lake” betitelde ipv kanaal of rivier. Dus de fout zat 'm in de editor (die niet meer wordt onderhouden). Je kan de zaak dan wel corrigeren in de database (wat ook gebeurde) maar die fout werd continu gemaakt dus dan blijf je aan de gang, vandaar dat ik dat repareerde in mijn kaart. Ik heb liever een goede kaart dan dat ik eerst moet wachten totdat iemand die fouten gaat repareren.

Nu is deze correctie nauwelijks meer relevant want
a) mkgmap kan nu zien of een polygon is gesloten, dus als er waterway=canal staat vult die de polygon met water ipv dat het een blauw lijntje is (maw de rivier staat dan droog)
b) de standaard editor is ID en de Potlatch gebruikers van toen zijn nu hopelijk meer ervaren

Ik kreeg per DM een reactie binnen over de wijze van verwerken van de correctie door middel van een mechanical edit. Dat verstoort namelijk de statistieken, bijvoorbeeld in de vorm dat It’s so funny_mechanical dan de last editor wordt op http://hdyc.neis-one.org/ in plaats van de mapper die op basis van survey wegen heeft aangepast.

Laat me weten als dit problematisch is. En bij voorkeur ook met een werkbare oplossing om de correctie dan wel doorgevoerd te krijgen.

Hi Itssofunny, jij had of hebt het initiatief, als jij het met instemming optuigt krijg jij het krediet, yep. Je kunt, als het je bezwaard, het eventueel verdelen, maar hoe ?

Ik begrijp hun probleem niet. Als jij of ik op persoonlijke titel wat van die overbodige tags weg ga halen ben je toch ook de last editor?
En als dat als filter in Josm wordt ingebouwd gebeurt precies hetzelfde, dan is het de mapper die in dat gebied actief is geweest.

Ik zie geen rede om die tags systematisch weg te halen. Ze zijn misschien nutteloos maar ze doen ook geen kwaad. Ik haal deze tags natuurlijk weg als ik ze tegenkom maar ik raak geen objecten aan alleen om die overbodige tags te verwijderen.

Een systematisch verwijdering van deze tags is een mechanical edit, due de regels van de OSMF zijn van toepassing, zie http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy

Zoals eerder werd vermeld: “U mag deze tag gerust verwijderen wanneer u het tegenkomt bij het kaarten maken. Zoals met alle andere tags die echt overbodig geworden zijn (zoals created_by) verwijder ze niet doelbewust, omdat dat de hoofddatabase van OpenStreetMap onnodig belast. (Een verwijdering creëert ook een nieuwe versie in de geschiedenis.)”

Het is maar de vraag of ze geen kwaad doen. Deze thread is begonnen door een opmerking van een Duitse mapper over deze tags. Vanuit mijn persoonlijke perspectief vind ik deze tags ook niet zo’n probleem. Maar als ik in de schoenen van een buitenlandse mapper of een beginnende mapper ga staan, dan kan ik me voorstellen dat deze tags niet helpen om OSM in Nederland te begrijpen

Die mechanical edit policy ken ik (ps er is een concept versie, die dus nog niet definitief is, en er is een andere definitieve versie). Ik denk dat de belasting van de hoofddatabase van OSM aanmerkelijk geringer zal zijn dan de belasting die de BAG import heeft veroorzaakt. Dat een verwijdering een nieuwe geschiedenis creëert: dat klopt, maar dat is het hele OSM model. Ook Paul Norman (DWG) doet niet een slimme truc om een nieuwe historie in mechanical edits te vermijden.

Het gaat hier om het doel: willen we gastvrij zijn voor beginnende mappers en buitenlanders, of vinden wij Nederlandse experts dat niet relevant?