Verwijderen nutteloze AND en 3dShapes tags

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?

Ik ervaarde deze onlogische tags ook als zeer verwarrend in mijn begintijd. Ik zou een voorstander zijn voor opruimen.

  • Wat maakt het uit dat er een extra mutatie regel komt, hier zal de database niet van overlopen.
  • Net als It’s so funny al zegt, de uploads van de BAG import waren belastend voor de OSM server, toch hebben we allemaal profijt van. En eerlijk gezegd, hier is de server toch ook voor. Ik ken veel mensen die niet mappen die zeer lovend zijn over de OSM na de BAG import. Laten we blij zijn met de aankondiging van Stefan over de sponsoring upgrade van de Nederlandse tileserver infrastructuur en mirror faciliteit.

Met het tweede ben ik het niet eens. Wanneer je nu twee wegen combineert die stammen van de AND-import (en bij de import zijn allemaal kleine delen geïmporteerd, waardoor heel veel straten samengevoegd kunnen worden!), dan krijg je in JOSM steeds de melding welke tags je op de gecombineerde weg wilt hebben. Niet echt handig… Opgelost kan dit inderdaad worden door de betreffende sleutels toe te voegen aan de lijst in JOSM, zodat ze automatisch verwijderd worden (net zo als dat nu gebeurt met bijvoorbeeld “created_by”).
Even voor de duidelijkheid: dit betreft de voorkeur “tags.uninteresting” in JOSM. Je kunt zelf proberen hoe dit werkt door de betreffende sleutels toe te voegen aan het lijstje; bewerk je dan een weg met die sleutel, wordt deze automatisch verwijderd. Zou op zich een mooie oplossing zijn…

Toch denk ik dat het beter is om de genoemde sleutels in één keer te verwijderen. We zijn er dan in één keer vanaf, maar ook in de andere editors zijn er geen problemen meer (bij de hierboven beschreven methode worden de sleutels alleen in JOSM verwijderd). Over de genoemde verstoring van de statistieken zou ik me echt niet druk maken, OSM gaat om de data en statistieken zijn slechts een bijproduct. De belasting van de server lijkt me ook niet zo’n probleem, het enige nadeel zou wellicht inderdaad zijn dat er van alle betreffende wegen een nieuwe versie komt. Dat zij dan zo…

Wat mij betreft mogen de sleutels verwijderd worden, ook al zal er bijvoorbeeld wat betreft de gerenderde kaart geen verschil zijn, maar het ruimt de database wel mooi op!

In post #15 van deze thread had ik aangegeven om het volgende te gaan doen:

  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

Dat ben ik nog steeds van plan om binnenkort uit te voeren, zij het dat na enig heen en weer mailen over met name statistieken ik toch maar heb besloten om de tags AND_nosr_r en AND:importance_level pas in december te doen. Daarmee krijgt iedereen die dat wil tussen nu en eind november de tijd om deze beide tags zelf te verwijderen.

In het geval dat er al een source tag staat (anders dan source=3dShapes) ben ik er voor deze te behouden.

“Enig heen en weer mailen over met name statistieken” is wat mij (DM) betreft iets te kort door de bocht. Statistieken op zich zijn niet relevant (geen doel op zich), maar wel de werkelijkheid die door statistieken worden weergegeven.

Dat lijkt een goede oplossing, waarmee gedeeltelijk aan mijn (DM) bezwaren tegemoet wordt gekomen
Nadeel is dat de historie mogelijk nóg verder vervuild raakt met meerdere Changesets per Object. Althans indien en voor zover er highways bestaan zonder een van deze twee tags, maar wel met andere AND* tags. Veel lijken dat er niet te zijn.

Om mijn eigen bezwaren tegen deze opschoningsactie te kwantificeren heb ik vanavond even alle AND* tags op alle highways virtueel (dus nog niet echt) verwijderd.

