Hey Ali

I check with Mapillary and I have to say, your changes are incorrect.

I rework and fixed the area in osm.org/changeset/87457020 but, please, only add details with valid sources and care about your changes and the community.

Cheers skyper

Oh, da habe ich schon anderes gelesen. Das hast Du schon korrekt formuliert.

Wenn, dann habe ich mich hier auf "fremden" Terrain bewegt, in einer Gegend, wo ich sonst nicht mappe und auch keine direkten Informationen habe.

Wie geschrieben, ich bin mir nicht sicher, ob z.B. mofa=yes fehlt, aber vorher mit dem "Radweg" war das nicht anders.

Mm brauchen wir einen eigenen Tag, entweder für die gemischt genutzten Weg oder für die Pfade. Aber ob sich da irgendeine Person mal findet, die genug Energie aufbringt dieses Problem zu lösen, steht in den Sternen.

Grüße skyper

Hallo Roger

Ich bin mir überhaupt nicht sicher und habe nur von cycleway -> path umgebaut. Bin mir nicht sicher ob bei path grundsätzlich alle "Vehikel" ausgeschlossen sind. Wenn ich an die neuen E-Scooter denke, bin ich mir bei motor_vehicle schon unsicher und bicycle ist ja explizit erlaubt.

Von daher, checke bitte selber nach und verbesser falls nötig. Danke.

Grüße skyper

Kann ich schon, allerdings was ist jetzt der richtig Bodenbelag und Du wirst über kurz oder lang mit Multipolygonen umzugehen lernen müssen.

So, habe ein bisserl verbessert: osm.org/changeset/87317512.

Hey okilimu

Kannst Du Dir bitte nochmal die Bahnsteige in Titisee anschauen. Im Moment ist das Routing zu Bahnsteig 2 äußerst bescheiden. Da fehlen noch Verbindungen. Auch bin ich mir sicher, dass die Bahnsteige 1 und 4 nicht so komplett getrennt sind.

Woher hast Du die detaillierte Information unter dem Dach her?

Grüße skyper

Hallo EinEngener

Bei osm.org/way/194001561 bzw. osm.org/relation/4053755 ist Dir wohl ein Fehler unterlaufen. Tags gehören zur Relation und nicht an die Mitglieder.

Kannst Du Dir das bitte nochmal anschauen und den Konflikt im "surface" aufklären (asphaltiert <-> Bodenkacheln)?

Danke und Grüße
skyper

Ich habe das Konstrukt verworfen und bin bei mehreren Werten für "interval" bzw "interval:conditional" gelandet, auch nicht gerade schön, aber deutlich kürzer:
"(00:30;00:55;01:30;01:00;02:12;04:26) @ (07:00-17:33; PH,SH, Dec 24,Dec 31 off); (00:30;00:55;01:30;01:00;02:00;04:38) @ (SH 07:00-17:33; PH, Dec 24,Dec 31 off)"

Ciao skyper

Hi jeroenrozema74

Does this service highway really exist (osm.org/way/807791492)? Did not find any evidence on any imagery. Where do you have the information from? As you did not add any source tag nor any comment to your changeset, it is hard to verify your changes.

Cheers skyper

> das Interval-Proposal war ein Kompromiss, weil das komplexe Abfahrtszeiten-Proposal krachend gescheitert ist (selten so eine Abstimmung mit so vielen Gegenstimmen gesehen). osm.wiki/Proposed_features/Public_transport_schedules/Departures

Warum steht davon nichts auf osm.wiki/Key:interval ?

Danke für den Link.
Grüße skyper

Na ja, die Meinungen gehen da doch sehr auseinander und OSM entwickelt sich auch weiter.

Wie geschrieben, ich bin am ausprobieren. Leider habe ich bisher keine Software gefunden, die GTFS IDs oder Links auswertet, geschweige denn eine Dokumentation darüber. Viel mehr versuche ich gerade Information ins wiki zu stellen und PTNA weiter voran zu bringen.

