Verwijderen nutteloze AND en 3dShapes tags

“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?

Is gebeurd.

Even controle door de experts of ik het nu goed doe:

  1. Ik heb de in mijn post #40 genoemde query uitgevoerd.
  2. Daarna gekozen voor exporteren met JOSM als bestemming

Toen volgde een foutmelding dat de gegenereerde data niet klopte en niet in het juiste formaat voor JOSM. Ik kon kiezen voor corrigeren of afbreken.
Corrigeren gekozen waarna alles wel goed ging en JOSM werd geladen met de dataset overeenkomstig de query.
In deze dataset zie ik dus uitsluitend wat door mij is bewerkt en dat de twee ongewenste AND tags bevat. Ik zie geen enkele andere way of node. Dat klopt neem ik aan.
Daarna:

  1. Alle tags geselecteerd met AND_nosr_r en verwijderd
  2. Alle tags geselecteerd met AND:importance en verwijderd

Bij controle zie ik dat alle wegen er nog keurig staan en dat er ogenschijnlijk niets anders is verwijderd dan de twee AND tags.
Nu zou ik alles dus weer kunnen uploaden en verwoest ik bijvoorbeeld niet heel Vught?

Daar wacht ik dus nog even mee totdat een expert heeft gesproken.
Eventueel zou ik het gecorrigeerde bestand aan een expert kunnen opsturen ter controle.
Is dat wat?

Marc, als je in JOSM via Windows de command stack opent kun je exact zien wat je doet. Als je in de selectie obv CTRL-F ontdoet van de twee betreffende tags zie je dat keurig in de command stack terug. Daarna kun je uploaden.

Cheers, Johan

ps als je ooit eens een keer merkt dat een upload niet goed is gegaan kun je dat het beste herstellen door de betreffende changeset(s) te reverten