Verwijderen nutteloze AND en 3dShapes tags

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?

Hoi,

Ha Johan,
Jij bent van het opruimen heb ik begrepen. :smiley:
Voor het grootste deel heb ik het water al hersteld. 'k zal waar nodig de boel nog fatsoeneren. Als jij wat wil opruimen…graag.
'k Was daar op weg van Dordt naar Veenendaal aan het mappen en zag thuis pas dat de boel leeg stond.
Hier nog een rotonde aangepast. http://www.openstreetmap.org/#map=18/51.90034/4.99538 Tot hier liep het leeg. In de mapnik kun je dat nog zien bij inzoomen.

Het gekke is dat in de OFM van 18 okt er gewoon water is. Alleen in de mapnik was het Merwedekanaal tot aan Zijlkade leeg en dat stuk Zederik vanaf Meerkerk. Ook een stuk bij Vianen was leeggelopen.
http://www.openstreetmap.org/#map=16/51.9757/5.0828

Denk wat ik getekend heb redelijk klopt. De eilandjes zitten al in de nieuwe relaties. Die waren in de mapnik water geworden.

Groet,
Eggie

edit: 'k Zie nu dat de hele boel aan de Oostkant van het Merwedekanaal onderwater staat als ik potlatch2 open. 'k Had Cartinus gevraagd om er naar te kijken. Weet niet of hij bezig is. … of ben jij al bezig? ik blijf er even af.

edit2 : De multipolygon stopt bij de Zijlkade en het water loopt nu schuinweg naar het Noord oosten.

Eigenlijk zijn we knap gestoord om in een landje te gaan wonen dat grotendeels onder de waterspiegel ligt :smiley:

Afgezien van kijken ben ik er nog niet mee bezig, dus misschien kan ik beter ff een paar dagen wachten met editen in dat gebied (zeker als je Cartinus al hebt gevraagd om er naar te kijken)

Johan,
'k Denk niet dat Cartinus bezig is, anders had hij wel op m’n mail gereageerd. Hendrikklaas wordt ook al ongerust. :smiley: Opruimen maar …of denk jij dat je die Multipolygonen kunt herstellen?

De multipolygoon is wel te herstellen, maar dan moet ik jouw werk van het afgelopen weekend verwijderen, wat misschien ook wel zonde is. Bovendien twijfel ik nog een beetje aan het herstellen van zo’n multipolygoon, omdat ik een aanhanger ben van het KISS principe: hou het simpel als het ff mogelijk is. De Duitsers hebben zelfs een topic gewijd aan multipolygonen: http://forum.openstreetmap.org/viewtopic.php?id=16911

Misschien kom ik er morgenavond aan toe, anders wordt het komend weekend

Kijk maar wat het beste lijkt. Alleen die eilandjes in de Oude Zederik had ik in mijn relatie opgenomen en dat eilandje in de bocht van het Merwedekanaal bij Meerkerk. http://www.openstreetmap.org/#map=19/51.92022/4.99914
Mijn werk kun je er rustig afgooien als het niet meer nodig is.
Die twijfel op die multipolygonen te herstellen zijn had ik direct al.
Denk niet dat dat water op het land zal renderen anders zat die fout al in de ofm van 18 okt… Eigenlijk al vreemd dat daar gewoon water is te zien.

@It’s so funny
edit: Ben toch zelf begonnen met het verwijderen van de overbodige multipolygonen. Het is echt een rommeltje en het is toch slecht weer en ik heb herfstvakantie. . Zelfs de brug is in de relatie opgenomen. Soms wel water op een MP soms niet en dan krijg je vreemde effecten. Als jij dan nog een keer wil kijken?
eggie

edit 2: Done op de manier van KISS.
Bij Vianen de MP kunnen herstellen. De oude Zederik opnieuw getekend en de rommel opgeruimd. Even afwachten wat het renderen doet.
Volgens mij komt het omdat iemand van de 3d-shapes lijnen slootjes heeft gemaakt. Dat gaat kennelijk wel, maar bij de Oude Zederik is dan de relatie kennelijk verbroken.

De oude Zederik (De Oude Keulse Vaart) en het Merwedekanaal toch maar iets minder KISS hersteld.

https://www.openstreetmap.org/#map=16/51.9251/5.0048

Wanneer iemand(?) slootjes maakt van de multipolygonen gaat het geheid mis met de relaties. Ziet er wel gelikt uit dat polderland …alleen het grote water loopt dan leeg en veel informatie als bosjes gaan verloren.
Eens kijken of al het water terugkomt?

Op het moment doet de standaard rendering niets met de layer tag voor landuse areas. Dat kan in de toekomst wel veranderen, zie ook https://github.com/gravitystorm/openstreetmap-carto/issues/53. Andere renderers gebruiken de layer tag misschien wel. We sorteren nu op volgorde van grootte, dus kleine areas worden bovenop grotere areas gerenderd.

Layer=-1 op landuse=residential is duidelijk incorrect, dus moet worden verwijderd (aangenomen dat het niet gaat om holbewoners).

Ik zie trouwens ook niet in wat voor rendering problemen met overlappende landuse=residential gebieden voorkomen zouden kunnen worden met layer=-1?

Bij deze een herhaling van mijn verzoek van een paar weken geleden. Tip om het jezelf makkelijk te maken: met de http://overpass-turbo.eu/ kun je op basis van de query user:“JE GEBRUIKERSNAAM” and (AND_nosr_r=* or AND:importance_level=*) via JOSM deze beide tags verwijderen. Let er svp op dat je daarbij nooit een weg, node of relatie mag verwijderen.

Geef ff een DM als je dit lastig vindt, dan kan ik je bijvoorbeeld via Teamviewer helpen

Cheers, Johan

Ik heb even moeten puzzelen hoe ik die query moest doen, maar mbv. de wizzard kreeg ik het onderstaande.
Ik post hem hier even, dan kunnen anderen (die ook zitten te worstelen) deze code gewoon overnemen met hun gebruikersnaam.

[out:json][timeout:25];
// gather results
(
  // query part for: “user:marczoutendijk and AND_nosr_r=*”
  node(user:"marczoutendijk")["AND_nosr_r"]({{bbox}});
  way(user:"marczoutendijk")["AND_nosr_r"]({{bbox}});
  relation(user:"marczoutendijk")["AND_nosr_r"]({{bbox}});
  // query part for: “user:marczoutendijk and "AND:importance_level"=*”
  node(user:"marczoutendijk")["AND:importance_level"]({{bbox}});
  way(user:"marczoutendijk")["AND:importance_level"]({{bbox}});
  relation(user:"marczoutendijk")["AND:importance_level"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

Een van de wegen die daarin wordt aangemerkt is:
http://www.openstreetmap.org/way/7074597

Daarop zie ik inderdaad de tag AND_nosr_r staan.

Als ik alles goed heb begrepen in de discussies hierboven, dan zou ik dus vanuit JOSM die overbodige tags nu kunnen gaan verwijderen?

Vat ik het zo goed samen?

Edit: plaatje vervangen door code n.a.v. opmerking vam @Allroads

Hi Marc,

Bedankt opgelost, ik had dezelfde vraag mbt dit item ook bij Its so funny neergelegd, met ja en ? Maar de post stond elders dacht ik.

i.p.v. plaatje

de sectie tussen “button CODE” zetten?