You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***

#1 2022-06-27 12:07:29

JeroenHoek
Member
Registered: 2014-06-22
Posts: 1,029

Bad OSM Mapping to be resolved by Renderer (?)

AnkEric is weer terug.

Nu is iedereen in principe welkom om de kaart aan te passen zolang de wijzigingen niet destructief zijn en correct, maar bij deze changesets snap ik even niet wat hier de bedoeling is.

In al zijn/haar changesets onder dit nieuwe account worden wegen opgesplitst zonder dat de tags op de nieuwe delen anders zijn. In het datamodel van OpenStreetMap is dat een betekenisloze actie. Het maakt niet uit of een way uit 10 stukjes of uit één stuk bestaat: als deze aan elkaar vast liggen en dezelfde tags hebben, dan is dat voor renderers, routeplanners, en andere data consumers bijna hetzelfde.

Het verandert voor de meeste renderers wel één ding, en dat is dat ze vaak noodgedwongen de straatnaam onnodig herhalen op de nieuwe segmenten. In die zin maakt het de kaart dus niet beter.

Voorbeeld:

https://www.openstreetmap.org/changeset/122868049

Het commentaar in alle changesets is steeds ongeveer hetzelfde:

AnkEric_DONE wrote:

Split way(s) to facilitate Renderer to {set bicycle=no} on highway segment(s)

Helaas dezelfde robottaal als voorheen.

De reden dat AnkEric dit doet, vermeldt hij/zij op een van de changesets:

AnkEric_DONE wrote:

Yes both segments are still the same on OSM, but "not on the ground".

Last segment should be tagged with [bicycle=no/use_sidepath] +/- [mofa=no/use_sidepath] +/- [moped=no/use_sidepath] +/- [foot=no/use_sidepath].

I don't want to survey or investigate what's correct. It is even possible that there is a bicycle crossing here.

Therefore I will Render as [bicycle=no] + [foot=no] on my OWN map. Since - IMO - this is most correct / likely for my own Cycling/Walking Map.

But to Render both segments differently the way has to be Split. Renderer cannot - yet - Split ways that have to be Split for correct Rendering.

Rendering by mkgmap:

# 1042856899 _ 52.0730551 _ 5.0695901 _ Hickorylaan _ unclassified
highway=* & osmid()=1042856899 & length()<60 {set bicycle=no; set foot=no; echo "[Hickorylaan]"}

# 1042860160 _ 52.1281225 _ 5.0526457 _ Straatweg _ residential
highway=* & osmid()=1042860160 & length()<15 {set bicycle=no; set foot=no; echo "[Straatweg]"}

Dit is dus letterlijk tagging for the renderer.

AnkEric is in het verleden altijd heel actief bezig geweest met het toevoegen van foot=use_sidepath en bicycle=use_sidepath op korte wegsegmenten tussen een fietspad en een weg, waar fiets en voetgangers geen gebruik van mogen maken. Dat is op zich correct, zei het erg gefocuset op iets wat de meeste mappers niet stoort (omdat het meestal segmenten betreft die toch niet routeren voor voetgangers en fietsers).

Een probleem voor andere mappers wat hiermee ontstaat is dat deze edits niet stabiel zijn. Iemand die in een gebied bezig is kan deze wegsegmenten weer aan elkaar plakken (want ze hebben dezelfde tags), en dat is ook volledig in lijn met onze richtlijnen. Dus krijgen we straks (weer) editwars, of een mapper die je na elke changeset die je doet op de hielen zit om dingen weer aan te passen naar zijn/haar voorkeur?

Last edited by JeroenHoek (2022-06-27 12:13:36)

Offline

#2 2022-06-27 12:30:28

Herrieman
Member
Registered: 2021-05-04
Posts: 91

Re: Bad OSM Mapping to be resolved by Renderer (?)

