Superview heeft er even geen zin in maar bedankt voor de terugkoppeling. Het zag er voor mij uit als een vreemde fout maar het is niet onlogisch met dat stuk tweerichtingen fietspad langs de Simon de Danserweg.

Hoi Eggie,

Vreemde ligging van osm.org/way/1150458845

Klopt dat?

Groeten,

Emvee

Bedankt, prima feed-back.

Ja, voor het auto-verkeer is traffic_signals=bridge niet de hoofdfunctie maar voor het fietspad wel.

Ik heb traffic_signals=bridge van de auto-verkeerslichten gehaald: osm.org/changeset/132464345

Goede vraag, eigenlijk nooit goed over nagedacht maar gevolgd wat ik tegen kwam.

Als ik osm.wiki/Tag:highway%3Dtraffic_signals lees dan staat onder pedestrians dat beide mag en onder cyclists dat het op de stopstreep is, voor de auto staat er niets.

Voor mij is de stopstreep logisch, die is onderdeel van de weg, het daadwerkelijke stoplicht staat naast de weg.

Ja dat dat was inderdaad incorrect!

Een vreemde fout gemaakt door mij, eigenlijk had er bicycle:forward=use_sidepath op gemoeten (zoals jij nu op het noordelijk stuk hebt gezet) ipv bicycle=use_sidepath en niet echt een idee hoe ik het zo fout heb kunnen doen.

Dus, bedankt voor de reparatie!

Hoi,

Ik vroeg me af op basis waarvan heb je dit fietspad, osm.org/way/4757845 oneway=no gemaakt?

PDOK laat een verkeerslicht aan één kant zien en ik zie geen stippellijnen op het midden van het pad.

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 osm.org/way/6860738 en osm.org/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 osm.org/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 osm.org/way/557501241 en osm.org/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, osm.org/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".

osm.wiki/Tag:tourism%3Dcamp_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 osm.wiki/Tag:tourism%3Dcamp_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.