(1) Overpass (http://overpass-turbo.eu/): Query per highway type:

 <query type="way">
   <!--
     Select Author, user name is case sensitive
     <user name="YourName"/>
   -->
   <has-kv k="highway" regv="cycleway"/>
   <has-kv k="AND_nosr_r"/>
   <bbox-query {{bbox}}/>
 </query>
 <query type="way">
   <!--
     Select Author, user name is case sensitive
     <user name="YourName"/>
   -->
   <has-kv k="highway" regv="cycleway"/>
   <has-kv k="AND:importance_level"/>
   <bbox-query {{bbox}}/>
 </query>
 <union>
   <item/>
   <recurse type="down"/>
 </union>
 <print mode="meta"/>

(2) Overpass: Exporteer Data naar JOSM

(3) JOSM: Search for objects, Search string = highway:cycleway
(Filter dus nogmaals om gevonden Nodes en Polygonen buiten deze Changeset te houden)

(4) Verwijder alle AND* tags binnen deze selectie.

Voor grote recordsets: selecteer voor de query eerst Noord-Nederland t/m Utrecht en daarna Zuid-Nederland onder Utrecht. Exporteer beide queries naar JOSM, zodat er binnen JOSM één Selectie en dus één Changeset wordt aangemaakt.

Herhaal dit voor alle highway types. Eventueel kunnen kleinere sets worden gecombineerd, bijvoorbeeld:

Dit levert de volgende aantallen op:

 cycleway = 3.530
 track  = 3.073
 path = 302
 footway = 1.322
 pedestrian = 1.711
 living_street = 296
 bridleway = 7
 residential = 7.676
 service = 6.075
 unclassified = 117.146
 secondary = 17.829
 tertiary = 46.706
 primary = 271
 motorway = 16
 trunk = 34

Totaal: 205.994 highways.

En dit zijn alleen de highways. Overige Ways, Nodes, Polygonen zijn niet meegeteld.

Geldt voor deze aantallen: “op persoonlijke titel wat van die overbodige tags weg halen”?

Of wordt hier in één klap een enorme hoeveelheid relevante informatie, Author, de laatste “survey_mapper”, verplaatst naar de historie en verwijderd als primaire property van een highway?
Waarna het niet meer mogelijk is (althans ik kan het niet) om op (historische) “Author” te selecteren.

Hierbij wordt geen inhoudelijke wijziging doorgevoerd, het is nog steeds dezelfde highway met dezelfde properties, dezelfde bochten, dezelfde lengte, dezelfde routering.
Alleen de Author is gewijzigd en een aantal overbodige tags zijn verwijderd. En juist de Author zou ongewijzigd moeten blijven in het geval van een niet inhoudelijke wijziging.

Bijna héél Nederland staat na deze correctie op naam van “It’s so funny_mechanical” met uitzondering van de gebieden waarin “It’s so funny” (vooral) actief is en “AnkEric” ooit (vooral) actief was.
En nee, ik vind dat niet grappig :confused:

De selectie op basis van Author (laatste “survey_mapper”) beschouw ik als relevant voor:

  • Het corrigeren van eigen fouten
  • Het corrigeren van fouten van anderen
  • Kwaliteitsaanduiding van Tags tijdens mappen (“Mijn” JOSM toont altijd een “List of people working on the selected objects”: Authors)
  • Kwaliteitsaanduiding van Tags tijdens renderen
  • Kwaliteitsaanduiding van Tags tijdens de beoordeling van een gemaakte route.
    Sommige Mappers vertrouw ik blindelings, met sommige anderen ben ik het vrijwel nooit eens. Juist van deze laatste groep verwacht ik niet dat zij tussen nu en eind november deze beide tags tags (AND_nosr_r en AND:importance_level) zelf zullen verwijderen. Het is de vraag of zij via dit forum of de mailing list bereikt worden en zij gebruiken waarschijnlijk geen JOSM. En vooral van deze groep vind ik het belangrijk dat zij als Author bewaard blijven.

Statistiek is zeker geen doel op zich, maar het geeft wel inzicht.
Zeker in het begin vond ik het leuk en stimulerend om te zien hoeveel wegen, nodes en relaties ik had gewijzigd, toegevoegd of verwijderd.
De verhouding [“last modifier of” / “modified”] (http://hdyc.neis-one.org/) is een kwaliteitsaanduiding voor een specifieke mapper. Hier word ik afgestraft voor het feit dat ik te lui ben om [surface=asphalt] aan een cycleway toe te voegen. Maar meer relevant: hier zag ik ook dat ik structurele fouten maakte die door anderen werden gecorrigeerd. Leerpunt en dus nuttig.

Ik heb in het verleden zelf ook de fout gemaakt om van alle data rondom mijn - binnen JOSM geïmporteerde - tracks alle AND* tags te verwijderen. Gevolg is dat een groot aantal wegen ten onrechte op mijn naam is gezet. Ik heb deze wegen nooit expliciet bekeken.
Mea culpa: ik was een “Remote Mapper” ofwel “Armchair Mapper”. Misschien mag ik hier wel nog het woordje “ook” toevoegen…

Ik heb “It’s so funny” voorgesteld om de mogelijkheid te onderzoeken om deze data te verwijderen zonder dat hierbij de Author wordt gewijzigd én zonder dat de historie wordt vervuild met een historie op overbodige tags.
Zodra overbodige tags op deze manier worden verwijderd wordt hiermee én de database daadwerkelijk geschoond én het informatieniveau van de resterende data verhoogd.
Maar: *“Ook Paul Norman (DWG) doet niet een slimme truc om een nieuwe historie in mechanical edits te vermijden”.
*Hiermee lijkt het alleen mogelijk te zijn om deze overbodige tags op een onherstelbare en schadelijke manier te verwijderen.
Vervuiling van de historie.
Verlies aan informatie!

Ik hoop alleen wel dat er per Object (Node of Way) maximaal één Changeset aan de historie zal worden toegevoegd (en niet x Changesets voor x gevonden AND tags per highway).

als je toch bezig bent; “layer=-1” mag ook van de “landuse=residential” af

Daar zou ik toch voorzichtig mee zijn. In een ideale wereld sluiten alle “landuse=residential” gebieden netjes op elkaar aan en is er nergens overlap. Helaas is de werkelijkheid anders en is er veel overlap. In de meeste gevallen weten de rederers heel aardig in te schatten welke landuse bovenop moet komen te liggen. In sommige gevallen gaan de rederers de mist is, en heeft een mapper layer=-1 gebuikt om dit op te lossen. Mappen voor de rederen is natuurlijk niet netjes, maar de layer=* tags geven nu wel informatie over welke landuse ‘bovenop’ moet komen te liggen.

Gertjan

Kan het zijn dat door het verwijderen van overbodige 3Dshapes en verwijderen AND -tags water … het water uit het Merwedekanaal en de Zederik is gelopen? De multipolygonen zijn op veel plaatsen onderbroken.
Nou zag ik ook dat iemand van sommige multipolygonen slootjes (drains) had gemaakt.
Voorlopig heb ik over het kanaal en de Zederik nieuw natural=water getekend en de multipolygonen maar gelaten voor wat ze waren. 'k Kan eigenlijk niet zien in " Who did it" wie hier gesleuteld heeft.
Johan … Heb jij hier iets gedaan middels Mechanical edit?

http://www.openstreetmap.org/history#map=17/51.91922/4.99873

Het water is inmiddels weer terug. de eilandjes heb ik in de nieuwe relatie opgenomen. In de mapnik was het gisteren alles grijs.

Mechanical edit: removing AND_w tags (water) when a waterway=* tag is present

ongeveer 20 uur geleden gesloten door It’s so funny_mechanical · #26202247

Mechanical edit: removing AND_w tags (water) when a natural=* tag is present

ongeveer 20 uur geleden gesloten door It’s so funny_mechanical · #26202148

eggie

is dit nu werkelijk zo ? Ik hoor daar steeds maar tegenstrijdige verhalen over dat die layer op landuse wel dan niet zou gebruikt worden. Kan er mij iemand bv. naar de lijnen in carto css verwijzen waar dit echt in rekening gebracht wordt ? Ik zou er nu wel eens het fijne willen van weten.

ik heb gisteren de AND_w tags verwijderd. En ook af en toe een lege polygon zonder zinvolle tags (bv de combi AND_w en history=retrieved from v5). Ik heb net een backup van de door mij geselecteerde AND_w polygons gecheckt. Daar stond het Merwedekanaal niet op (die bevatte dus geen AND_w tag). Vervolgens heb ik een backup van eind september gecheckt, want ik kwam er met de history van Potlatch (1) niet uit. Zo te zien is er een aantal weken geleden iets mis gegaan met deze relatie: http://www.openstreetmap.org/relation/1100678/

Momenteel is sprake van een dubbele op elkaar liggende waterpolygoon: een gebroken relatie (1100678) en een nieuwe waterweg (30844080) met een nieuwe relatie (4119134) die niet helemaal goed is omdat die relatie geen tags kent behalve type=multipolygon. Het lijkt mij beter dat er nog wat opruimwerk wordt gedaan zodat de dubbelingen worden verwijderd. Wil jij dat oppakken of zal ik dat doen?