BTM, geeft geen foutmelding, splitsing weg verder als one=yes en cycleway=lane dat in zou houden dat links en recht een lane is, wannneer daar geen oneway:bicycle=no of cyclway=opposite op staat maar eigenlijk zou het cycleway:right=lane moeten zijn.
Ik weet niet of dat fout is. Je kan ook interpreteren dat cycleway= lane icm met oneway=yes synoniem is aan cycleway:right=lane. Dat is tenminste wat ik met de OFM concludeer als ik die combinatie tegenkom.
Als er wel aan beide kanten een bike lane zit, moet er specifiek oneway:bicycle=no erbij gezet worden. Doe je dit niet dan geldt oneway ook voor fietsers, dus de cycleway=lane zit maar aan één kant van de weg (cycleway:right dus).
cycleway:right=lane is vollediger, maar de renderer / router kan cycleway=lane ook goed interpreteren als cycleway:right=lane als er alleen oneway=yes staat. Kwestie van afspreken wat de juiste regels zijn, cycleway=lane is eenvoudiger voor de mapper. Ik (OFM/BTM) reken dat dus niet fout/ ben niet zo kritisch.
Wat nogal eens gedaan wordt is een oneway in de tegengestelde richting voor fietsers taggen als cycleway=opposite_lane zonder oneway:bicycle=no.
vmarc herkent dat niet als oneway:bicycle=no en blijft de weg zien als oneway ook voor fietsers
vmarc herkent wel cycleway=opposite als oneway:bicycle=no
cycleway=opposite_lane houdt automatisch in oneway:bicycle=no, zelfde als cycleway=opposite (maar dan met een fietsstrook in de andere richting). Dit soort tags als cycleway=opposite of opposite_lane zijn ooit door iemand bedacht en geaccepteerd dus voorlopig moeten we er maar mee werken. Wat vmarc zegt hoeft niet altijd op te gaan, dat geldt voor alle kwaliteitscontrole tools.
Dat jij in btm dit niet als fout wil aangeven, omdat je afgeleid een bepaling kan maken is jouw keuze.
Dat taggers zich er makkelijk van af maken met alleen lane aangeven (dus voor beide kanten) is in beginsel fout. Dus aan beide kanten een fietsstrook. Terwijl dat dat er niet is. Bij dit soort gesplitste weg situaties.
Hebben we het nog niet gehad over shared_lane, wat vaak ook nog het geval is (fietssuggestiestrook).
De routeerder of de controleurtagger in jouw, een van de twee heeft een beetje de overmacht.
Dat je cycleway=lane aan beide zijden ziet is jouw interpretatie. Je kan het ook anders zien, cycleway=lane op een oneway is maar één lane. Maar dat is een kwestie van afspreken wat betekent wat. En die afspraken zijn nogal vaag en voor meerdere interpretaties vatbaar, zoals alles op OSM.
Het tag-info scherm werkte in de laatste versies van Firefox niet meer. Dankzij Hubert87 is dit opgelost door regel 46 in noordfiets.jss uit te schakelen:
Ik kwam erachter dat in de BTM, als je het menu “route tags” gebruikt de wegen met “bicycle=use_sidepath” niet voorkomen in de overlay “non cycleable ways” en wel zichtbaar zijn in de overlay “cycleable ways”. Het gaat wel goed in het menu “cycleway tags”. Zou je dat kunnen aanpassen?
Hij lijkt geen rekening te houden met de tags van de vorm “moped:forward:yes”. Kun je dat toevoegen?
Is het misschien mogelijk om Omniscale als basiskaart toe te voegen? Die refreshen supersnel, op meerdere zoomlevels (als in live). Kwam ik achter toen ik routing testte via GraphHopper, het is hun standaard basiskaart.
Je bedoelt bromfietspaden waar alleen bromfietsers eenrichting op mogen en fietsers beide richtingen? Kan je een voorbeeld geven? Anders is oneway=yes, moped=yes toch voldoende?
Wil ik best toevoegen als layer, kan je mij de code geven voor die omniscale kaart?
Nog een verzoekje. Sinds Mapillary zijn site heeft aangepast werkt de link naar de juiste mapillary locatie niet meer. In mijn eigen webkaartjes heb ik het aangepast met de volgende code.
Een weg met “vehicle=no” (als gevolg van geslotenverklaring C1) wordt niet getoond bij overlay “non cycleable” / wordt getoond bij overlay “cycleable”.
Een weg met “surface=asphalt” wordt niet getoond met overlay “surface = paved”.
Idem voor “surface=paving_stones”, en wellicht ook andere surfaces die normaal als “verhard” worden beschouwd.
Ik weet ook niet helemaal precies wat je onder “semi-paved” vat.