Edits in de Krimpenerwaard

AnkEric, bedankt voor je uitleg en werk met de correcties. Nu begrijp ik ook waarom er verschillen in ‘dekking’ tussen de OFM en osm.org ontstaan. Een duidelijk pleidooi om verder te kijken dan de neus van osm.org lang is. En inderdaad, bij mijn correcties ben ik ook maar even uitgegaan van de bestaande landuses zonder te controleren of grass, orchard, farmland, etc. nog juist zijn.

De OFM is voor mij altijd de primaire bron om te constateren dat er iets mogelijk niet klopt, omdat ik na mijn fietstochten altijd het gps-spoor langsloop en controleer op routering. Osm.org is de tweede stap voor controle van de tags, etc.

off topic:

@AnkEric, je slaat hiermee de spijker op zijn kop.
De OSM database is gevuld met relevante data die in de database is gestopt en DAAROM (sorry voor de hoofdletters, maar ik wilde het eruit laten springen) dienen mappers zich aan de overeengekomen afspraken te houden.

Naast de database bestaan de renderers (lees kaartmakers/routeerders) die gebruik maken van deze database. Die kunnen zelf overwegen of ze de wegen of de electrische ondergrondse leidingen op de kaart willen laten verschijnen.
Menig mapper (en dan spreek ik niet over beginnende mappers die foutjes maken (soms met grote gevolgen)) vergeet dit perspectief weleens. De meesten weten dat de 3dShapes import veel fouten achter heeft gelaten in de database, en er mappers zijn die dit ook opvalt en graag een steentje willen bijdragen om dit op te lossen. Met als gevolg dat men verdrinkt in de natural=water etc. etc.

Toch moet gezegd dat het verkeerd oplossen van fouten, ook zijn positieve kanten heeft.
=== Als men fouten maakt, kan men hiervan leren ====
(Sommigen zullen het helaas nooit leren maar dat is een zeer klein groepje)
Daarom is het ook goed om zonder blaming and shaming deze fouten bespreekbaar te maken.
(ook ik heb me hieraan onbewust schuldig gemaakt, waar ik nu nog steeds spijt van heb, het was namelijk goed bedoeld)

Als voobeeld van rendering wil ik een voorbeeld geven.
Een golfbaan is voor weinigen interessant om te renderen, toch staat het, als het goed gemapt is zeer goed op de kaart.

Dit is ook een precies een voorbeeld waar Milo het ook over had, als er overeenstemming is om het te mappen moet men dat ook vooral doen! En het mappen van golfbanen is redelijk goed vastgelegd.
Ook bij het mappen van golfbanen is het niet zichtbaar op de grond. Ja de tee, de pin, de green, de fairway, de bunker, de rough, en de waterpartijen zijn zichtbaar.
Maar de vluchtlijn (afstand) van de golfbal naar de hole kun je niet zien, toch wordt deze gemapt volgens afspraak (golf=hole)
Openstreetmap.org

Umap

Wanderreitkarte

Nou als iemand nog een golfbaan wil taggen, de Breuninkhof bij Busloo is nog niet van holes, etc voorzien. http://www.openstreetmap.org/#map=17/52.19946/6.12014&layers=N
En 't Zelle bij Varssel ook niet http://www.openstreetmap.org/#map=16/52.0595/6.3911&layers=N
De Pitch & Putt Busloo is al wel door een mapper gedaan.

Nog een leuke:

Self-crossing ways en geen multipolygon.
En dus onjuist gerenderd op een mijn eigen kaart (én OFM).

Let vooral op de drijvende bench en picnic_site (want ook “picnic_table” mappen we ook bij voorkeur onjuist als “picnic_site”).

Maar ook hier, wél correct op openstreetmap.org:

ik vind dat dit een onaangename, arrogante toon heeft.

Is niet elke picnic_table een picnic_site ? Is het niet ons aller taak om andere mappers op te leiden en de juiste, soms nieuwere tags aan te leren ? Ik ken picnic_table ook nog niet zo lang. het is alleszins recenter dan picnic_site en waarschijnlijk ook nog niet zolang gekend in de meeste editors, als het al gekend is.

Dit is een wat erg optimistische aanname over de “zware renderers”… Wat feitelijk gebeurd is dat er slechts een “primitieve” sortering op grootte plaats vindt. De tabel met polygonen wordt slechts zo gesorteerd, dat de grootste features eerst getekend worden tijdens het renderen, en de kleinere later. Dat bewerkstelligd dus de “correcte” weergave.

“Correct” bewust tussen aanhalingstekens, want zolang er geen echte multipolygoon met outer en inners is aangemaakt, is het feitelijk slechts gissen wat de juiste weergave van de data is, en is de gebruikte sortering slechts een doekje voor het bloeden…

Om daadwerkelijk softwarematig “te bepalen of een area binnen een andere area” ligt, zou een geoprocessing operatie van ongekende omvang vragen tegen een wereldwijde database. De rendersnelheid zou er bepaald niet op vooruit gaan… :roll_eyes:

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.