Als ik het goed begrijp is de intentie goed (verbeteren tags op verschillende wegdelen), maar de uitvoering niet (want die tags worden niet doorgevoerd in OSM, maar alleen in eigen data). Niet echt direct een probleem voor ons, maar zeker ook geen verbetering van de kaart.
Ik plak inderdaad ook wel eens wegen aan elkaar als ze exact dezelfde tags hebben. Als er een goede reden is om ze toch te splitsen verwacht ik dat terug te zien in bijvoorbeeld een note of fixme.

Offline

#3 2022-06-27 12:52:55

Martin Borsje
Moderator
From: Puth
Registered: 2011-10-22
Posts: 3,181

Re: Bad OSM Mapping to be resolved by Renderer (?)

Wegdelen met gelijke tags die niet verschillen in deelname aan een routerelatie kunnen en dienen m.i. samengevoegd te worden en zeker niet opgesplitst.

Los van het feit dat opgebroken wegdelen steeds een naamsvermelding krijgen, wat slordig, niet nodig is, is er simpelweg geen reden gelijke wegdelen te splitsen in OSM. Als je dat om wat voor onbegrijpelijke reden dan ook voor jezelf wilt, dan doe je dat maar in een privélaag op je eigen computer.

Offline

#4 2022-06-27 14:37:19

E de Wit
Member
Registered: 2018-11-02
Posts: 125

Re: Bad OSM Mapping to be resolved by Renderer (?)

Aan de source van changeset: https://www.openstreetmap.org/changeset/122910641 te lezen is AnkEric op de hoogte van dit draadje.

Nu wordt er een fixme=<text> toegevoegd aan het korte stukje weg.
Volgens mij kost het minder moeite de juiste  tags met *=use_sidepath erop te zetten....

Misschien dat iemand dit kan bevestigen / ontkrachten, maar zover ik JOSM ken wordt het historie van een object altijd op het lijnelement met de meeste nodes geplaatst. In onderstaande changeset is dit niet het geval:
https://www.openstreetmap.org/changeset/122910731
Je moet dan voor het knippen meer nodes op het korte stukje plaatsen dan het lange om de historie 'over te zetten'.
Dit is nadelig voor toekomstige bewerkingen aan de weg die dan plots geen historie meer heeft.

Offline

#5 2022-06-27 14:41:22

A67-A67
Member
Registered: 2014-04-08
Posts: 783

Re: Bad OSM Mapping to be resolved by Renderer (?)

Het splitsen van de ways om bicycle=use_sidepath o.i.d. op het deel te zetten waar je niet mag fietsen, lijkt me geen probleem, maar dat moet je dat ook wel doen. Dit lijken me half-afgemaakte wijzigingen. Meestal is het aan de tags op de kruisende weg wel duidelijk welke tags de correcte zijn en dan kun je dat ook gewoon kopieren naar het wegdeel waar je niet mag fietsen.

Offline

#6 2022-06-27 14:49:49

JeroenHoek
Member
Registered: 2014-06-22
Posts: 1,029

Re: Bad OSM Mapping to be resolved by Renderer (?)

E de Wit wrote:

Nu wordt er een fixme=<text> toegevoegd aan het korte stukje weg.
Volgens mij kost het minder moeite de juiste  tags met *=use_sidepath erop te zetten....

A67-A67 wrote:

Dit lijken me half-afgemaakte wijzigingen.

Mijn vermoeden is dat AnkEric niet bij wil dragen aan betere data, om persoonlijke redenen. AnkEric heeft als mapper genoeg ervaring om bicycle=use_sidepath etc. correct toe te passen. Ik zou dat vermoeden graag ontkracht zien overigens door AnkEric zelf en niet op basis van aannames hoeven te redeneren.

Zoals het nu staat komt dit op mij over als treitergedrag van iemand die in de clinch lag met andere mappers bij het vorige account (AnkEric zonder _DONE).

Offline

#7 2022-06-27 15:35:09

Maarten Deen
Member
Registered: 2010-05-20
Posts: 489

Re: Bad OSM Mapping to be resolved by Renderer (?)

