This leaves it a bit unclear what exactly should be supported here. A relation of relations of linear features is often a relation of either type superroute or route_master (see also T312572). It may be desirable to treat these two the same way in our import mapping. Fetching member relation geometries for other types of relations is probably less likely desirable.

In this context Pacific Crest Trail relation appears to be somewhat odd example in its current state. It wasn't a relation of relations until a few years ago. Then it was turned into one but its relation type route wasn't changed. I assume this isn't intentional, and similar to Kungsleden example it should also get type superroute?

That looks like the same issue indeed. I would guess so, if you phrase it like that, the issue/ticket should be "Display superroutes in Kartographer". Does this mean that changing the type alone would fix the problem here? I.e., does it already work with superroutes?

Interestingly, it does seem to work for the Appalachian Trail, which is also a superroute: https://en.wikivoyage.org/wiki/Appalachian_Trail

It does not work for Nordkalottleden, Kungsleden, the Pacific Crest Trail, or the Continental Divide Trail.

Interestingly, it does seem to work for the Appalachian Trail, which is also a superroute

This is because its member relations of supported type route, like relation/18326383, all carry wikidata key with the same value. Which as a workaround is probably suboptimal as OSM object and Wikidata item aren't exactly matching, member relations are for route sections while associated Wikidata item is for entire route.

That would also explain why the Kungsleden winter trail also showed up. It was tagged with the wikidata key as well. I've created a superroute for both the winter and summer trail in OSM, as well as updated the Kungsleden summer trail with the relevant stages.

Some additional information: several trails also have points of interest included in the trail. Would it be a good plan to switch the data format to KML? This could include both the sections as well as the points of interest.

Nordlandsruta is now finished as well: https://en.wikivoyage.org/wiki/Nordlandsruta

This simple python script did the trick for me, it would be very helpful for readers of wikivoyage to be able to get a KML (and view it!). Most hikes start with downloading the trail for offline use.

