Naar aanleiding van de bekendmaking van de gemeente Haarlemmermeer ([Halfweg: aanleg F200 | gemeente Haarlemmermeer](https://F200 aanleg in Haarlemmermeer) ) wil ik graag het huidige fietspad traject) immers het is slechts een verbreding en asfalt upgrading van de bestaande fietspaden op het traject tussen Haarlem, Halfweg & Amsterdam de vindbare naam: F200 geven zonder eventuele lokale bestaande namen te verwijderen.
Iemand tips dit elegant op te lossen ? Gemeente Haarlem & Amsterdam hebben hun deel al jaren terug opgeleverd. Gemeente Haarlemmermeer gaat rond september hun deel (fase 10/10) nu pas opleveren omdat de plannen door gemeenteraadswissel in die gemeente F200-planaanpassing tot gevolg had. Zie ook deze Wikipedia pagina: Snelfietsroute F200 - Wikipedia.
Als iemand een briljant idee heeft wil ik het recreatieve fietspad ten noorden van A200/N200 & F200 op dezelfde manier de vindbare naam G200 geven.
Alle nuttige input is welkom !
Dit kan als een routerelatie worden toegevoegd, vergelijkbaar met andere snelfietsroutes: Relation: MaasWaalpad (11116042) | OpenStreetMap
Dit soort nummers worden Meestal toegevoegd met ref=
Bij autowegen gebeurd dit zowel op het wegdeel als de route relatie.
Bij fietspaden/fietswegen heb ik dit tot nu toe alleen nog gezien op de relatie zelf:
Dank jullie wel A67-A67 & Tjuro !
Als ik zo’n route relatie maak kan dat dan niet tot gevolg hebben dat andere eventuele bestaande reatie’s verbroken worden ?
Graag jullie kritische blik en/of verbeteringen als ik het toch net niet goed genoeg heb uitgevoerd.
Wanneer je een routerelatie gaat inleggen dan kan dat geen kwaad…Gaat zelfs met editor iD nog goed. Maar op het moment dat je gaat knippen met editor iD en er lopen al routerelaties gaat het mis.
Het kan alleen goed met editor JOSM. Die maakt geen warboel van andere relaties… , maar zelfs dan zul je alle relaties ‘moeten’ controleren.
De naam van de ‘snelroute’ moet inderdaad op de relatie en niet op de weg. Veel paden zullen immers gewoon de straatnaam als naam hebben.
Bedankt voor de info Eggie.
Een globale ‘survey’ laat zien dat de F200 als relatie geen probleem gaat opleveren omdat de afzonderlijke stukken fietspad geen eerdere relatie bevatten.
Dit in tegenstelling tot de te maken G200 relatie want daar zitten wel stukken bij die onderdeel zijn van andere route relatie’s 
…
Beste oplossing voor t maken van de G200 relatie ?
Ter verduidelijking (voor diegene die mijn link verwijzingen & links die daar dan ook weer in verwerkt zitten niet of niet helemaal gelezen hebben) :
F200 is de snelfiets route: Haarlem (Amsterdamse poort) <———> Amsterdam (Haarlemmerpoort) via Halfweg.
G200 is de noordelijker gelegen recreatieve route van dezelfde bestemmingen die (ook met rekeninghouding van toekomstig onderhoud van beider trajecten) op verschillende punten met elkaar verbonden zijn.
Het is geen probleem als een fietspad onderdeel is van meerdere relaties, dat gebeurd regelmatig bijv als een pad onderdeel is van een wandel en fietsroute.
Die delen dus gewoon lid maken van zowel de F200 als de G200 relatie.
Een routerelatie is een lijstje wegen. Een weg kan in net zoveel routerelaties zitten als er routes overheen lopen.
Als je in 1 relatie werkt, kan je de andere routerelaties niet verbreken.
Maar als je een weg splitst, samenvoegt of verwijdert, moet je alle routes die eroverheen lopen controleren en repareren.
Ik vraag me af waarom ref überhaupt gebruikt wordt op de wegdelen in OSM ongeacht of het een weg is voor auto’s of weg voor fietsers…
Kwa OSM onderhoudbaarheid (gemeenten kunnen op termijn besluiten een [snel]route via andere bestaande wegen te laten lopen door uiteenlopende redenen) zou mijn voorkeur uitgaan naar alleen een route-relatie voor alle wegen.
Graag jullie mening want dan kan ik gefundeerd F200 & G200 aan gaan maken.
Dit ligt in verband met dat carto refs niet renderd vanuit de route relatie. zie:
Tjuro bedankt voor de documenten !
GitHub docs vluchtig doorgelezen even een korte samenvatting:
Door een niet opgeloste rendering issue moet je beide gebruiken (ref=* en route relatie) al is dit niet ideaal natuurlijk op 2 punten:
OSM mapping onderhoudbaarheid
Zodra een gemeente een route op verschillende wegdelen omlegt moet je de hele oude route af om ref= waarden op wegdelen die niet meer onderdeel zijn van die route weghalen en nieuwe wegdelen met ref= waarden toevoegen…
Data redundantie
- Nadeel: dubbele data opslag
- Voordeel: extra controle middel of latere aanpassingen op zo’n route wel goed doorgevoerd is.
Daarbij wel aangemerkt als Cruyfiaans voordeel (elk nadeel heeft zo zijn voordeel)
De rendering issue bestaat bijna 10 jaar en zou alleen al uit jubileumkado uitgangspunt opgelost moeten worden 
Tjuro weet jij bij wie ik wezen moet om dit weer onder aandacht te brengen ?
Een fietsrouterelatie met ref kun je duidelijk zien op de beide fietslagen op osm.org en op websites als cycling.waymarkedtrails.org.
Als je zo’n relatie aanmaakt in de iD-editor, vooral als het je eerste keer is, dan zullen er wel foutjes inzitten. Ik wil best die foutjes eruit halen als je de relatie heb aangemaakt.
En dus taggen we voor deze renderer… die op vele andere punten niet wil renderen wat wij taggen. IK begin behoorlijk de p in te krijgen van OSM Carto.
Helemaal top !
Als ik m aangemaakt heb zet ik in deze post een map verwijzing zodat je er snel naar toe kan springen.
Peter, adem in adem uit… de wereld is niet perfect samen kunnen we ‘m wel perfecter (proberen) te maken…
1 dag terug zat ik in net zo’n ‘dip’ als jij en een andere leden trokken me daar weer uit…
Dat gun ik jou ook vandaar mijn reactie
Ik heb geen dip maar wel specifieke dingen waar ik toenemend genoeg van krijg. Carto ga ik geen moeite meer voor doen, been there, done that, case closed.
Helemaal top !
Als ik m aangemaakt heb zet ik in deze post een map verwijzing zodat je er snel naar toe kan springen.
Ik ben begonnen met ref=F200 waarden op de fietspaden te plaatsen zodat als ik op een verkeerde manier later de relatie’s gelegd zou hebben in ieder geval zichtbaar is welke traject stukken onderdeel zouden moeten zijn van F200.
Als de relatie’s van F200 goed(gekeurd) zijn ga ik op dezelfde manier de noordelijker gelegen recreatieve route G200 aanmaken.
Ik heb hier toch wat moeite mee:
Kijk, als je een A-weg een ref geeft, is dat ook echt omdat die fysieke weg zo heet. Soms gaat het om een route, dan klopt het eigenlijk niet meer als ref van het object, en dan maken we er een routerelatie van die de ref draagt. Soms loopt een snelweg alleen een stukje samen met een andere, dan kan je de beide losse delen wel de ref geven, want beide delen worden daar afzonderlijk mee aangeduid.
Hier hebben de vele losse wegstukken echt niet dezelfde ref. Ik vind dat de ref alleen op de relatie hoort. De algemene kaart hoort van de wegdelen de wegnaam te tonen, niet de ref van de route die er overheengaat.
Mocht er later één lang fietspad gemaakt worden dat niet allerlei min of meer aangepaste bestaande wegen, straten, fietspaden en verbindingsstukjes aan elkaar knoopt, dan zou dat fietspad MI een echte naam krijgen en dan zou F200 ook de ref van het fietspadobject kunnen zijn.
Vergelijk: Rotterdam eo heeft genummerde (en als zodanig bewegwijzerde) fietsroutes, bijvoorbeeld de 11 loopt van NIeuwerkerk aan de IJssel tot Oud-Beijerland. Het is een routerelatie, en de ref van de relatie is 11. Maar het zou fout zijn om alle leden ref 11 te geven.
Och, je gooit gewoon de juist wegdelen in de relatie (het is er maar één), kijkt of-ie goed is, en dan hoppa naar OSM knallen.
De relatie is niet meer dan een zakje wegdelen waar je achtereenvolgens overheen fietst. De relatie doet niks met de wegen zelf. Als het fout is, kan je de relatie weggooien zonder dat er iets met de wegen gebeurt. Dit in tegenstelling tot het zetten van ref tags, dat verandert alle wegdelen.
Euhmmm ik heb navraag gedaan hier, heb GitHub pagina’s doorgespit & een verkortte samenvatting gepost hier waarbij de conclusie was zowel ref als routerelatie maken.
Dacht echt dat ik goed bezig was… ik stop mijn werkzaamheden tot ik van Peter een handleiding op OSM-wiki kan lezen hoe dit soort situatie’s aan te pakken…