Als ik zijn opmerking in de startpost lees weet hij niet hoe het ter plaatse is maar neemt hij aan dat het zo is. Daarom wil hij het niet in OSM taggen maar wel op zijn eigen kaart. En bicycle=no/foot=no moet je eigenlijk ook alleen zetten als de borden of regels dat aangeven (alhoewel ik daar zelf ook wel tegen zondig).
Tja, ik vind het geen erg nuttige changes maar het kan in OSM natuurlijk ook niet echt kwaad.
Zolang hij ook maar niet gaat zeuren als anderen die wegen weer gaan samenvoegen.

Ik zou me hier niet druk over maken.

Offline

#8 2022-06-27 16:11:44

JeroenHoek
Member
Registered: 2014-06-22
Posts: 1,029

Re: Bad OSM Mapping to be resolved by Renderer (?)

Maarten Deen wrote:

Tja, ik vind het geen erg nuttige changes maar het kan in OSM natuurlijk ook niet echt kwaad.

Met al die fixme-tags zadel je andere mappers wel op met extra werk.

Maarten Deen wrote:

En bicycle=no/foot=no moet je eigenlijk ook alleen zetten als de borden of regels dat aangeven (alhoewel ik daar zelf ook wel tegen zondig).

Dat is zo, maar dat is hier niet het probleem. Deze wegsegmenten kunnen prima bicycle=use_sidepath krijgen, want er is een verplicht fietspad naast. Doorgaans zijn die ook duidelijk als G11 of G12a getagd.

Offline

#9 2022-07-02 08:01:53

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

Re: Bad OSM Mapping to be resolved by Renderer (?)

JeroenHoek wrote:

Het verandert voor de meeste renderers wel één ding, en dat is dat ze vaak noodgedwongen de straatnaam onnodig herhalen op de nieuwe segmenten. In die zin maakt het de kaart dus niet beter.

Ik ben in principe redelijk neutraal wat dit issue betreft, en kan je ook vertellen dat het technisch weldegelijk mogelijk is om dergelijke lijnen weer aan elkaar te knopen "voor de renderer", tijdens post-processen na import. Voor gegeneraliseerde wegelementen voor kleine schalen (b.v. 1:100k-1:M) doe ik dit in mijn eigen Renderer.

Wel vind ik het grappig dat je juist de rendering aanhaalt als een reden om de weglijnen niet te splitsen, is dat niet in essentie net zo goed "taggen voor de Renderer"? wink

Een GIS als ArcGIS of QGIS, hebben er overigens helemaal geen moeite mee om "herhaling" te voorkomen tijdens het plaatsen van labels, daar zijn gewoon opties voor in de "label engine". Dat het in de huidige "web" frameworks vaak niet gebeurd, is een andere zaak...

Offline

#10 2022-07-02 10:02:20

Famlam
Member
From: Nijmegen
Registered: 2019-11-10
Posts: 216

Re: Bad OSM Mapping to be resolved by Renderer (?)

Een ander argument tegen het onnodig splitsen van wegen is dat het erg makkelijk is om per ongeluk een klein wegsegmentje te missen, wanneer je een weg aanpast. Daarom voeg ik ze meestal samen wanneer ik een wegdeel aanpas en ze in een rechte lijn liggen zonder andere tagging.

Offline

#11 2022-07-28 19:21:02

Friendly_Ghost
Member
From: Netherlands
Registered: 2020-05-20
Posts: 357

Re: Bad OSM Mapping to be resolved by Renderer (?)

Dit gaat toch nergens meer over? https://www.openstreetmap.org/changeset/124196071

Last edited by Friendly_Ghost (2022-07-28 19:22:13)

Offline

#12 2022-07-28 19:25:24

Cartographer10
Member
Registered: 2019-07-02
Posts: 413

Re: Bad OSM Mapping to be resolved by Renderer (?)

Friendly_Ghost wrote:

Dit gaat toch nergens meer over? https://www.openstreetmap.org/changeset/124196071

Eens. Alhoewel het technisch niet fout is slaat het naar mijn mening ook nergens op dit te doen. Map het dan zelf. Overal zie je van die kleine changesets van AnkEric

