In dem er den Nutzer fragt, ob er A->B will oder B->A. Der Rest geht dann mit oneway/roundabout-tags und Wegrichtung.
Genau so könnte das Ausgabeprogramm vor einer Verzweigung fragen, ob man Variante 1 oder 2 haben will und ebenso vor einer excursion, ob man den Abstecher machen will. Und siehe da, man erhält eine einzige durchgehende Route.
BTW: MIt track bezeichnet man eine aufgezeichnete Folge von trackpoints, die daher Zeiten enthalten (können).
Routen sind für die Planung und Navigation vorgesehen und enthalten keine Zeiten. Die sind eigentlich das Thema hier.
Doch. Alle Informationen können erfasst worden, für diskontinue so wie kontinue Routen, Alternativen, Fahrrichtungen, und mehr.
Ein kontinue Superroute von 36 Segmente kann als ein einziges Track in gpx-Format exportiert worden.
Ich sehe Route-Relationen in OSM als gespeicherte vorgefertigte Routen. Man braucht im prinzip kein Router mehr, nur Navigation. Schade das wenige Navigationsapps das so direkt benutzen. Immer diese Umwege mit gpx-Dateien…
Jetzt nur noch jemanden finden, der das programmieren kann…
I think you don’t get the point here: The export of the Innradweg is resulting in a gpx-track continaing 36 track-segments. If you simply put them together a they are, you get what I was showing above. You can discuss whether the long connections should be existing or not. But in both cases, the result doesn’t help the enduser. The required result is one track, from start to end in order to get information about the length and so on. That’s not possible how the Innradweg-relation (and many others) is set up at the moment.
I agree with you that the problem would be solvable with our data-model.
All the members of a super-ralation needs to be a part of the single line and completly cover a section and need to be in corrct order. An point where the alternative section is starting, you need to have as well a split in the “main” section. Under these conditions the exporter can provide a usable track.
At the moment the sectioning is not done like this, but more based on geographical areas. For instance: something like “Innradweg in Bayern”
OSM does not know that. It justs records the information about what people mark as the Innradweg. The route relation is not stored for any particular output. That is the terrain of applications.
sind sie aber nicht, sie sind Stecken die vorhandene Wege nutzen, aber es gibt keinerlei Garantie dass sie linear sind, und daher kann man damit auch nicht unbedingt so navigieren wie mit der Strecke die ein Router ausgibt.
I agree with you. Though in order to make such an output possible, the way we split route-relations would need to adopt. A bit like you Knooppunkt is working. Whereever a route is split into more than one possibility, would be a Knooppunkt. The section inbetween the Knooppunkt you would add into one route-realtion and all those sections you would add to the super-route of the Innradweg.
In a rather simple approach, an exporter could return a single track combining the shortest possiblity. 
I think the Innradweg is almost sectioned that way. The only thing missing is a relation containing one main route. If the alternatives are all equally important and no single main route can be assigned, then you could say a Node Network situation is present.
Node networks can handle Nodes with names, in OSM. Knooppuntnet has a Planner for routing over node networks, which allows you to generate a gpx for exactly your chosen route (called itinerary, in Knooppuntnet).
Waymarked Trails displays node networks different from local/regional/national/international routes, and all the sections are separate, so you can’t get a gpx of your planned route through the node network from Waymarkedtrails.
in Italien haben die Wanderrouten oft Zeitangaben
https://taginfo.openstreetmap.org/keys/duration#combinations
Yes, almost. The only thing which need to change is to do the splitting a bit more systematic.
In a lot of cases there is nothing like this. The route on the left or the right side of the Inn would be equally “main”. Anyway, in the concept, each of the segments, you check first node and last node. All segments having the same nodes, are exchangeable segments. You could give them a role like main or alternative to classify them. The exporter could pick one continous route out of those segments. Either by asking the user or picking somehow automatic (shortest, first in order, longest, prefer main,…)
Automatic would often produce a route that the user doesn’t want. The export function could use one driving direction and main as defaults, leaving it up to the user to specify reverse direction / different role. Reverse would often be needed for bicycle routes.
It still would be hard to differentiate between different alternatives with the same role. The only way would then be to have the end user pick specific sections.
From what I know of developments in the hiking world: the need is there, the tools lag behind.
Another thing missing at the user end: tools to cut/export a specified section from a larger route, for trip planning. Where the cut-off points would not have to coincide with relation start/end nodes.
ich schlage vor, den Titel zu ändern in “Auswahl einer Strecke aus Relationen mit nicht-linearen routes” oder ähnlich, weil die Daten ja nicht “unbrauchbar” sind sondern die Frage ist, wie man sie für eine bestimmte Anwendung brauchbar bekommen kann.
Eigentlich sind die Zeitangaben zu den Routingpoints Uhrzeiten (inkl. Zeitzone), aber für voraussichtlich gebrauchte Zeiten kann man das auch zweckentfremden. Das habe ich auch schon gesehen.
Im Prinzip könnte man einen zurückgelegten Track auch auf einem Portal zum Nachverfolgen einstellen, ist aber aus mehreren Gründen unzweckmäßig…
The most easy way would be to just yank the alternatives form the superroute, at least in Tyrol that is easy.
The Innradweg is managed from a .com domain, while the alternatives are managed by the local administration. The locals do not have much of a say on the main route, yet incidentally, they recently moved one of the bicycle counters from the main route to an alternative route.
These local alternatives, are they actually ausgeschildert wie der Innradweg?
Die Alternativrouten R3A, R3B und R3C sind genauso ausgeschildert wie die Hauptroute R3.
Der Innradweg ist übrigens in Tirol gar nicht augeschildert, der existiert nur als Homepage 
Die Betreiber haben einfach den R3 “übernommen”.
Ich nehm die Alternativen aus der Superrelation heraus, die gehören dort nicht hinein.
Ich erstelle dann Teilrelationen für alle ausgeschilderten Routen. Dann erstelle ich eine Superroute-Relation für die Hauptroute, die aus mehreren Abschnitten besteht, die zusammen eine durchgehende Route sind. Dann mache ich eine weitere Superroute, mit der Hauptroute und allen kleineren und größeren Alternativen, mit den entsprechenden Rollen.
Zur Problematik der Erstellung von GPX-Tracks aus OSM-Routen ist ja genug geschrieben. Als einstweilige schnelle Lösung kann vielleicht die Bearbeitung der heruntergeladenen GPX-Datei mittels einer XSL-Transformation mit dem folgenden Stylesheet darstellen. Damit werden die Segmente der ursprüglichen Tracks in eigenständige Tracks umgewandelt, die mit x-beliebigen Navigationstools, die GPX können, verwendet werden können müssten.
Für die Transformation verwende ich das Plugin „XML Tools“ in Notepad++. Eine weitere Möglichkeit sind online-Transformationstools wie z.B. XSLT Tester (Free online XSLT 2.0/3.0 Test Utility
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:gpx="http://www.topografix.com/GPX/1/1">
<xsl:output
method="xml"
version="1.0"
encoding="UTF-8"
indent="yes"/>
<xsl:template match="/">
<gpx xmlns="http://www.topografix.com/GPX/1/1"
creator="waymarkedtrails.org"
version="1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<xsl:apply-templates/>
</gpx>
</xsl:template>
<xsl:template match="/gpx:gpx">
<xsl:copy-of select="gpx:metadata"/>
<xsl:for-each select="gpx:trk">
<xsl:variable name="Trackname"><xsl:value-of select="./gpx:name"/></xsl:variable>
<xsl:for-each select="gpx:trkseg">
<xsl:element name="trk" xmlns="http://www.topografix.com/GPX/1/1">
<xsl:element name="name">
<xsl:value-of select="$Trackname"/> Teil <xsl:number format="001"/>
</xsl:element>
<xsl:element name="trkseg">
<xsl:for-each select="gpx:trkpt">
<xsl:copy-of select="."/>
</xsl:for-each>
</xsl:element>
</xsl:element>
</xsl:for-each>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
1 Like