Kungsleden (https://en.wikivoyage.org/wiki/Kungsleden):

import requests

# Overpass API endpoint
url = "http://overpass-api.de/api/interpreter"

# Overpass QL query
query = """
[out:xml][timeout:25];
relation(1657661);
(._; >>;);
out body;
"""

# Send request
response = requests.post(url, data={'data': query})

# Save the raw XML
with open("superroute.osm", "wb") as f:
    f.write(response.content)

print("OSM XML saved as superroute.osm")

How about storing the POI and sections in wikidata as arrays, so articles can be created by using the POI from there?

If there are problems with that, how about only adding the nodes to wikidata that have a wikidata reference? That would incentivise adding wikidata references to OSM as well.

Hey,

I would be willing to work on this, but I would need some guidance around where to start.

At the moment, all of the most popular trails have wikivoyage guides. All of the most popular trails are fully mapped in OSM. Since most (90 % of hikers looking for trail guides) hike these trails, I believe we can serve > 90% of hikers with the guides and map data we currently have, if we find a good way to visualise the data in OSM, and allow people to download the data before setting off on a hike.

The key opportunity here is in how we visualize and distribute this existing information. If we create a system that allows users to easily view OSM trail data and download it (perhaps as KML files) before heading out, we can dramatically increase the utility of these open-source resources.

I think this could be incredibly valuable. There are tons of paid hiking guides out there that offer essentially the same data. If we can make Wikivoyage + OSM slightly more user friendly, we can help most hikers get what they need for free, using open and community-driven tools.

At the moment POI's that are wikidata references don't work when you export to gpx, so I would guess new functionality would need to be made for that as well. Those combined with the sections from OSM would create really good hiking guides.

In T388303#10617497, @Pikne wrote:

This leaves it a bit unclear what exactly should be supported here. A relation of relations of linear features is often a relation of either type superroute or route_master (see also T312572). It may be desirable to treat these two the same way in our import mapping. Fetching member relation geometries for other types of relations is probably less likely desirable.

In this context Pacific Crest Trail relation appears to be somewhat odd example in its current state. It wasn't a relation of relations until a few years ago. Then it was turned into one but its relation type route wasn't changed. I assume this isn't intentional, and similar to Kungsleden example it should also get type superroute?

superroute is not universally used within OSM because it stems from a bug in one of the editing applications. The older and more common convention is to simply nest multiple type=route relations inside another type=route relation. I suspect the geoline service would benefit from supporting such “route superrelations” in general, regardless of the type=* tag.

In T388303#10809333, @mxn wrote:

superroute is not universally used within OSM because it stems from a bug in one of the editing applications. The older and more common convention is to simply nest multiple type=route relations inside another type=route relation. I suspect the geoline service would benefit from supporting such “route superrelations” in general, regardless of the type=* tag.

I see, then it may have been intentional as well to keep type=route for Pacific Crest Trail example. My impression was that type=route is mostly outdated for relations of relations as in my region these days almost always a different relation type is used for these relations. Your "stems from a bug" assessment sounds odd, though. Relation type superroute after all existed and was used long before this change in JOSM codebase was proposed.

I think it would be problematic to treat all relations regardless of the type=* tag the same in regard to member relations. For instance, geoline currently also returns boundary relations as linestrings. These relations sometimes contain member relations of subarea role. If geometries for that kind of member relations would be combined into a single geometry then the result would be pretty much useless. Or, some people have included tributary waterway relations in relations of other waterways, so that individual OSM object (relation) for some individual waterways basically no longer exists.

I guess the general problem with nested relations is that there isn't a clear criterium on why one should nest relations, and often this is done just because relations are treated as categories. This way it's also extra difficult for consumers to make any good use of nested relations. In this regard superroute and route_master relation types appear to be attempts to start with a clean sheet and use a more simple data structure for more clear-cut purposes, so that it was potentially more useful for consumers (including the geoline service here).

I'm not entirely sure if imposm even allows us to build linestrings from nested relations. If it does then possibly we should do it for three relations types then, also for type=route in addition to type=superroute and type=route_master. Unless perhaps too many overlapping or in other ways peculiar geometries would result from this.

In T388303#10757822, @Jpolvto wrote:

Some additional information: several trails also have points of interest included in the trail. Would it be a good plan to switch the data format to KML? This could include both the sections as well as the points of interest.

This sounds like a different matter, and may warrant separate (more refined) feature request. But you might want to discuss this first on Wikivoyage with users who have set up its current maps related scripts and templates. Maybe some onwiki script or external or semi-external Toolforge tool would be sufficient for data export/format conversion? Wikimedia Maps uses GeoJSON data format, and it probably isn't likely that it's going to change.

Thanks a lot for the response!

This sounds like a different matter, and may warrant separate (more refined) feature request. But you might want to discuss this first on Wikivoyage with users who have set up its current maps related scripts and templates. Maybe some onwiki script or external or semi-external Toolforge tool would be sufficient for data export/format conversion? Wikimedia Maps uses GeoJSON data format, and it probably isn't likely that it's going to change.

Fair enough, let's keep this one scoped to the minimum of what we would require to make hiking guides (a lot!) better.

In T388303#10811731, @Pikne wrote:

I see, then it may have been intentional as well to keep type=route for Pacific Crest Trail example. My impression was that type=route is mostly outdated for relations of relations as in my region these days almost always a different relation type is used for these relations. Your "stems from a bug" assessment sounds odd, though. Relation type superroute after all existed and was used long before this change in JOSM codebase was proposed.

route superrelations, superroute relations, and route_master relations are all common in different contexts and regions. The strongly held regional differences have never really been reconciled, since superrelations of any kind are quite obscure and hidden to most mappers. I should’ve worded my assessment slightly differently: if not for a misunderstanding in the JOSM bug tracker, there probably wouldn’t be as much usage of superroute today and probably more usage of route_master. In any event, there are at least three common tagging schemes of equal value to Wikipedia for grouping route relations.

I think it would be problematic to treat all relations regardless of the type=* tag the same in regard to member relations. For instance, geoline currently also returns boundary relations as linestrings. These relations sometimes contain member relations of subarea role. If geometries for that kind of member relations would be combined into a single geometry then the result would be pretty much useless. Or, some people have included tributary waterway relations in relations of other waterways, so that individual OSM object (relation) for some individual waterways basically no longer exists.

Yes, I was only referring to the case of nesting route relations inside route/superroute/route_master relations. And perhaps chronology relations if OpenHistoricalMap support is ever added. But subarea members should definitely be ignored for the purpose of returning the parent relation’s geometry. Otherwise all kinds of weird edge cases can arise. Just as the geoshape/geoline service maintains a hard-coded list of relation types to support, it would need to maintain a hard-coded list of roles to omit as well.

I'm not entirely sure if imposm even allows us to build linestrings from nested relations. If it does then possibly we should do it for three relations types then, also for type=route in addition to type=superroute and type=route_master. Unless perhaps too many overlapping or in other ways peculiar geometries would result from this.

Good question. Besides this ticket, I’d be especially interested in that support because OHM uses imposm to generate its official vector tiles, and OHM relies very heavily on nested chronology and other relations to abstract certain attributes.