Edits in de Krimpenerwaard

Ik ben gisteren zowat de hele dag bezig geweest met het oplossen van de zichtbare omissies op osm.org. Met Potlatch heb ik nodes zitten verschuiven en de boel zo goed en zo kwaad mogelijk aan elkaar geknoopt. Dat de OSM validator nog niet tevreden is, zal me voorlopig een worst zijn. De situatie is echt breedschalig niet correct gemapt en ik heb geen ambitie om dat te gaan oplossen. Ik wacht even af wat de OFM (voor mij de referentie) er a.s. zaterdag van gemaakt heeft en als daar nog hindelijke zaken als ondergelopen land of droge sloten tevoorschijn komen, dan wil ik nog wel een poging wagen het te verbeteren, misschien weer met hulp. Het door AnkEric aangehaalde ondergelopen eilandje bij De Loet is een goed voorbeeld dat me op OFM nog niet opgevallen was en heb inmiddels een poging gedaan om het te verbeteren. We zullen zien hoe het uitpakt.
Achteraf heb ik een beetje spijt dat ik aan het ‘project’ Krimpenerwaard ben begonnen, maar het positieve is dat door jullie meedenken en uitleg ik - en ik hoop ook andere mappers - ook weer veel geleerd heb.

@BikePC, Ben benieuwd… Daar bij De Loet https://www.openstreetmap.org/#map=19/51.92391/4.68516 stond eerder de boel helemaal onder water. Ook de andere eilanden. Toen ben ik ook aan het repareren geweest ( ook met hulp van Ligfietser)
Uiteindelijk was het bovenwater, maar je ziet … het is zo weer gebeurd met die multies.
Het is een lastig stukje. Volgens mij is het nu weer goed.

Het is nog lang niet goed :frowning:

Iedere keer als ik een “Self-crossing way” laadt en corrigeer vind ik weer een aantal nieuwe.
Sommige fouten zijn wel zichtbaar op “een” kaart, andere niet.
Inmiddels twee volle avonden frustratie en de vraag: waar ben ik aan begonnen?
(Ja, ik weet waarom: komende drie weken is dit ons fiets- en wandelgebied).

Positief geformuleerd: de resterende fouten zitten “aan de buitenrand” van het inmiddels wél, grotendeels, gecorrigeerde gebied.

Eric,
Ik doel op het op de OFM niet zichtbare eilandje bij De Loet… Dat is nu goed volgens mij. Voor de rest zit er nog vele uren werk in om het goed te krijgen. Voor een regenachtige dag.
Voor je fietstochten zullen de fouten hopelijk weinig uitmaken.

Volledig mee eens.
Bovendien ben ik zo’n “kleintje” en werk jij met de “zware renderers”.

Maar…

Als ik had geschreven dat de zware renderers “over het algemeen redelijk in staat zijn” om “goed te gissen” wat de juiste weergave van de data is, maar de “kleintjes” dat niet kunnen…?

Want eigenlijk, zo lees ik het, versterk je mijn “conclusie”: zelfs de “zware renderers” hebben in principe multipolygonen nodig. Niet alleen de kleintjes.

En dat is mijn punt:
Te vaak plakken mappers landuse/natural bovenop landuse/natural, zonder multipolygonen.
Of men plakt een open, not closed, area bovenop een - al bestaande - multipolygon (en dat rendert, helaas zou ik bijna zeggen, meestal nog goed ook).
Als ik daarop wijs krijg ik (soms, vrij vertaald) als reactie: “Het ziet er anders prima uit op de kaart… dus geen enkele reden om met die lastige, onzinnige en overbodige multipolygonen te gaan werken. En als jij dat wilt verbeteren, ga vooral je gang!”
Einde discussie!
Ik heb nog even iets gesputterd over OFM, maar: “Zonde van alle tijd die je er aan besteed he HET GAAT NIET ALLEEN OM GPS-GEBRUIKERS IN DE WERELD”.

