Word er nu met de nieuwe service=busway vanuit gegaan dat altijd beide borden er hangen? Neem bijvoorbeeld https://www.openstreetmap.org/way/475472200 , in theorie mag je daar ook lopen (als dat voetpad er niet naast had gelegen). Die nuance wordt genegeerd omdat het anders te complex wordt? Vind ik op zich prima, maar wellicht handig om goed te documenteren voor consistentie.
highway=busway is standaard niet toegankelijk voor voetgangers. Als je er wel mag lopen, moet je expliciet foot=yes toevoegen.
Bij het nieuwere bord F13 is het ook verboden voor voetgangers op de busbaan (als er een stoep aanwezig is, mag je wel op de stoep lopen, want de stoep is geen onderdeel van de rijbaan).
Lijkt me een logische toevoeging in het rijtje footway/cycleway/bridleway/motorway gebaseerd op het primair gebruik. Zal het hier in de buurt eens nalopen.
Vandaag werd ik na een edit van mij in het buitenland gewezen op enkele uitzonderingen die op “highway=busway” van toepassing zijn. Het gaat mij daarbij specifiek om:
Deze uitzondering is te vinden op de Wiki, Similar infrastructure, Bus-only motorway links.
De busbanen die leiden van/naar bijvoorbeeld Amsterdam Centraal en Nijmegen Centraal zijn getagd als “highway=busway” terwijl bij Arnhem Centraal en Utrecht centraal gebruik wordt gemaakt van de “highway=service” tagging.
Voordat ik zaken ga corrigeren (zoals het in de wiki gedocumenteerd staat) wil ik eerst hier even een balletje opgooien om te kijken hoe de Nederlandse community tegen deze uitzondering/regel aankijkt.
Rondom Utrecht Centraal zijn een aantal wegen die opnieuw geclassificeerd kunnen worden als highway=busway. Is het oké om dit hier en op andere stations zo te taggen, of zien mensen liever iets anders of de huidige situatie met access=no, psv/bus=yes/designated en highway=service? Zie bijvoorbeeld 691727676, 7057576, 632861792.
(Ik vraag het van tevoren omdat Utrecht Centraal nogal een drukke locatie is en ik hier geen problemen wil creëren.)
We gaan het zien. De PR is aangepast nu met de nieuwste eisen verzoeken (zie bovenste post). Met name het meenemen van highway=bus_guideway, omdat deze in het echt steeds dichter naar highway=busway kruipt. Het gaat niet goed genoeg zijn, want iedereen wil wat anders, maar misschien dat Joseph aanvoelt hoe dit overkomt op de gemeenschap en dat we met een paar normale wijzigingsverzoeken een werkbare versie kunnen maken. (En daarnaast: als mijn aanpak niet geschikt is houdt niemand de maintainers tegen om zelf een oplossingsrichting uit te werken; de maintainer met de grootste mond heeft al bijna twee jaar geen enkele commit meer gedaan.)
Klopt OsmAnd heeft hem, OpenMapTiles (ook gebruikt voor knooppuntnet.nl) heeft er ook ondersteuning voor (maar de style die knooppuntnet.nl gebruikt heeft die nog niet zo te zien). OrganicMaps nog niet, maar die zie ik ook geen PR weigeren hiervoor.
Aangezien ik een enthousiast gebruiker ben van Locus (Classic) met daarin de maandelijkse OpenAndroMaps vector kaarten uit OSM heb ik een feature request gedaan op busway voor de theme’s op de vector kaarten: die is meteen geaccepteerd en doorgevoerd. Ik ga het zien op de NL kaart op het begin van de volgende maand: https://www.openandromaps.org/en/oam-forums/topic/new-tag-busway
Om ook rekening te houden met de z-volgorde van de wegen (waarbij wegtypes hoger in de hiërarchie boven anderen getekend worden wanneer ze overlappen) moet de database opnieuw ingeladen worden. Dat is een actie die eens in de paar jaar gedaan wordt. Doe je dat niet, dan heb je soms dan een raar stukje overlap waarbij een stukje busway net bij de splitsing boven een snelweg ligt of zo. Aangezien dit alsnog vele malen beter is dan helemaal niets renderen, is dat niet een argument om highway=busway uit te stellen, en het is ook nog eens iets wat gewoon geregeld kan worden.
Ik ga er niet van uit dat mijn PR geaccepteerd wordt. Na een paar dagen (of weken) stilte volgt er straks een reeks aan non-argumenten waarom mijn oplossing niet goed is, maar met een alternatief komen ze ook dan niet.
Heel misschien valt het mee en reageert Joseph op een normale manier („Oh ja, dit kan wel werken. Zou de tint iets meer naar het blauw kunnen?”) maar het zou me verbazen. Of gewoon: „Tja, het is nog niet perfect, maar laten we het eerst hier eens mee proberen en dan kijken of we met feedback van de gemeenschap het nog beter kunnen maken.” Maar nee, bij features waar de heren maintainers niet achter staan wordt de lat zo hoog gelegd dat je er eigenlijk niet aan kan voldoen. Ik ben er nog niet over uit of dat gewoon misplaatst en naïef perfectionisme is, angst om iets kapot te maken, of kwaadwillende opzet.
Niet alle maintainers zijn zo, maar Mateusz heeft zich onlangs teruggetrokken als maintainer (je merkt in zijn toelichting ook dat de sfeer onder de maintainers daar een rol in speelt), en Daniel is nu eigenlijk de enige die daadwerkelijk positief reageert op bijdragen op GitHub.
De frustratie over Carto komt trouwens steeds meer naar boven in de gemeenschap. Deze open brief is daar een mooi voorbeeld van. (Ik heb daar zelf ook op gereageerd, en onderschrijf de strekking volledig.)
Het liefst zou ik helemaal niets om Carto geven (het kost me veel energie om daar vriendelijk en constructief te blijven), maar zolang het de standaardrenderer van openstreetmap.org is heeft het een enorme invloed op het project en de perceptie van gebruikers. Beginnende mappers die met ID werken zijn afhankelijk van Carto voor de feedback op hun werk (en zelfs bij JOSM vormt dat een belangrijke feedbacklus), en voor veel gebruikers is openstreetmap.org het enige wat ze kennen. Ik vind de huidige situatie een van de grootste bedreigingen voor het project.
Het is triest.
Ik zit er zelf niet in, maar wat ik jammer vind is dat de discussie niet rechtlijnig gevoerd wordt. Als je als maintainer zegt “Dit gaan we niet doen”, soit.
Maar nu is het “We moeten wachten tot technical feature x, en dat duurt nog een jaar” en twee jaar later wordt x eindelijk mogelijk en dan is het “het wordt nog niet zoveel gebruikt” (wat ook maar relatief is) terwijl de hoofdreden dat velen schroom hebben om een bepaalde tag te gebruiken is dat het niet op OSM-carto gerenderd wordt.
Inmiddels is het 2024 en wordt het nog steeds niet gerenderd op OSM. Ik was mij niet bewust van deze discussie totdat mijn bewerkingen om een aantal wegen weer op de oude manier te taggen teruggedraaid werden.
Is het acceptabel dat door een “nieuwe” tag die blijkbaar niet door de Carto-community geadopteerd wordt (en het ernaar uit ziet dat dat voorlopig ook niet gebeurt), er blijvende gaten vallen in de kaarten van OSM? Ik heb geen idee van andere toepassingen van de OSM-data, maar in mijn ogen is de kaart van OSM zelf de hoofdtoepassing.
Als ik het goed begrijp wordt deze tag ook voornamelijk in Nederland gebruikt en is het dus niet wereldwijd overgenomen. Aangezien dit maar een heel klein percentage van alle wegen is, voorzie ik dat de prioriteit van Carto om dit aan te pakken laag blijft. Is het niet beter om de de facto standaard van de rest van de wereld weer te gaan volgen?
Inmiddels is het 2024 en wordt het nog steeds niet gerenderd op OSM.
De tag highway=busway wordt gerenderd op de drie van de zes kaartlagen die worden aangeboden op osm.org (Tracetracks, Humanitarian en CycleOSM). Van de overige drie worden de ‘Fietskaart’ en ‘Transportkaart’ al jaren niet meer aangepast aan ontwikkelingen binnen OSM en is OSM-carto de enige die daadwerkelijk weigert de tag te renderen.
Deze kaartlagen zijn overig slechts voorbeelden van wat je met OSM-data kan doen. Het is niet dé OSM-kaart en niet de hoofdtoepassing. Veelgebruikte apps als OSMAnd en Organic Maps renderen busbanen ook gewoon.
Is het acceptabel dat door een “nieuwe” tag die blijkbaar niet door de Carto-community geadopteerd wordt (en het ernaar uit ziet dat dat voorlopig ook niet gebeurt), er blijvende gaten vallen in de kaarten van OSM? Ik heb geen idee van andere toepassingen van de OSM-data, maar in mijn ogen is de kaart van OSM zelf de hoofdtoepassing.
Ja. De Carto-community bestaat niet. Het is een kaart die slechts door een handvol maintainers wordt bijgehouden. De dwarsligger voor highway=busway is ook maar één persoon. En er zijn door veel mensen kant-en-klare pull requests aangedragen.
Er is wel een OSM-community welke de tag al drie jaar geleden heeft goedgekeurd. De tag behoort zelfs tot de minderheid van tags die het formele proposal-proces hebben doorlopen.
Dan is mijn vraag: hoezo zijn gaten in de kaart acceptabel, en is iedereen het daarmee eens? En als Carto niet zo actief is, moet er dan niet ergens een discussie gestart worden over wat de nieuwe standaard kaart van OSM moet worden? Want als ik op Openstreetmap.org kom dan is dat wel dé eerste kaart die ik zie. En als dit met iedere nieuwe tag blijft gebeuren, dat wordt de kaart er niet mooier op.
Wat zijn overigens de voordelen van de nieuwe tag t.o.v. de oude tags, behalve dat het scheelt in aantal tags?
Veel mappers vinden de gaten in de kaart natuurlijk vervelend, maar OSM Carto is niet van de OSM-community, maar van de mainainers van OSM Carto. Het staat ook op iemands persoonlijke Github.
De vraag of OSM Carto wel de standaardkaart moet zijn, is vaker opgerezen. Het zorgt namelijk voor een onofficieel veto voor een zeer klein aantal mensen. De discussie die we nu hebben, komt ook door de persoonlijke voorkeur van één persoon.
De oplossing zou echter zijn om een eigen kaartlaag te maken, wat veel meer tijd kost dan je vooraf zou denken. Sinds Tracestrack Topo vorig jaar is toegevoegd, is er eindelijk een concurrerende kaartlaag die beter is in nieuwe tags ondersteunen.
Voordelen van de busway-tag zijn:
Overzichtelijkere tagging: busbaan = busway, net als fietspad = cycleway en voetpad = footway. Zo zijn geen ingewikkelde combinaties van tags nodig, waarbij vaak ook nog lastig te bepalen was of bus=designated of psv=designated de juiste tag was.
Het is een eenduidige tag, die rendering mogelijk maakt. Zie bijvoorbeeld de laag Tracestrack Topo. Dit is niet mogelijk met highway=service i.c.m. wisselende access-tags.
Het is de vraag of een busbaan eigenlijk wel een highway=service is. Service-wegen zijn vooral bedoeld voor toegangswegen en opritten, die van een duidelijkere lagere klasse zijn dan de rest van het wegennet.
Toch frappant dat ervoor gekozen is om voor zo’n groot open source-project met zo’n grote community een kaartlaag als standaard te gebruiken met een enkele maintainer, die nog onwelwillend is ook.
Waar zou ik de discussie over het gebruik van Tracestrack Topo als alternatief kunnen volgen? Ik weet niet hoe ver dat in de pipeline zit, maar desnoods zou er wellicht geopperd kunnen worden om een fork van Carto onder te brengen bij OpenStreetMap on GitHub · GitHub.