Offline

#13 2022-07-28 19:26:29

JeroenHoek
Member
Registered: 2014-06-22
Posts: 1,029

Re: Bad OSM Mapping to be resolved by Renderer (?)

Friendly_Ghost wrote:

Dit gaat toch nergens meer over? https://www.openstreetmap.org/changeset/124196071

Nee, die kleine stukjes tussen rotonde en fietspad horen dan ook geen cycleway=lane meer te hebben. Maar het gaat AnkEric hier niet om correcte tags; enkel om het gedrag van de eigen privérenderaar.

Offline

#14 2022-07-28 19:45:29

Famlam
Member
From: Nijmegen
Registered: 2019-11-10
Posts: 216

Re: Bad OSM Mapping to be resolved by Renderer (?)

Idem voor deze: https://www.openstreetmap.org/changeset/124087736
Vooral de fixme op https://www.openstreetmap.org/way/1081365920 . Ziet iemand (op historische of up to date luchtfoto's) waar die marked crossing zou zijn?
(Ik zal hier komend weekend eens langsfietsen, want de fietspaden hebben wel een update nodig, maar dat is ongerelateerd aan zijn edit)

Voorstanders voor een bulk-edit om al die fixme's er landelijk gewoon af te gooien roll?

Offline

#15 2022-07-28 20:03:43

Martin Borsje
Moderator
From: Puth
Registered: 2011-10-22
Posts: 3,181

Re: Bad OSM Mapping to be resolved by Renderer (?)

Famlam wrote:

Idem voor deze: https://www.openstreetmap.org/changeset/124087736
Vooral de fixme op https://www.openstreetmap.org/way/1081365920 . Ziet iemand (op historische of up to date luchtfoto's) waar die marked crossing zou zijn?
(Ik zal hier komend weekend eens langsfietsen, want de fietspaden hebben wel een update nodig, maar dat is ongerelateerd aan zijn edit)

Voorstanders voor een bulk-edit om al die fixme's er landelijk gewoon af te gooien roll?

Volgens de laatste foto heeft de ZZ van de rotonde en update gehad en is die fixme geeneens meer van toepassing. Ik heb e.e.a. aangepast, https://www.openstreetmap.org/changeset/124199786

Offline

#16 2022-07-28 20:05:41

Martin Borsje
Moderator
From: Puth
Registered: 2011-10-22
Posts: 3,181

Re: Bad OSM Mapping to be resolved by Renderer (?)

JeroenHoek wrote:
Friendly_Ghost wrote:

Dit gaat toch nergens meer over? https://www.openstreetmap.org/changeset/124196071

Nee, die kleine stukjes tussen rotonde en fietspad horen dan ook geen cycleway=lane meer te hebben. Maar het gaat AnkEric hier niet om correcte tags; enkel om het gedrag van de eigen privérenderaar.

De ligging van de fietspaden is sowieso anders en deze voegen zich pas veel later aan de hoofdrijbaan. Onzorgvuldig gemapt. En foot=yes behoeft toch niet op een cycleway in NL?

Offline

#17 2022-07-28 21:44:26

JeroenHoek
Member
Registered: 2014-06-22
Posts: 1,029

Re: Bad OSM Mapping to be resolved by Renderer (?)

Martin Borsje wrote:

En foot=yes behoeft toch niet op een cycleway in NL?

Niet nodig, maar het kan ter verduidelijking in situaties waar foot=use_sidepath ook voorkomt op fietspaden in de buurt.

Offline

#18 2022-07-28 22:06:58

Famlam
Member
From: Nijmegen
Registered: 2019-11-10
Posts: 216

Re: Bad OSM Mapping to be resolved by Renderer (?)

Martin Borsje wrote:

Volgens de laatste foto heeft de ZZ van de rotonde en update gehad en is die fixme geeneens meer van toepassing. Ik heb e.e.a. aangepast, https://www.openstreetmap.org/changeset/124199786