En dus waren - sommige - eilandjes met bomen op - alle - heidevelden rondom Hilversum onzichtbaar.
Waren - alle - open plekken in de bossen van ten oosten van Kortenhoef onzichtbaar: 100% forest.
Eilandjes in water in een weiland. Onzichtbaar.
Enz., enz. (zie ook bovenstaande voorbeelden).

Prima zichtbaar op openstreetmap.org, onzichtbaar op OFM en mijn eigen kaart.

En ik zie maar één oplossing: multipolygonen!

@AnkEric, had dat nou even eerder gezegd dat je de Krimpenerwaard zou gaan aanpakken, dan had ik mijn gestoei met Potlatch om de ernstigste plooien glad te strijken achterwege kunnen laten en mijn tijd (beter?) ergens anders aan kunnen besteden! Not amused :frowning:
Natuurlijk weet ik dat dat de Krimpenerwaard een oerwoud aan validation errors oplevert, maar kennelijk ben je nu ineens door een wesp gestoken om de boel aan te gaan pakken. Het zijn echt niet alleen de edits van Alsoft die onjuist zijn. Andere mappers hebben ook naturals=water neergekwakt bovenop bestaande landuses zonder er verder iets aan te doen. En dat is echt niet recent - die situatie bestaat al jaren. Natuurlijk is er een hoop te doen, maar als ik je een advies mag geven, sla niet door en hou het simpel waar het simpel kan.
Mij zie je niet meer in de Krimpenerwaard met edits aan landuse en naturals - voor een mooi nieuw fietspad wil ik nog wel een uitzondering maken :slight_smile:

De twee witte vlekken op osm.org zijn volgens mij ‘forest’: http://www.openstreetmap.org/#map=17/51.91609/4.65852 :slight_smile:

Meer dan twee “laatste” witte vlekken opgevuld: [natural=wood], [landuse=farmyard].

Maar dit is en blijft lastig:

  • OFM (en mijn eigen kaart) rendert alle witte vlekken als “groen gras”. Ik zie geen witte vlekken op mijn eigen kaart en dus lastig zoeken.

  • Als je die “witte vlekken” wél rendert, vind ik dat niet mooi. En wat erger is: Anke vindt dat niet mooi. Het fietspad door het Loetbos loopt door een witte corridor, “brandgang”. Ziet er - op de kaart, een beetje - uit als een “te vermijden fietspad”.
    Dit is ook het gevolg van een fietspad dat niet als “area:highway” is getagd. Want gras en asfalt sluiten in werkelijkheid wél volledig aan. Maar die discussie is hier weer Off-Topic.

  • Nog lastiger is [landuse=grass]. Mede omdat OFM het niet (meer!) rendert is [landuse=grass] een vrijwel nutteloze, niet meer onderhouden puinhoop geworden. Ook ik redeneer: zolang het er goed uit ziet op mijn eigen kaart vind ik het prima. Dus ook ik ben “een pot die de ketel…”.
    Maar het is niet “prima”. Bijvoorbeeld: vele kruisingen zijn vervangen door een rotonde. Maar: het gras ligt er nog ongewijzigd uit de tijd van de 3dShapes import en de kruising.

  • Eén witte vlek (parking Zijdeweg) was het gevolg van onjuiste tagging: amenity=parking_space
    Use amenity=parking_space to map a single parking space on a parking lot. Mapping parking spaces is an addition, not a replacement, to mapping a whole parking lot with amenity=parking.
    Een onjuiste parking_space wordt niet gerenderd.

Feedback, als iets niet oké is dan helpt het niet om:

  • een noodverband aan te leggen

  • dubbel te stikken

  • een plakkertje zonder lijm op een lekke binnenband te drukken. Lekke binnenband plakken is een “thuiskomertje”, definitieve fix is het vervangen van de binnenband.

