You are not logged in.

#26 2016-11-07 05:24:18

Commodoortje
Member
Registered: 2013-10-31
Posts: 2,414

Re: Edits in de Krimpenerwaard

AndriesWijma wrote:
BikePC wrote:

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.

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.

2016-11-07_05-22-47.png?raw=12016-11-07_05-15-44.png?raw=1

Offline

#27 2016-11-07 07:31:11

dvdhoven
Member
From: Deventer Colmschate
Registered: 2015-03-09
Posts: 2,365

Re: Edits in de Krimpenerwaard

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.


Dick van den Hoven

Offline

#28 2016-11-07 10:14:22

BikePC
Member
From: Zoetermeer NL
Registered: 2010-06-09
Posts: 548

Re: Edits in de Krimpenerwaard

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.

Last edited by BikePC (2016-11-07 10:17:27)


GPS: Garmin Edge 800 / Edge Touring Plus / Edge Explore

Offline

#29 2016-11-07 15:15:24

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

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

Krimpenerwaard_voor_na_correctie.jpg

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:

Krimpenerwaard_Osmose.jpg

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:

Self_crossing_ways.jpg

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.

Bleiswijk_missing_water.jpg

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.

Ameland_Oerd_Blinkert.jpg

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.

Last edited by AnkEric (2016-11-07 19:22:55)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#30 2016-11-07 16:18:09

BikePC
Member
From: Zoetermeer NL
Registered: 2010-06-09
Posts: 548

Re: 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.


GPS: Garmin Edge 800 / Edge Touring Plus / Edge Explore

Offline

#31 2016-11-07 16:18:55

Commodoortje
Member
Registered: 2013-10-31
Posts: 2,414

Re: Edits in de Krimpenerwaard

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
2016-11-07_15-38-34.png?raw=1
Umap
2016-11-07_15-40-38.png?raw=1
Wanderreitkarte
2016-11-07_15-44-24.png?raw=1

Last edited by Commodoortje (2016-11-07 16:22:03)

Offline

#32 2016-11-07 16:46:48

dvdhoven
Member
From: Deventer Colmschate
Registered: 2015-03-09
Posts: 2,365

Re: Edits in de Krimpenerwaard

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 … 4&layers=N
En 't Zelle bij Varssel ook niet http://www.openstreetmap.org/#map=16/52 … 1&layers=N
De Pitch & Putt Busloo is al wel door een mapper gedaan.


Dick van den Hoven

Offline

#33 2016-11-07 20:17:15

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

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").

Self_crossing_ways_en_geen_multipolygon.jpg

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

Self_crossing_ways_en_geen_multipolygon_wel_goed.jpg


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#34 2016-11-08 07:31:18

escada
Moderator
Registered: 2011-08-13
Posts: 1,743

Re: Edits in de Krimpenerwaard

AnkEric wrote:

want ook "picnic_table" mappen we ook bij voorkeur onjuist als "picnic_site"

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.

Offline

#35 2016-11-08 08:58:03

mboeringa
Member
Registered: 2014-06-29
Posts: 345

Re: Edits in de Krimpenerwaard

AnkEric wrote:

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.

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

Offline

#36 2016-11-08 09:24:46

BikePC
Member
From: Zoetermeer NL
Registered: 2010-06-09
Posts: 548

Re: 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.


GPS: Garmin Edge 800 / Edge Touring Plus / Edge Explore

Offline

#37 2016-11-08 09:48:06

eggie
Member
From: Dordrecht
Registered: 2010-09-03
Posts: 3,645

Re: Edits in de Krimpenerwaard

@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.

Last edited by eggie (2016-11-08 09:51:53)

Offline

#38 2016-11-08 11:14:44

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

eggie wrote:

Het is een lastig stukje. Volgens mij is het nu weer goed.

Het is nog lang niet goed sad

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.

Krimpenerwaard_JOSM_validation.jpg

Last edited by AnkEric (2016-11-08 11:19:23)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#39 2016-11-08 11:53:28

eggie
Member
From: Dordrecht
Registered: 2010-09-03
Posts: 3,645

Re: Edits in de Krimpenerwaard

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.

Offline

#40 2016-11-08 12:35:51

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

mboeringa wrote:
AnkEric wrote:

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.

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

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!

Last edited by AnkEric (2016-11-08 14:32:00)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#41 2016-11-08 16:57:22

BikePC
Member
From: Zoetermeer NL
Registered: 2010-06-09
Posts: 548

Re: Edits in de Krimpenerwaard

@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 sad
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 smile

Last edited by BikePC (2016-11-08 17:00:01)


GPS: Garmin Edge 800 / Edge Touring Plus / Edge Explore

Offline

#42 2016-11-09 17:34:05

BikePC
Member
From: Zoetermeer NL
Registered: 2010-06-09
Posts: 548

Re: Edits in de Krimpenerwaard

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


GPS: Garmin Edge 800 / Edge Touring Plus / Edge Explore

Offline

#43 2016-11-10 14:14:50

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

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.

Last edited by AnkEric (2016-11-10 18:52:50)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#44 2016-11-14 10:49:05

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

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!

Krimpenerwaard_nood_verband.jpg

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.


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#45 2016-11-14 11:06:48

Commodoortje
Member
Registered: 2013-10-31
Posts: 2,414

Re: Edits in de Krimpenerwaard

AnkEric wrote:

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.

Offline

#46 2016-11-14 11:30:06

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

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:

Krimpenerwaard_slordig.jpg

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.

Last edited by AnkEric (2016-11-14 13:50:26)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#47 2016-11-14 14:21:53

dvdhoven
Member
From: Deventer Colmschate
Registered: 2015-03-09
Posts: 2,365

Re: Edits in de Krimpenerwaard

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.


Dick van den Hoven

Offline

#48 2016-11-14 14:56:19

eggie
Member
From: Dordrecht
Registered: 2010-09-03
Posts: 3,645

Re: Edits in de Krimpenerwaard

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

Offline

#49 2016-11-14 18:51:34

AnkEric
Member
Registered: 2010-03-07
Posts: 373

Re: Edits in de Krimpenerwaard

Zelfde laken en pak:

Krimpenerwaard_Crossing_ways.jpg

Maar... wat is het nut van dat wat ik gewoon als "werk" beschouw:

Krimpenerwaard_To_Do.jpg

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:

Krimpenerwaard_simple_of_multipolygon.jpg

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.

Last edited by AnkEric (2016-11-14 19:27:12)


Mapper: willy-nilly.
Dissatisfied User: bicycle=*, barriers, surface=gravel, routing, highway=service, wetland=*, building=*, oneway:bicycle=no, duplicate POI, hotel-restaurant, eetcafe, missing/incorrect access, track/path, brandgang, vending_machine, picnic_table/picnic_site, multipolygons, errors, missing priorities (http://wiki.openstreetmap.org/wiki/Good_practice).

Offline

#50 2016-11-14 21:55:28

dvdhoven
Member
From: Deventer Colmschate
Registered: 2015-03-09
Posts: 2,365

Re: Edits in de Krimpenerwaard

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.


Dick van den Hoven

Offline

Board footer

Powered by FluxBB