Dat bedoelde ik met:

(Ik zal hier komend weekend eens langsfietsen, want de fietspaden hebben wel een update nodig, maar dat is ongerelateerd aan zijn edit)

wink . (Ik heb trouwens ook nog een achtergebleven stukje bicycle=use_sidepath verwijderd )

Last edited by Famlam (2022-07-29 01:33:38)

Offline

#19 2022-07-29 20:43:06

Friendly_Ghost
Member
From: Netherlands
Registered: 2020-05-20
Posts: 357

Re: Bad OSM Mapping to be resolved by Renderer (?)

Hier ook: https://www.openstreetmap.org/changeset/124198122
en in vele andere changesets. Hij selecteert een weg, deelt deze in tweeën, past verder niets aan, updatet onnodig meerdere busroutes en maakt ook niet duidelijk waarom deze weg in OSM gesplitst moet worden. Die comments zijn ook waardeloos, want hij doet helemaal niets met access tags.

Ik vind dat dit afbreuk doet aan hoe wij mappen in OSM.

Offline

#20 2022-08-02 22:44:07

Tilia_J
Member
Registered: 2019-01-17
Posts: 97

Re: Bad OSM Mapping to be resolved by Renderer (?)

Ik begin mij hier ook steeds meer aan te storen en heb even met een changeset comment mijn mening gegeven: https://www.openstreetmap.org/changeset/124404578

Offline

#21 2022-08-03 06:08:15

Martin Borsje
Moderator
From: Puth
Registered: 2011-10-22
Posts: 3,181

Re: Bad OSM Mapping to be resolved by Renderer (?)

De tijdstippen waarop de laatste, vrijwel identieke denk ik, changesets uitgevoerd worden verontrusten mij.

Kunnen we niet die changesets gewoon terugdraaien tot hij zich hier in het forum meldt?

En wellicht een tijdelijke ban door de DWG?

Offline

#22 2022-08-03 06:38:26

PeeWee32
Member
From: Leusden, NL
Registered: 2010-11-28
Posts: 1,300
Website

Re: Bad OSM Mapping to be resolved by Renderer (?)

Changesets terugdraaien die niets aan OSM hebben toegevoegd en alleen hebben gezorgd voor een toename van het aantal records in de (actuele) OSM database (performance) lijkt me alleszins gerechtvaardigd. Zeker als die changesets bij andere mappers lijdt tot irritatie. Probleem hierbij is voor mij voornamelijk dat deze mapper er helaas dan weer voor zorgt dat anderen hun kostbare energie steken in iets waar osm niets mee opschiet. Gezien de geschiedenis van deze mapper verwacht ik geen heil van enig overleg. Een ban door de DWG (liever permanent dan tijdelijk) zou ik prima vinden.

Offline

#23 2022-08-03 11:23:47

Allroads
Member
Registered: 2011-03-05
Posts: 3,305

Re: Bad OSM Mapping to be resolved by Renderer (?)

Ik heb geen moeite met die knippen, immers ze moeten er toch komen bij vele afslagen, want op veel plaatsen hoort die *=use_sidepath te worden gezet. Eerder deed ik dat niet, mede doordat ik de tags van Ankeric zag ben ik dat gaan doen, Vaak samen met zijn Mapillarry beelden.
In het verleden is op het forum door andere contributers aangeven, dat men dat wel makkelijk vindt, een knip bij een kruising bij het aanleggen van de route relaties.
Ik knip bij kruisingen vaak en zet indien mogelijk ook de access tags. Voor alle vervoersvormen, want door andere wel eens wordt vergeten, ik denk wel eens bewust, een keuze.

Als je de moeite neemt om ze samen te voegen kan je ook de moeite nemen om het correct te doen. Immers die controle doe je al. Je bent ter plekke bezig. De database beter te maken. Dat is ons doel.