In de Krimpenerwaard zijn - in de context van dit draadje - tientallen “dubbel gestikte noodverbandjes” aangelegd.
Dat is een nieuwe Error: “Unclosed way - landuse type grass” voor een area, polygon of multipolygon die altijd gesloten moet zijn.
Dezelfde fout in andere situatie wordt gemeld als: “duplicated ways”, “way contains segment twice” of (als het noodverband óók slordig ligt): “crossing ways”, “self-crossing ways”, “self-intersecting ways”.

Links: voor “correctie”.
Rechts: noodverband toegevoegd over de al aanwezige [landuse=grass]. Nieuwe Error!

En ook hier geldt: typische Potlatch fout, JOSM waarschuwt.
Mits je de tijd neemt om JOSM een validatie te laten uitvoeren. En juist dat laatste was in de Krimpenerwaard het probleem. Want vrijwel alle fouten zijn gemaakt met JOSM.

AnkEric, kan het zijn dat hier het spreekwoord geld: “wat was er eerder de kip of het ei”?
Ik zou me maar voor kunnen stellen dat de 3dShapes import (2011) er eerder was, dan de validatie in JOSM op duplicated ways", “way contains segment twice” “crossing ways”, “self-crossing ways”, “self-intersecting ways”.

Ik ben het met je eens dat dit soort klussen niet met Potlach of erger met ID gedaan wordt.

Ja dat kan zijn, maar niet in de context van de Krimpenerwaard en mijn voorbeelden.

Ik heb oorzaak, gevolg en vervolgschade beoordeeld op basis van de Historie. Soms (vaak) geeft ook de historie geen uitsluitsel. In dat geval heb ik (in een klein aantal gevallen) een Revert uitgevoerd. Niet uitgevoerd dus, maar de oorspronkelijke situatie beoordeeld vóór de Reverted Changeset(s).
Want ja, ook ik heb mij afgevraagd hoe het zat met de “kip of het ei”.
Conclusie: user “A*” is, voornamelijk maar niet alleen, verantwoordelijk voor de Krimpenerwaard puinhoop. En niet 3dShapes.
Ook zijn de fouten gemaakt met een JOSM versie die controleerde op dit soort fouten.
Maar hoe verder weg bij “De Loet” des te meer is niet “A*” eerst verantwoordelijk, maar “p*”.

Vandaag dacht ik nog even een half uurtje over te hebben voor een paar kleine Osmose kritiekpuntjes (die ik tot nu toe had gemist). Maar helaas: dat half uur is al weer ruimschoots verstreken. En opnieuw geldt: puinhoop in de basis, verbeteren is “lastig” (understatement).
Want, ik heb dat al eerder aangegeven (tussen de regels door): ik beperk mij op dit moment tot puinruimen. Normale verbeteringen (vergelijk met mijn tracks, CycloMedia en Bing), daar kom ik niet aan toe. Dat is een volgende fase, maar dan niet voor mij (hopelijk).
Het is voornamelijk fout gegaan bij het toevoegen van water. Maar helaas: dat geldt (gedeeltelijk: “gold”) voor bijna heel Zuid-Holland, Noord-Holland en Utrecht.

Een volgend - typerend -voorbeeld:

Landuse and natural overlappen. Oorzaak: het water is in het verleden door user “p*” consequent over het gras heen gepletterd. Niet incidenteel, maar gewoon structureel en altijd. User “p*” hierop aanspreken is 100% zinloos.

De bridge heeft geen layer. Ook user “p*” die dit structureel niet nodig vindt. En Keep Right vind het alleen echt fout als bridge een waterway kruist. Twee keer raden wat er gebeurt als je “eventjes een kanoroute” wilt toevoegen door alsnog een waterway toe te voegen.

De track is realigned op basis van Bing. Maar daarbij is niet voldoende ingezoomd en het gevolg is een crossing way.

Ja, user p is een ook een ramp. Werkt met Potlach en doet dingen, die je niet met Potlach moet doen en is niet voor rede vatbaar.
In tegenstelling tot user g is p altijd onder de radar gebleven alleen bekend bij een paar mappers.
Ik heb ook al last gehad van het werk van p bij het maken van Regge meanders.

