Tja, zowel voor service en residential is wat te zeggen, dus wat mij betreft geen probleem.

> sommige routers hebben problemen met die stukjes toegangsweg voor fietsroutering.

Ik hou me actief bezig met brouter maar vraag me af welke routers problemen hebben met highway=service voor de fiets.

Hoi,

Bedankt voor het bijwerken!

Een opmerking over cycleway=opposite, dat gebruiken we al een tijd niet meer in Nederland, zie https://forum.openstreetmap.org/viewtopic.php?id=65612

Kan je way/6860738 en way/6860741 aanpassen?

Het zou goed zijn ook oneway:mofa=no en oneway:moped=no/yes toe te voegen

Groeten.

Ja, oneway:bicyle=no is duidelijker en je hebt ook nog oneway:mofa en oneway:moped om het volledig te maken.

ik heb het aangepast in changeset/130083545

Wat is een "de facto" fietsstrook?

Op PDOK zie ik geen fietsstrook en dat fietsen tegen het eenrichtingsverkeer in mogen is al aangeven door oneway:bicycle=no.

cycleway=opposite_lane is ook outdated, zie https://forum.openstreetmap.org/viewtopic.php?id=65612

Hoi,

Bedankt voor de update.

Wat betreft way/557501241 en way/102949997, cycleway=opposite is outdated, gebruikt oneway:bicyle=no in plaats daarvan.

Zie ook https://forum.openstreetmap.org/viewtopic.php?id=65612

Bedankt voor het repareren!

Nog even gekeken maar dat inderdaad wat samengevoegd en later weer gesplitst, ik vermoed dat ik bij het samenvoegen een fout heb gemaakt.

Hi Tom,

I can not follow you, the Prins Bernardstraat does not connect with the Helsdingse Achterweg. Please indicate the OSM ID's for the ways you see a problem.

As far as I can see OSM is mapped following what is in BAG, the only thing I am unsure about is if this way, way/7103940, is called Burgemeester Jonkheer Hoeufftlaan or Helsdingse Achterweg.

Sorry for using the word "removing" 🙃 You do some operation so that there are no two camp sites.

Wat is you conclusion form the tagging list discussion?

> My database table for drawing campsites does not contain site-relations anymore.

That explains why you see it not as a problem, but to me it means that my change done in this changeset was not that strange. You do remove the site tourism=camp_site relations for your database, I think it is better to do that in the actual data.

I did read the tagging list, seems to me like there is no common support for tourism=cam_site relations.

Yes, I did read your blogpost, https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/, quoting "On backcountry campsites there is often no well defined boundary. "

I did reply on that in the first alinea of my previous reply.

You are telling me multiple times I did break your map but you are not answering the question I did raise on that in my previous reply. It did solve the problem I saw.

Okay, so for backcountry sites (6/15 of this commit), there is a solution.

I see your point of the problem with the site relation and a camp place for multiple tents/caravans but what I do not understand is:

> Fact is that my map is currently incomplete[1] because you removed the camp_site tagging of the site relation.

Why? Instead of a relation=site with tourism=camp_site AND a node/way with tourism=camp_site that is part of the relation there is after my change only the node/way with tourism=camp_site

So instead of two camp_site's only one what is the "ground truth".

tourism=camp_site clearly specifies that area mapped includes toilets and beaches so inside of using a poor supported site relation I would go for a mapped area as tourism=camp_site including the parking spaces, reception and restaurant, see also the picture on the last page of https://www.waldcamping-hollenbacher-see.de/wp-content/uploads/2021/03/Waldcamping_Flyer_2021.pdf

If you want to explicitly indicate that the cafe/playground/restaurant are also open to the general public then add "access=yes" to these objects.

Yes, I did also some work to get campings in Europe cleaned up and a part of that is this change-set. Good to see you have a common interest.

I still see no reason why for this case a tourism=camp_site inside a tourism=camp_site is a good idea.

If I read tourism=camp_site, it describes the whole camp site including toilets, beaches and swimming pools and based on this I would say the site relation should be tagged with tourism=camp_site but the node not. Looking at it now, that is not what I did in this changeset.

The problem is indeed what kind of tag to give the nodes. If I read https://www.trekking-pfalz.de/service/faqs, I see only one tent is allowed so why not tourism=camp_pitch?

The commit message was clear on why I changed things, osm.wiki/One_feature,_one_OSM_element

It looks to me you already reverted my change 1 month ago

Maybe it is better to map the tourism=camp_site node as tourism=camp_pitch

Geen probleem, ja ik maak wel eens een foutje maar tot nu toe niet bij het samenvoegen van wegen op basis van de kaart van PeeWee32, alleen een situatie waar OSM Inspector niet van hield.

Bedankt voor je werk om het OV binnen OSM correct te houden.

Bedankt weer.

Ik heb weer eens geprobeerd terug te halen wat er fout was maar dat is me nog niet gelukt.

I do not have a opinion about historic=exhibit versus exhibit=historic and that discussion should not take place here but on the Wiki Talk pages, on the forum or on the tagging list.

As long as the Wiki is not updated and indicates to "historic=exhibit ‒ Use exhibit=history instead." these kind of changes will keep on happening, so please get the Wiki updated.

I find it strange to revert changes without contacting the "owner" first. On osm.wiki/JOSM/Plugins/Reverter you can find:

Do not revert changes by other users without contacting them first in a polite way and giving them enough time to reply (one week minimum). Broken data can be fixed easily, but a broken community is not so easy to restore. :)

In de note schreef je ook "fietstunnel is veel korter." maar dat kan ik niet plaatsen, zie way/7296550

Bedankt voor het opmerken van het probleem, ik had het op een gegeven moment ook wel opgemerkt maar dat had een tijd kunnen duren.

Niet de hele Antoniuslaan maar wel het stuk tussen Avelingen en Huysweer.

Dit had niets met samenvoegen te maken, wat ik heb gedaan is het splitsen van wegen ter hoogte van Huysweer de banen gesplitst maar dat is niet in deze changeset gebeurd maar in https://overpass-api.de/achavi/?changeset=126497995

Ja, dat moet het probleem zijn want ik was me bewust dat hier busrelaties op lagen en het ze nog met de relatie-editor in JOSM gecontroleerd en die zag geen probleem.

Ik zou dit een probleem van OSM Inspector willen noemen.

Een issue openen op https://github.com/geofabrik/osmi_pubtrans3 zou goed zijn, maar zonder voorbeeld wordt dat moeilijk

Dank voor de heads-up, ik zag de discussie op het forum voorbij komen.

Even gekeken naar de zuidelijke linkeroever toegangsweg maar op basis van de https://smoothefiets.ddns.net/html/verkeersbordenkaart/index.php?lat=50.851659210&lng=5.694610029&z=19.

oneway is duidelijk maar zie ik niet zo snel waar psv=yes en motor_vehicle:conditional=no @ (Mo – Fri 11.00 - 18.00; Sa 11.00 - 17.00; Su 12.00 - 17.00) vandaan komt.