Zelf navigeer ik ook veel topografisch, wat wil dat zeggen, eigenlijk het oude kaartrouteren, in een nieuw jasje (smartphone), Waarbij ik met een style wegkleuren aangeef waar ik wel of niet mag komen. rood/ groen/geel (destination)/geen kleur, voor de gebruikte vervoersvormen.
Dan maak je geen gebruik van een routeringsberekening.
En zo gebruikt Ankeric het ook op, ik meen, met zijn Garmin.
De reden van je wordt bij, zeg maar, A naar B routering toch wel tegen gehouden, dus ik doe het maar niet, is een keuze, in mij optiek een verkeerde.
Je doet er mij ook een plezier mee als men het wel goed tagt, volledig.

Mentaliteit:
Aan een kant kan ik het wel waarderen dat hij een account gebruikt, die naar hem wijst en niet anderom.
In eerder discussie meen ik mij te herinneren dat andere aangeven, zet dan een fixme, dat heeft Ankeric dan ook gedaan. ( Wellicht van, jullie zeggen,  ik doe het, jullie weten het zo goed)
Nu met omschrijving, waarom geknipt.

Nu kom je bij het punt, statement gemaakt.
Tot de orde (werkwijze) van de dag, het verbeteren (aanvullen) van de Openstreetmap data.

Ik roep dan ook op, Ankeric om de tagging te zetten. Dat jij en andere er gebruik van kunnen maken. Zo ook aan alle andere om ook de goede taggijng te zetten op de juiste plaats voor alle vervoersvormen.

Ik zie nogal eens dat alleen bicycle=use_sidepath wordt gezet en niet voor mofa foot moped. Soms denk ik, dat doet men bewust, dat is ook een vorm van mentaliteit, die ik niet waardeer. Je bent nu ter plekke bezig neem het mee, als andere het later moet controleren zijn we er met ons alle meer tijd aan kwijt. Tenzij je niet de kennis hebt om dat te kunnen,

Samen maken we de database beter, ga daar voor, vele hebben daar plezier van. Vele die je niet kent, doe het voor hun.

Offline

#24 2022-08-03 12:44:41

Tilia_J
Member
Registered: 2019-01-17
Posts: 97

Re: Bad OSM Mapping to be resolved by Renderer (?)

Allroads wrote:

Ik heb geen moeite met die knippen, immers ze moeten er toch komen bij vele afslagen, want op veel plaatsen hoort die *=use_sidepath te worden gezet. Eerder deed ik dat niet, mede doordat ik de tags van Ankeric zag ben ik dat gaan doen, Vaak samen met zijn Mapillarry beelden.

Je hebt op zich een punt. Ik ben er dankzij Ankeric mij ook bewuster van geworden en voeg steeds vaker cycleway=lane, use sidepath en sidewalk=yes toe. Echter: Ik vind het niet netjes dat hij enkel opknipt om het werk bij anderen neer te leggen.

Allroads wrote:

Als je de moeite neemt om ze samen te voegen kan je ook de moeite nemen om het correct te doen. Immers die controle doe je al. Je bent ter plekke bezig. De database beter te maken. Dat is ons doel.

Deze redenatie kunnen we ook omdraaien door te stellen "wie knipt, zet ook de tagging".

Allroads wrote:

Ik roep dan ook op, Ankeric om de tagging te zetten. Dat jij en andere er gebruik van kunnen maken. Zo ook aan alle andere om ook de goede taggijng te zetten op de juiste plaats voor alle vervoersvormen.

Dit dus. Dat is functioneel opknippen. De huidige werkwijze niet, en ik struikel inmiddels redelijk vaak over dit soort changesets bij het reviewen.

Offline

#25 2022-08-03 13:13:22

Martin Borsje
Moderator
From: Puth
Registered: 2011-10-22
Posts: 3,181

Re: Bad OSM Mapping to be resolved by Renderer (?)

Tilia_J wrote:

Deze redenatie kunnen we ook omdraaien door te stellen "wie knipt, zet ook de tagging".

Precies; alles - zonder reden wellicht - opknippen en het niet gelijk afmaken slaat nergens op.

Offline

Board footer

Powered by FluxBB