Zelfde laken en pak. Nooit antwoord… geen teamplayer. Keep right kleurt overal rood.

Zelfde laken en pak:

Maar… wat is het nut van dat wat ik gewoon als “werk” beschouw:

Er is nog genoeg water dat niet op de kaart staat. Als dat op dezelfde manier alsnog op de kaart wordt gepletterd, hebben we volgend jaar hetzelfde probleem.
Hoe krijgen we die kraan dicht?

Of, zoals Eggie suggereerde, zet die brede sloten als waterway op de kaart vóórdat iemand anders…
Maar… ik vind ze daar te breed voor. Behalve “sloot” zijn ze ook behoorlijk landschapsbepalend… mooi zelfs. Mooier dan een dun waterway lijntje.

Maar ook dat werkt niet.
User “p*” plettert dan alsnog [natural=water] op de kaart en dan gewoon naast de waterway. Want Bing…
Resultaat: overlapping natural=water en landuse=grass, waterways die naast het natural=water lopen (of natural dat naast de waterway loopt) en crossing natural=water.

En hoe en wanneer houd ik hier op:

De landuses zijn hier gebaseeerd op de oude weilandensituatie.
Het is nu een golfbaan.
Join overlapping Areas, multipolygon “grass” met “natural=water” en “natural=wood” als inners.
Simpel, snel… Multipolygonen zijn niet altijd lastig en moeilijk (De Loet is klaar!?), maar soms ook simpel en snel.
Maar ja, het samenvoegen van landuse is niet onomstreden.

In het geval van zo’n golfbaan kun je alle grasvlakken samenvoegen tot één geheel. Op een golfbaan lopen geen kavelgrenzen. En als je al die grasvlak tot 1 vlak hebt samengevoegd, kun je er een multi van maken met die watervlakken.
Wel moet je die rand watervlakken er nog weer uitsnijden.
Fikse klus als ik zo bekijk.

Na mijn laatste correctie is Multipolygon “De Loet” is niet (meer) oké.

Locatie: N51.92403° E4.68420°

JOSM mopperde over “Intersection between multipolygon ways (13)”.

Inner ways mogen niet “touchen” (behalve op één punt)
Dat was al grotendeels opgelost door een “lege inner” (zonder tags) rondom de eilandjes te tekenen. De eilandjes zijn vervolgens weer opgebouwd uit meerdere simple polygons. Deze oplossing heb ik gisteren consequent doorgevoerd, waarna JOSM helemaal tevreden was.

JOSM:

Maar… links (OSM, mapnik) is oké, rechts (Mijn eigen kaart van vannacht, mkgmap) is NIET oké.

Deze manier van tekenen is van links naar rechts acht keer toegepast. Alleen bij de voorlaatste inner gaat het fout (en niet op OSM). Alle andere gaan wél goed.
Ik weet dat mkgmap een aantal iteraties (herhaald doorlopen) maakt om dit soort ways in kaart te brengen.
Enige oplossing die ik zelf kan bedenken: splits de multipolygon op. Deze bevat (te) veel verschillende inners (nooit een probleem), maar bovendien bevatten de “inners” weer (te veel) simple polygons ???
Iemand een beter idee? Zie ik iets over het hoofd?

Eric, probeer eens mkgmap r3702, daarin wordt al rekening gehouden met kleinere polygons bovenop grotere. Het is nog experimenteel, de bestanden worden 30% groter bij mijn OFM dus ik wacht het nog even af, zie http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q4/025355.html

Mkgmap r3702 lost dit inderdaad op.

java -Xms2048m -Xmx2048m -jar F:_APPS\mkgmap\mkgmap.jar –order-by-decreasing-area -c osm_nl.args -c splitter\template.args 40010.typ

