Page MenuHomePhabricator

Wikivoyage mapframe and itinerary GPX traces
Open, LowPublic


The code used to display OpenStreetMap tiles in-line in Wikivoyage articles was replaced last fall. This broke a few capabilities which existed in the old mapframe code, including the ability to display a static map if a dynamic one isn't available and the ability to draw a route or itinerary as a series of co-ordinates in GPX format.

This issue was raised in October 2016 at but not resolved.

Effectively, articles like displayed an OpenStreetMap inline on the page; this map imported to a list of GPX co-ordinates which drew the path of her Benz motorcar on the map, city to city.

The "(Edit GPX)" link still appears under the map, but the actual GPX trace is not drawn at all by the new map code. Various proposals were made to replace this functionality, including but nothing was done.

As this is breaking existing functionality, this is a bug, not merely an "enhancement".

Event Timeline

debt triaged this task as High priority.Jan 9 2017, 7:44 PM
debt added a project: Maps-Sprint.
debt added subscribers: CKoerner_WMF, MaxSem, JGirault and 2 others.

Let's take a look and see if we can get this fixed or possibly find a work-around.

The problem described can be solved at Wikivoyage/en itself. The GPX traces must be converted to GeoJSON files and stored at Wikimedia Commons. I made it for instance for the Cerchiara di Calabria map. Kartographer already supports lines and polygons. Examples realized can be found at WV/de lounge. The (Edit GPX) link can easily renamed to Edit GeoJSON and redirected to Commons.

Interesting, but that does still leave a few questions:

  • The original {{mapframe}} was intended to show the map (with the GPX trace) in-line on the destination page, without requiring the user go elsewhere. Will the Cerchiara di Calabria map. display inline on the page?
  • The original idea was to permit the GPX data to be stored locally; while Commons is useful for sharing resources between language editions, if some key piece of data is voted off that wiki (which has its own local admins and policies) that breaks things for the individual dependent projects. We see this already with photos which disappear under one rationale or another, often on some obscure point of "freedom of panorama" policy. Is there still a way to store these locally if their arbitrary disappearance on Commons would break things?
  • What happens to the static map which was available as a fallback under the old system? Instead of displaying it only when the dynamic map is unavailable (and merely linking to it otherwise), pages like are attempting to display both versions and doing a poor job of it (the static map is cropped in some odd manner which makes it unusable in this case).
  • What happens to the existing pages with GPX code on - with no clear migration path, these are broken?
  • I think we will solve the problem to show {{mapframe}} both with markers and traces in the articles. I will play a little bit at my playground because it is a beta feature and will inform you at the pub if it is working well. I am not sure if there will be an automatic way to include traces to the articles. Therefore we should use intuitive file names and categories at Commons to find these Trace data easily. Of course we will loose this automatic way but on the other hand we can add several traces on several maps in an article, and we can use the same map data in different articles.
  • We should accept that all traces will be stored at Commons or OpenStreetMap. Traces cannot be copyrighted. Therefore I do not see causes to remove them with rationales as known for images. For this reason we must not store them locally.
  • Maybe we can propose a Wikidata property to store map data locations for the belonging Wikidata qualifier of these sites. Then it should be easier to find available maps.
  • I am sure that we do not need fallback maps any longer. The WMF map servers are highly available in contrast to the toolserver. But we can look for a solution to display both dynamic and static maps simultaneously.
  • Import and export of GPX files is the object of the phabricator task T55023. This is supported by Yurik, too. Therefore I hope that this would be realized in future.
  • Unfortunately the GPX code is already broken now because it is and will not be supported by the Kartographer. But both on en/Wikivoyage and de/Wikivoyage we have only about 30 traces which could be converted for instance with a GPSies converter tool. With some adaptions it takes about 10 through 15 minutes to transfer it to Commons. But I hope that the GPX support is realized soon.

Admittedly, I'm hesitant about relying on Commons and even more reticent to rely on something being present on a non-WMF project like OpenStreetMap. If is "the largest state of the Federal Republic of Germany", odds are it's a legally-defined entity and its borders are consistent and known; OSM has them tucked away somewhere. Some of our lower-level regions, though, are arbitrary: where does "southeastern Ontario" end and "eastern Ontario" begin? Each language Wikivoyage divides things differently; an imported {{mapmask}} needs the local wiki's version of these subprovincial regions as some languages have more articles and therefore divide the same territory more finely. A few novelty itineraries like the or Radiator Springs might not be marked on any OpenStreetMap. It's anyone's guess if OSM would keep on the map if it legally hasn't existed since 1985.

We might need the fallback maps for printed copies, PDF's or offline e-book readers, where we can't scroll a dynamic map. The dynamic map pretty much assumes availability of JavaScript and a live broadband connection; Wikivoyage has "print a copy to carry with you" as a stated project goal as it's intended for voyagers. Good luck getting mobile data of any kind on hundreds of kilometres of Trans-Labrador or Trans-Siberian Highway.

Certainly I'd be interested to see what can be done to recover the existing functionality we lost and repair the couple dozen itineraries which lost their existing displayed GPX traces. The number of articles is manageable as this is mostly affecting itinerary and most of our articles are individual cities and geographic destinations.

Moving off the sprint board - the Discovery team won't be able to finish this work at this time.

Jhernandez lowered the priority of this task from High to Low.Aug 7 2018, 3:40 PM
Jhernandez edited projects, added Maps (Kartographer); removed Maps.

Hallo together, although I tried to get an understanding how Phabricator works (I read the german - english introduction), I just like to let you know that I really hope to get the functionality back, that tracks can be displayed in Map Windows in Wikivoyage. I have been the author of the mentionned Cerchiara di Calabria article in wikivoyage and would like to add the track to the map, so that someone visiting the place is able to do this hike. We can do with several markers from one important point of the hike, to the next, but to have a track that eben might be loaded t oa navigation device would be much more professional. So we leave all of this to the commercially available solutions like outdoor active, which i do not like to support as it's not open source.
But when discussing with other travellers, I usually get the answer that they use Google Maps, Outdoor active and so on, they have little understanding of open source projects and from their point of view, they consider projects like wikivoyage as less useful, professional as traacks like hiking trails cannot be displayed. For me this is frustrating.
I'm not a computer crack and no developer, I just like to share my experiences at such places to other travellers, as it is the case with most Wikimedia projects. To share knowledge with others. I'm the author of most of the mentionned hiking trails / hiking recommendations in the german language Wikivoyage but I stopped doing this, as the older work is not available anymore and with the new situation, I do not know how to do it (and so I cannot write a useful help file). Thanks to the developers for all your support to our needs Martin - ~~~~