Wikivoyage talk:Hiking itinerary template Voyage Tips and guide

OpenStreetMap offers significantly more data that could enhance our trail guides, though it’s unclear what licensing or usage agreements would apply in these cases. Examples of useful data include:

• Distance (km) for each stage
• Elevation change and elevation profiles
• Estimated hiking time
• Complete trail mappings, including sub-relations

It’s worth noting that for most long-distance trails covered on Wikivoyage, the corresponding OpenStreetMap relations are already segmented in a way that aligns well with our guide format. The main exceptions are the Appalachian Trail and the GR 10, which are not divided into logical sections (for our purposes). Jpolvto (talk) 16:58, 4 May 2025 (UTC)Reply

The OSM licences are designed to make reuse possible, but I haven't checked their licensing terms in detail. Much of what we use are data collections rather than literature (maps are counted as such, at least in Finland), and data, I think, isn't protected in the USA. In EU there is the neighbouring database right protecting it, so we should respect the licensing terms (otherwise our EU contributors may have difficulties editing that aspect of our articles). Some uses require attribution; note the "OSM contributors" attribution included by default at the bottom of our dynamic maps. –LPfi (talk) 09:56, 5 May 2025 (UTC)Reply

I’ve been thinking about listings for a while. While they’re a staple of traditional printed hiking guides, using them on Wikivoyage sometimes feels a bit off. One issue is duplication. When trails share sections, like the Kungsleden and Nordkalottleden, the same listings end up appearing multiple times.

Another challenge is how listings are presented. Personally, I find that placing full listings at the end of paragraphs can create information overload. For example, if you look at the history of the Offa’s Dyke Path article, it looked incredibly cluttered to me at one point.