Twee keer winst:

  • polygonen binnen een “inner” multipolygon worden nu - altijd - goed gerenderd. Dus ook deze uitzondering.
    Ook het Hilverbeek (ten oosten van Kortenhoef) lijkt beter (meer open grassland, minder forest).
    Mkgmap behoort nu óók tot de “zware renderers”… :sunglasses:

  • bruggen missen op - mijn - kaart - op sommige locaties - de highway die over de brug loopt. Ook dat lijkt opgelost. Zie onder: 1 van de 4 bruggen was onjuist.

Links mkgmap r3701 (HikingMap), rechts mkgmap r3702 (BikeMap)

Kaartbestand is - voor mijn kaart - 20% groter.
Verschil tussen 20 en 30% wordt misschien verklaart uit het ontbreken van residential area op mijn kaart:
landuse=residential {delete landuse}

EDIT 08 december 2016:
Met of zonder “–order-by-decreasing-area”, bovenstaand voorbeeld rendert nu altijd goed.
Ook met mkgmap 3701.
OpenFietsMap (Benelux_v12-11-2016) was niet OK!
OpenFietsMap (Benelux_v19-11-2016) was OK!

Het water rond Bleiswijk is niet boven water. Maar dat wordt ook ws. veroorzaakt door het ontbreken van multipolygonen.

Mooi te zien dat ook de wegen op de bruggen weer boven water komen!

Dat kan te maken hebben met de draw priority in de OFM typ file (kassen 0x4e = 7, farmland 0x1f = 5, kleine wateren 0x3c = 6). De programmeur schrijft hierover het volgende:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q4/025381.html

Project afgesloten: 20 uur frustrerend en 80% zinloos werk.

Laatste JOSM validatie:

De laatste paar Warnings:

  • zijn niet oplosbaar zonder survey

  • mogen genegeerd worden (“Nodes at same position” zijn meestal UMTS masten)

  • zijn false positives: “Similarly named ways”.
    “Groenendijk”, “Groenedijk”, “Groendijk” is een moeilijke: “note=Groenendijk in Nieuwerkerk, Groendijk in Capelle”. En: dat is geen Krimpenerwaard.

  • zijn voor mij onbegrijpelijk

  • negeer ik standaard: “Role verification problem”.
    Wel een leerpunt: hier staan ook multipolygon outer/inner ways zonder “role” aanduiding. Deze zijn wel gecorrigeerd.

  • vind ik niet belangrijk: geen name op tertiary roundabout. Weet ook niet wat de naam zou moeten zijn.
    En ja, een pedestrian moet - volgens JOSM - ook een naam hebben. Soms terecht, soms overdreven. Soms is pedestrian onjuist.

ToDo voor de liefhebber:

  • Overlapping landuse (grass) en natural (water)

  • Unconnected area’s (JOSM: Join node to way [J])

  • Méér water

  • Vergelijk landuse en natural met CycloMedia luchtfoto’s. In dit gebied zijn er veel bomen bijgekomen sinds 3sShapes en ook sinds Bing. Ook [natural=tree_row] ontbreekt vaak en is met tegenwind op de fiets best prettig (maar wordt niet gerenderd op OFM).

  • 24x highway=residental heeft geen name

  • Nog steeds veel “bijna” fouten. Deze worden niet gezien door JOSM, soms wel door Osmose. Meestal: handwerk…

Conclusie:
Het op de kaart pletteren van buitengewoon slordig “werk” is vooral hinderlijk voor collega’s.
Het aanbrengen van wijzigingen of verbeteringen binnen een dergelijk gebied is onevenredig lastig. Bijvoorbeeld het toevoegen van water wordt moeizaam als je eerst de area’s moet corrigeren voordat je iets nieuws kunt toevoegen. Tenzij je zelf óók bereid en in staat bent om troep op troep te stapelen.
De Renderer heeft er meestal weinig of geen last van (dan wel: lost het zelf wel op). Daarom was het project voor 80% zinloos.
Maar het zou mooi zijn als volgende mappers zich nu kunnen beperken tot werk dat 80% zinvol is.