Er bleek al een issue voor te zijn en het is ook gedeeltelijk gefixt. Zie https://github.com/geofabrik/osmi_pubtrans3/issues/19. Mocht het niet opgepakt worden, zouden we kunnen kijken of één element een lege rol geven (bijv bij start of einde van de route) het probleem oplost. Al is de huidige tagging accurater met de werkelijkheid natuurlijk.

Kennelijk is de norm in Azië dat de 'hail_and_ride' voor gedeeltes van de route gelden (waardoor er ook altijd elementen zonder role overblijven). Wat mij betreft is dit een bug in de validator en is gebruik van de role hier wel terecht. Ik ga proberen een issue aan te maken bij de Geofabrik OSM inspector.

En de reden dat ik die role heb toegewezen is vanwege deze tekst op de website: "Wat vooral ook de buurtbus zo aantrekkelijk maakt, is het feit dat u ook "zo maar" onderweg langs de route de bus aan kan houden om op te stappen. U bent niet strikt aan een halte gebonden om met de bus mee te gaan."

Hi @Leo Slager, welke tool geeft foutmeldingen? Kreeg bij uploaden wel een JOSM melding dat er geen elementen met een lege rol zijn (zoals verwacht voor deze buslijn) en ook Osmose laat niets zien.

hail_and_ride als rol staat beschreven op osm.wiki/Relation:route#Members (vierde rij) en op osm.wiki/Buses#Adding_streets_to_the_relation

Check, dank voor je reactie. Ik kwam hierop vanwege meldingen van Osmose die het conflicterende tags vindt. Zelf denk ik dat amenity=parking eigenlijk landuse=highway al impliceert, dus niet op hetzelfde object gebruikt hoeven te worden. Beide zeggen niets over welk type voertuigen ervan gebruik kunnen maken (voor fiets gebruik je de specifiekere amenity=bicycle_parking, andere voertuigen zou je met tags kunnen specificeren) en ook niets over het type ondergrond, daarvoor zou je surface=* gebruiken. Alleen zegt amenity=parking natuurlijk iets over het gebruiksdoel van het oppervlak. De wiki lijkt te impliceren dat landuse=highway vooral bedoeld is voor wegengebieden, zoals de ondergrond van snelwegen met daarop de highways en toebehoren als vangrail e.d.

Zie jij dat ook zo of zie ik toch een reden over het hoofd waarom landuse=highway hier een toegevoegde betekenis heeft?

Beetje laat op het feestje, maar vanwaar de landuse=highway op de parkeervlakken?

Dank nog voor het snelle verwerken van de nieuwe 30-wegen! Ik wist het ook niet, maar kreeg nu een JOSM waarschuwing en had eerder al eens gezien dat Osmose hier ook over klaagde.

Hi @ligfietser, volgens mij had met deze changeset ook de source:maxspeed=NL:urban weggehaald moeten worden, aangezien NL:urban 50 km/u impliceert

Hi @Rubenke, wil je a.u.b. niet de wikidata-tags van straten verwijderen?

Top, ik heb ook een issue in Osmose ingeschoten om deze te accepteren als alternatief voor osm.wiki/Tag:direction=: https://github.com/osmose-qa/osmose-backend/issues/2795

Begrijp waar je vandaan komt. Denk dat het bij traffic_signals zo gedaan wordt omdat er ook andere tags op dezelfde node geplaatst worden. Hierdoor kan het ambigu zijn waar de direction tag betrekking op heeft. Bij give_way is er geen andere informatie (in ieder geval volgens de huidige norm)

Het is niet handig om zomaar af te wijken van de norm zoals gesteld op de wiki: highway=give_way. Software dat rekening houdt met de give_way tag kan niet opeens deze afwijking herkennen. Ik kwam op deze changeset omdat foutdetectiesoftware als Osmose deze nodes markeert vanwege een missende 'direction' tag. Als je het niet eens bent met een geldende norm kan dat eventueel via het forum of een proposal ter discussie gesteld worden, maar tot die tijd graag de geldende norm hanteren.

Hi Jeroen, op de give_way nodes heb je abusievelijk give_way:direction gebruikt i.p.v. osm.wiki/Tag:direction=.

Hi Rubenke, is er een reden dat je de Wikidata records van deze straten afgehaald hebt?

Hi Marc, nog niet aan die toegekomen idd. De way is momenteel niet getagd als brug (geen man_made=bridge). Omdat de 'brug' onder de gebouwen door zou lopen is het hier misschien makkelijker om het water als tunnel te taggen. Maar had nog niet bedacht hoe dit te gaan fixen.

Hi Jelv, dit betrof niet de website van de locatie maar een verzamelsite met de nodige (spam) advertenties. Ik heb deze aangepast.

Hi jj000, dat is vreemd, in deze changesets zou ik alleen wikidata tags moeten wijzigen. Heb je een voorbeeld waar ik die tag heb toegevoegd? Zie hem voor veel wegen in de binnenstad, maar die tags zaten daar al op. Thanks!

Dit ging niet zoals gehoopt en heb ik gerevert in changeset/173872927

Dank, was een snelle toevoeging onderweg. Zal erop letten (weet niet zeker of dit vanuit CoMaps direct kan)

Hi eggie, mogelijk was dit is een bug in CoMaps: ik probeerde Anytime te vervangen met COMMIT, maar zie dat de wijzigingen van COMMIT bij de adresnode zijn gekomen, terwijl de fitness node (2721731477) ongewijzigd is. Wat is nu de juiste weg, node/2721731477 verwijderen?