Bad OSM Mapping to be resolved by Renderer (?)

JeroenHoek · 2022-06-27T11:07:29.000Z

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:

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:

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?

Herrieman · 2022-06-27T11:30:28.000Z

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.

Martin_Borsje · 2022-06-27T11:52:55.000Z

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.

E_de_Wit · 2022-06-27T13:37:19.000Z

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

A67-A67 · 2022-06-27T13:41:22.000Z

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.

JeroenHoek · 2022-06-27T13:49:49.000Z

E de Wit:

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

A67-A67:

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

Maarten_Deen · 2022-06-27T14:35:09.000Z

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.

JeroenHoek · 2022-06-27T15:11:44.000Z

Maarten Deen:

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:

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.

mboeringa · 2022-07-02T07:01:53.000Z

JeroenHoek:

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”?

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…

Famlam · 2022-07-02T09:02:20.000Z

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.

Friendly_Ghost · 2022-07-28T18:21:02.000Z

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

Cartographer10 · 2022-07-28T18:25:24.000Z

Friendly_Ghost:

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

JeroenHoek · 2022-07-28T18:26:29.000Z

Friendly_Ghost:

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.

Famlam · 2022-07-28T18:45:29.000Z

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 ?

Martin_Borsje · 2022-07-28T19:03:43.000Z

Famlam:

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 ?

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

Martin_Borsje · 2022-07-28T19:05:41.000Z

JeroenHoek:

Friendly_Ghost:

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?

JeroenHoek · 2022-07-28T20:44:26.000Z

Martin Borsje:

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.

Famlam · 2022-07-28T21:06:58.000Z

Martin Borsje:

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)

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

Friendly_Ghost · 2022-07-29T19:43:06.000Z

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.

Tilia_J · 2022-08-02T21:44:07.000Z

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