I noticed it’s also possible to reference listings like this: [[Stockholm archipelago#Grand Hotel Saltsjöbaden|Hotel Saltsjöbaden]], which seems like a cleaner approach. But that raises another question.

I’m unsure where certain types of listings actually belong. Refuges and mountain huts often feel more connected to the trail than to any specific town or region. Still, I hesitate to place them directly within the itinerary sections either. Bluecoordinationfine (talk) 09:47, 8 July 2025 (UTC)Reply

I don't think the listings cause "information overload" in Nordkalottleden or Södra Kungsleden. On the contrary, I think it is nice to see also that information when reading about a specific leg. Of course, it is possible to cause clutter, and when there is a lot to tell about a place, it is usually best to just have a summary there and link the rest. In those cases, the place is often relevant also outside the specific itinerary and can be described in its own article, such as Ritsem or Kvikkjokk. I see that you moved out listings from the French Way; I haven't looked closer. Whether moving away the listings make sense depends on the specific itinerary and the style of the article.

Avoiding having the same information duplicated across articles is a real concern. I'd recommend creating articles for hub locations, unless there is some existing article where the information fits. There was a discussion on overlapping sections somewhere, and I think I stated that covering such a section on a separate page would make sense in many cases. In the cases I have stumbled upon, there either has been some itinerary on (more or less) the specific section, there has been an article on just one of the overlapping trails, or the overlapping has been minor. There certainly are cases, where you'd need to create a page on the overlapping section with no rationale other than avoiding duplication. This mostly works if the trails that overlap are similar. If one is a hiking trail and the other a snowmobile route (sharing sights and huts), then referring readers to the other one doesn't feel right.

–LPfi (talk) 13:10, 10 July 2025 (UTC)Reply

Hey! Thanks a lot for the reply!

This is just a personal observation. It’s not that listings are objectively cluttered, but I do get a kind of information overload from listings with a large amount of details like phone numbers, email addresses, or capacity information. I think that's more of a general point on listings presentation though.

I mostly moved them from the GR 10 article! I think Scandinavian wilderness trails are quite different from trails in Central Europe. For the GR 10, you start and end every day in a village, adding the listings there makes a lot more sense. Not so much for the trails in Scandinavia that you mentioned.

This is also the reason I hesitate a bit there. It seems the listings belong more to the trail than to a town.

I don't have a real answer to the question on duplication here, but it's maybe good to mention that this is something to think about in the future. Bluecoordinationfine (talk) 17:21, 10 July 2025 (UTC)Reply

Here are a few possible improvements I’ve been thinking about. Some are relatively straightforward, while others may be more technical:

• Additional/custom vector icons: Useful for special locations or for distinguishing between lean-to shelters and enclosed cabins.

• Link map sections to text: Make sections of the map interactive. When a user clicks a trail segment on the map, the page automatically scrolls to the corresponding descriptive paragraph.

• Structure section data: Treat each trail segment as a data object with a unique Wikidata identifier (e.g., Q12345). Combining this further with geolines offers a full "marker-like" experience, where information on a trail section is displayed (from wikidata or otherwise) in combination with a visual representation. In this way, the geoline does not need to be added directly, you add the hiking section template, and the geoline shows up as well.

Example template: {{SectionInfo|wikidata=Q131542780}}

Displayed in text:

• Hemavan - Atoklimpen
• Distance: 41 km (calculated from OpenStreetMap, or taken from wikidata)
• Duration: 11:00 hr (calculated using Naismith's rule, or taken from wikidata)
• Ascent: 573 m (calculated using open-elevation.com, or taken from wikidata)

As well as an elevation chart for this trail section.

For trail sections which do not have a relevant relation in OSM, we could use a pathfinding algorithm. For most trails, we will not need this.

I would consider something like this very beneficial for structuring hiking itineraries, as well as maintaining that structure.

Bluecoordinationfine (talk) 09:55, 8 July 2025 (UTC)Reply

The more I think about this, the more I become convinced that this is a good idea. It feels like the missing part of the puzzle when it comes to itineraries. Mapshapes exist for covering an entire route, this would allow for structured data on sections of a route. The one thing I can't quite figure out is how to deal with trail termini. These would be essential for a pathfinding algorithm, but they would also be irreconcilable with listings. To see what I mean, consider that same stretch from Kungsleden.

You would need Adolfström and Sjnultje, as well as their coordinates. If we want this to be something that works both for users entering data, and for users using a section from wikidata, there would have to be an interface to enter these places as well. That would be fine with markers, although there are some issues displaying markers as part of a heading, but it would not work with listings. I.e.:

Marker 1 to Marker 2 - this would work fine

Listing 1 to Listing 2 - This would create an unreadable heading.

Something to think about. Bluecoordinationfine (talk) 15:35, 5 August 2025 (UTC)Reply

We try to have the fewest possible templates, because they are not easy for newcomers to understand or change. WhatamIdoing (talk) 17:10, 6 August 2025 (UTC)Reply

Hi WhatamIdoing,

Thanks for the feedback! I completely agree with the principle of keeping templates to a minimum, I've been considering that trade-off as well.

My thinking is that in this specific case, a new template would create a net simplification for editors in the long run. It would automate tedious tasks like calculating and formatting distance and time, while offering readers a major upgrade with interactive trail sections and consistent data.

I can't see a way to achieve this functionality with our current tools, but I'm very open to alternatives if you see a different path forward.

Edit: An added benefit is that this encourages new editors to see itineraries differently. Articles capture factual details about places, but itineraries serve another purpose. Many hiking itineraries on Wikivoyage are little more than lists of places along a trail.

That approach does not truly describe a journey. It omits details such as trail conditions, the character of the landscape, and the hiker’s perspective. This template can help guide new editors towards focusing on the journey, by giving them tools that nudge them in a different direction.Bluecoordinationfine (talk) 19:45, 6 August 2025 (UTC)Reply

I make a bunch of listings for out-and-back hiking trails, and have also had impulses to standardize some of the presentation. Here's my thoughts for your proposal:

• Link map sections to text: When a user clicks a trail segment on the map, the page automatically scrolls to the corresponding descriptive paragraph.

I think this would be useful for all kinds of listings! For example, when I click on a pinpoint icon for the restaurant nearest to my hotel, I would like a seamless way to jump to that listing's full text. You can kind of fake this by making the listing name an anchor link, i.e, {listing name=[Article#Restaurant_name]}, but that's not a good general practice. What if all pinpoint labels that don't already have a link got that anchor link by default?

• I think pathfinding algorithms are better run once and entered into the site statically. I'm not an expert on OSM, but I feel like that ecosystem must have much better tools for such problems that WV can more easily scrape from.
• Could inline trail stat tags, that could be used like Template:Convert, be a good middle ground for usability?

• Kungsleden Etapp 24: Adolfström - Sjnultje
• Distance: {routedistance|Q134269942}
• Duration: {routeduration|Q134269942|walk}
• Cumulative ascent: {routeelevation|Q134269942}

Gerode (talk) 19:41, 7 August 2025 (UTC)Reply

Hey! Thanks a lot for the response!

• I think this would be useful for all kinds of listings! For example, when I click on a pinpoint icon for the restaurant nearest to my hotel, I would like a seamless way to jump to that listing's full text. You can kind of fake this by making the listing name an anchor link, i.e, {listing name=[Article#Restaurant_name]}, but that's not a good general practice. What if all pinpoint labels that don't already have a link got that anchor link by default?

I didn't consider listings in the "Link map sections to text" proposal, that's an excellent point. Right now, when you click on a listing, you're taken to the right position on the map, but it doesn't work the other way around, which would be quite beneficial as well.

• I think pathfinding algorithms are better run once and entered into the site statically. I'm not an expert on OSM, but I feel like that ecosystem must have much better tools for such problems that WV can more easily scrape from.

That's a good point. I'm not an OSM expert either, I do wonder what happens when a route changes, or when elevation data gets improved? It would be nice to be able to incorporate these changes as well in some way.

• Could inline trail stat tags, that could be used like Template:Convert, be a good middle ground for usability?

• Kungsleden Etapp 24: Adolfström - Sjnultje
• Distance: {routedistance|Q134269942}
• Duration: {routeduration|Q134269942|walk}
• Cumulative ascent: {routeelevation|Q134269942}

This would definitely improve usability, and I really like the direction you’re going with it. One small concern that comes to mind: could introducing separate templates for each data point make things feel a bit less standardised overall? WhatamIdoing also mentioned a preference for keeping the number of templates to a minimum, so it might be worth thinking about how to strike the right balance.

If we’re aiming to standardise around this format, why not have a single template that covers all of these data points? This would be more in line with how listings work as well.

There are some other things to consider here as well. I had a conversation with the folks over at wikidata about cumulative elevation gain here. Potential other data points include start point and destination point (or termini). If these contain elevation data, and the cumulative elevation gain is known, cumulative elevation loss could be automatically calculated in a template. If we'd like to include net elevation gain, this can be calculated as well. Bluecoordinationfine (talk) 20:38, 7 August 2025 (UTC)Reply

> If we’re aiming to standardise around this format, why not have a single template that covers all of these data points? This would be more in line with how listings work as well.

I mostly make brief out-and-back trail listings for Park articles, so my problems are smaller than yours 😛. I want a lot of the OSM/Wikidata automagic you describe, but in a compact single-line presentation. Also, I agree with User:WhatamIdoing that the more a wiki source looks like code, the more intimidating it is for new contributors. I'm looking for a compromise that is less tedious than manual data entry, but looks more like markup than coding.

Gerode (talk) 22:31, 7 August 2025 (UTC)Reply

Also, I found that the functionality for those templates already exist, so we don't need to wait around for someone to code it (though some syntactic sugar would be nice).

Kungsleden {wikidata|title|Q59780}

• Distance: 450 kilometre {wikidata|property|Q59780|P2043}
• Cumulative ascent: {wikidata|property|Q59780|P7297}

Gerode (talk) 22:58, 7 August 2025 (UTC)Reply

Thanks for the idea! I'm happy to wait though. There's plenty to do in the mean time :) Bluecoordinationfine (talk) 19:21, 8 August 2025 (UTC)Reply

Here's a small test: Module:SectionInfo/sandbox

User:Bluecoordinationfine/SectionInfo test

This is the best I can do for now, without looking more into this. At least this is something to more clearly communicate the intent, and it's good to learn as well! Bluecoordinationfine (talk) 17:25, 9 August 2025 (UTC)Reply