Im Wiki fehlen mir z.B. noch Beschreibungen für Fälle mit wenigen zeitlich weit auseinanderliegenden Fahrzeiten bzw welche mit überlappenden Zeiten einzelner Fahrten. Im ersten Fall reichen wohl Zeitsequenzen bei "opening_hours" und das weglassen von "interval", beim zweiten Fall wird es interessanter.

Hey,
ich bin gerade ein bisschen am experimentieren, was geht und was nicht, und wie ich die 255-Zeichengrenze umschiffe.

Diese Linie wollte ich mir nachher eh nochmal anschauen. Ich denke am einfachsten wird es in diesen Fällen, wenn "interval" und "duration" als Sequenze mit mehreren Werten, getrennt durch Semikolon, verwendet wird.

Die Links zum GTFS sind ja vorhanden, und irgendwie und -wo muss halt mal angefangen werden, sonst kommen wir nie dazu, dass auch komplizierte Situation eingetragen und ausgewertet werden.

Hallo Yoschilein

Willkommen bei OSM.

Beim Belchenbus hast Du public_transport:version=2 eingetragen. Richtig ist aber "1", da bei 2 jede Fahrtrichtung und auch jede Variante in eine eigene Relation gehört und diese wiederum in eine "route_master".

Habe es verbessert.

Grüße skyper

Hey Mat69,
ich habe mir die Situation angeschaut und jetzt doch "lanes:both_ways=1" verwendet. Das funktioniert bei gesperrten Flächen zwischen den beiden Gegenrichtungen und hat den Vorteil, dass ich es bei "lanes" weglassen kann.
Siehe osm.org/changeset/86626974

Grüße skyper

I had a closer look at route 5 and six and made little changes: osm.org/changeset/86049452

I noticed little problems:

* Most platforms and all stops do not have a name, which makes it hard to work with.
* Platforms and stops are usually pairs, so osm.org/node/3044774952 and osm.org/node/3044774953 seem to be too far away from each other.
* The starting stop for route 6 going north is missing.

I am not sure how we can use the link you mentioned.

For more help, you might get into touch with osm.org/user/sanchi. It looks like an active and experienced user, speaking Spanish.

By the way, I deleted all the relations without member as they are useless.

Cheers skyper

You are right about the complexity and I, personally, never tried to edit a relation with iD.

You can contact a local user who did added the other relations and ask for help.

And/Or I can have a look at route 5 the next days but it is not easy to check/update from the couch. By chance, do you know if there are external sources allowed to use, like GTFS?

Hello rodrilafu

GerP did contact me.
Bus routes can get quite complex. As starting point, osm.wiki/ES:Buses, osm.wiki/ES:Relation:route and osm.wiki/ES:Relation:route_master.

What do you want to change on bus route 6?
So far it is present in the data base as "Public Transport version 2 (PTv2) with route_master (osm.org/relation/4010004) and one route per direction (osm.org/relation/3994553 and osm.org/relation/3996761).
What is wrong?

Greetings skyper

Or you could use rare type=node relation, see osm.wiki/Relations/Proposed/Node. But it is not supported by any software.

All these are PTv1, so far, and need an update. I added S12 last week, S2 Denzlingen <> Elzach is under construction and trains to France were not running for some weeks (Covid-19).

cu skyper

Salli jeroenrozema74

Thanks for the link, I missed that and thought All-in-One is dead.

The S3 was introduced last autumn among the other S-Bahn but are missing so far, in OSM. ÖPNV needs a lot of work, see https://ptna.openstreetmap.de/results/DE/BW/DE-BW-RVF-Analysis.html.
Not that easy, as Covid-19 changes routes and departure times frequently and some lines are not running at all in these days.

Did not find any information what the special layer includes and what tags are supported.
Hope that the line will reappear but note that the name "Münstertalbahn" is not present as "name" value atm but only in "description". Are other PTv2 relations included? Have a look at the trams and buses in Freiburg, they are all PTv2.

Please, let me now if you have problems and need help, like e.g. contacting the owner of the page.

Wish you the best.