Stadsregio Gent gaat dit najaar een eigen fietsknooppuntnetwerk uitrollen in het gebied waar al een provinciaal fietsknooppuntnetwerk ligt. Er is al een speciale planner ontwikkeld voor de stadsregio; die werkt rechtstreeks op OSM (overpass queries voor een planningslaag op een OSM-kaart, heb ik begrepen).
Gisteren was daarover een overleg tussen de verkeersdienst van de stad Gent (die zelf mapt) en geselecteerde OSM-ers, waaronder vmarc en ik.
Twee interessante zaken:
1. Overlap van de twee netwerken.
Provincie en stad hebben afgesproken dat de stad de punten van de provincie zal gebruiken (dus hetzelfde nummer) maar de bewegwijzering is apart, dus eigen bordjes in eigen stijl. De planner van de provincie zal de extra knooppunten van de stad niet gebruiken; alleen de planner van de stad gebruikt alle knooppunten.
2. Vooruit invoeren planning.
Men wil het geplande netwerk in OSM zetten en pas zichtbaar maken als het uitgerold is
Hiervoor zijn oplossingsvoorstellen geformuleerd hoe dit in OSM te realiseren.
Ad 1: Gebruik lcn en lcn_ref voor het stadsnetwerk, om dit te onderscheiden van het rcn provincienetwerk
- Knooppunten die in beide netwerken voorkomen hebben dus zowel een lcn_ref als een rcn_ref. In dit geval met hetzelfde nummertje, maar dat is niet persee noodzakelijk!
- Nieuwe lcn routes die precies hetzelfde zijn als bestaande routes van het provincienetwerk (dus waar geen nieuwe tussenliggende punten komen) zullen een lcn-kopie moeten krijgen. Dit komt overeen met de situatie op de weg: de provinciale bewegwijzering is gelijk aan de lokale bewegwijzering maar op andere schildjes.
- De planner voor het nieuwe stadsnetwerk gaat alleen naar lcn-routes en lcn_ref knooppunten kijken.
- Algemene planners (Knooppuntnet) zullen moeten kijken hoe ze dit gaan ondersteunen: scheiden van lcn en rcn, of integreren. In het laatste geval kan je bv. een knooppuntlijst krijgen waarin je kan zien of het volgende knooppunt een lokaal of een regionaal knooppunt is.
Ad 2. Gebruik state=proposed en de proposed: life cycle prefix
- state=proposed zetten op de geplande nieuwe routes. Deze tag bestaat, is gedokumenteeerd en wordt best veel gebruikt voor dit doel.
- state=proposed zetten op een gepland nieuw netwerk, als het in zijn geheel proposed is. Dat vervangt niet de state=proposed op de individuele elementen.
- proposed:lcn_ref= zetten waar in de toekomst lcn_ref moet komen
- Het is in dit geval aan de operator om te bepalen of de punten en routes eerst helemaal uitgerold worden en dan in één keer beschikbaar gesteld, of dat ze elke gerealiseerde route meteen openstellen. Alles in één keer dan hebben we het al gauw over een mass edit, maar wel een redelijk simpele: voor één dedicated knooppuntnetwerk alle state=proposed tags en de proposed:lcn_ref =* vervangen door lcn_ref=* met dezelfde values.
- Knooppuntnet zou iets kunnen doen met de proposed objecten, maar voor nu is afgesproken om ze niet mee te nemen in de Analyse en op de Kaart/Planner.
Opmerkingen:
Deze beide oplossingen kunnen generiek worden toegepast in de tagging, dus voor alle knooppuntnetwerken, ongeacht de geografische scope l, r, n, i en de transportmodus c, w, h, m, p, i.
Ook voor named node netwerken (in gebruik in Frankrijk, Duitsland en Zwitserland; ondersteuning in Knooppuntnet volgt binnenkort) werkt het in principe hetzelfde: gebruik xxn_name en proposed:xxn_name ipv xxn_ref en proposed:xxn_ref
Wat wordt nu niet ondersteund: als verschillende netwerken van precies hetzelfde type (scope en transport) elkaar overlappen. Dat is zowizo een situatie waar we nu ook geen oplossing voor hebben. Mocht het reguliere praktijk worden (niet bij ons denk ik, maar in het buitenland acht ik dat zeker niet uitgesloten) dan verzinnen we wel weer een generieke oplossing!
Kommentaar is welkom, wij hebben vast niet aan alles gedacht.