Edits in de Krimpenerwaard

Ik ben de laatste uren niet aan het editen geweest hoor, alleen net even gekeken wat AnkEric gewijzigd had. Kon zo snel niet zien wat nu anders is dan wat ik had achtergelaten na mijn edits aan wegnr. 451609907.

JOSM geeft wel heel erg veel fouten aan. …maar als gras en water weer renderen is er toch wat gewonnen. een aantal staartsloten had ik verwijderd want die zaten weer een eind verderop aan de landuse gras vast en die landuse kruiste dan over de andere percelen heen. Hier kan dan beter waterway=drain getekend worden.

En dan maar hopen dat kaarten die anders gerenderd zijn, zoals de OpenFietsMap niet alsnog ondergelopen landerijen en/of witte vlakken laten zien… :confused:

Eerder op de avond heb ik ook even meegekeken en zag ik vervolgens dat AnkEric al een correctie had gemaakt. Wat je wil, schematisch gezien, is een 0 maken: een lijn die op hetzelfde punt begint en eindigt en dus een vlak wordt. Deze lijn was echter een schematische 6 of een 9 want het had één extra knoop en dus een extra stukje lijn. Het zag er daardoor wel uit als een gesloten vlak maar was het niet werkelijk.

Ver ingezoomd op https://www.openstreetmap.org/way/451609907 in de versie voordat dit probleem opgelost was ziet een staartje, ofwel 6 of 9 figuur, er als volgt uit.
Deze extra node wordt (onbewust) veroorzaakt door het bewerken met Potlatch, maar nog veel sneller door ID.
Dit soort unclosed ways, kan er alleen al voor zorgen dat een rivier lek raakt. Vandaar dat het werken in complexe landuses wordt geadviseerd om in JOSM te bewerken.

Dat soort hinderlijke dingen gebeuren in JOSM ook, maar daar heb je het meestal sneller in de gaten. En anders gaat de validator wel piepen.

Dank heren voor het aanreiken van jullie uitgebreide uitleg van de oorzaak van de problemen. Mij leert het dat ikzelf in elk geval met Potlatch niet aan dit soort complexe reparatie-klussen moet beginnen - een foutje is zo gemaakt en Potlatch waarschuwt niet.
Ik weet niet of Alsoft meeleest, maar ik hoop dat hij lering trekt uit de door hem aangerichte schade waar dit gedoe allemaal mee begon. Hij gaf aan niet meer met OSM bezig te zullen zijn, dus ik denk dat we hem niet meer gaan zien.

Vóór (OFM v05-11-2016) en ná correctie (Map van vandaag):

Ik zie nu pas dat er zowel minder als méér water is na correctie.

Voorbehoud:

In 23 Changesets zijn - vrijwel - uitsluitend JOSM validatie correcties uitgevoerd.
Source: “JOSM validation”.

Slechts af en toe is vergeleken met CycloMedia.
Maar er is geen controle gedaan op de juistheid van landuse, natural.
Zijn dit inderdaad nog landbouwgronden?
Is dit inderdaad een boomgaard?
Ligt hier water? Of niet?
Is dit een brug? Of een ‘culvert’? Of gewoon gras? In ieder geval heb ik water onder gras verwijderd, omdat JOSM dit ziet als een duplicate (source: 3dShapes).

Te weinig gecorrigeerd is het niet aansluiten en/of overlappen van {landuse=grass} en {natural=water}.
In principe (…) wordt water bovenop grass goed gerenderd (assumption: water ligt boven grass).
Mits de area’s gesloten zijn, maar zelfs van een “U-vormige-not closed-area” (om meer water toe te voegen) heb ik voorbeelden gezien die toch goed worden gerenderd.

Ook Osmose ziet “vooruitgang” maar is nog allerminst tevreden:

En ik mag - als ik dat zou willen - gewoon verder gaan waar ik gisteravond na vier uur ben opgehouden.
Nu “Self-crossing ways”, die kende ik nog niet:

De situatie in Krimpenerwaard was weliswaar behoorlijk “slordig” (zeker omdat de meeste fouten met JOSM zijn gemaakt en dus niet gevalideerd), maar ook volstrekt normaal en typerend voor de gemiddelde kwaliteit van OSM.

Voorbeelden:

Bleiswijk, OFM vs. eigen Map.
Quick and Dirty opgelost door de renderer:

  • landuse=greenhouse | landuse=greenhouse_horticulture {set landuse=farmland}
    Immers: kassen worden gezien (assumption) als building en een building wordt altijd boven water gerenderd. Dus veranderen in landuse en probleem is - voor mij - opgelost.

Maar oorzaak is het ontbreken van multipolygonen.

Ameland, Oerd Blinkert: OFM v15-10-2016 (vóór correcties) vs. eigen Map (ná correcties).
Onjuiste multipolygon, simple area’s niet opgenomen in een multipolygon.

Helaas wordt hier op dit forum de mening geventileerd dat multipolygonen alleen nut hebben om “gaten in area’s” te kunnen maken.
Vergeten wordt dat de zware renderers (openstreetmap.org) prima in staat zijn om te bepalen of een area binnen een andere area ligt (en dus moet worden gerenderd als “inner”).
Maar eenvoudige renderers (Garmin kaarten m.b.v. mkgmap) kunnen dat niet.
Zie Ameland waar complete simple area’s niet worden gerenderd! Wat dan weer het gevolg was van een wel aanwezige outer multipolygon, maar waarin de “inners” ontbraken.
Beide voorbeelden werden, worden op openstreetmap.org wél correct gerenderd.

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: