Wikivoyage talk:Dynamic maps Expedition

From Wikivoyage
Jump to: navigation, search

Contents

Integrate {{poi}} and {{listing}} as one template[edit]

Is there any plan to integrate {{poi}} and {{listing}} as one template? At least three fields (lat, long, name) overlap. K7L (talk) 06:48, 26 February 2013 (UTC)

Yes, I think that the number (somehow) and color (by tag name, e.g., "eat") should be auto-generated by the listing, and the POIs generated by the lat long fields in the listing itself. --Peter Talk 07:56, 26 February 2013 (UTC)
This is pretty god damn awesome if you ask me :) --Stefan (sertmann) talk 08:40, 26 February 2013 (UTC)
Newest version of PoiMap generates POI direct from listing,[1] use tags "eat" "see" e.g. and special icons shapes.[2] -- Mey2008 (talk) 18:39, 26 February 2013 (UTC)
For our tagged listings, the " |type=eat " looks to be generated automatically when the extension feeds the tag data to the template, so " |map=1 " would be the only new parameter. Then again, we do have many listings which are still missing co-ordinates. That might be a good task for a 'bot - import (lat, long) from nominatim.openstreetmap or somewhere? I'm also wondering if OSM's own POI database might be of use to us - there does seem to be some overlap between their POIs and our {{listing}}s. K7L (talk) 19:39, 26 February 2013 (UTC)
What needs to be done to get our listings to generate POI directly? --Peter Talk 21:24, 28 February 2013 (UTC)
We'll have to do the lat/longs for listings by bot. It's just not realistic to have humans entering these! I envision that being part of a project between us, OSM, and Wikidata, depending on how much of the hard work has already been done by OSM. Does anyone know who we should be talking to about this outside Wikivoyage? --Peter Talk 01:08, 27 February 2013 (UTC)
I also see this as an exciting new partnership between the three sites. We should be putting together a formal proposal or well-thought out set of ideas that we can present to both the OSM and Wikidata community. I think Wikidata has a lot on their hands right now, so it may be worth leaving them out until things calm down over there and we work out the intricacies. JamesA >talk 04:52, 27 February 2013 (UTC)

Wikivoyage articles on a map[edit]

Swept in from the pub

I've been browsing wikivoyage trying to decide where to go next. I ended up making a side project out of putting articles on a map: http://www.cheriot.com Cheriot (talk) 14:30, 23 March 2013 (UTC)

That's very nice! --Nick (talk) 18:27, 23 March 2013 (UTC)
That's very cool, and an interesting way to see what kind of geographic coverage we've got. What are your plans for this? Is it something that could potentially be integrated here? -- Ryan • (talk) • 17:21, 24 March 2013 (UTC)
Thanks! The first direction is adding more data. I find the most useful resources when I'm looking for a place to travel are wikivoyage, wikipedia, and google's image search. One down :) Then I want to make it easier to collaborate with the people I'll be traveling with. Still figuring out how that will work. I hadn't thought about actually integrating it into wikivoyage.org, but I'm interested in anything I can do to work with the community. I'm a big fan of this place. --Cheriot (talk) 19:39, 24 March 2013 (UTC)
This map is essential! Planning a trip without it is like walking through a labyrinth of wikilinks... This tool gives a broader vision of where interesting stuff is, what route makes sense, and what spots are on the way. I would argue this kind of map could be on the main page, if light enough. Nick, are you willing to share the overlay, so that others can build around it? Hotels/restaurants/items that have GPS coordinates could be shown as well. Nicolas1981 (talk) 09:52, 25 March 2013 (UTC)
I'm glad you've found it useful:) I suspect the bigest hurdle of getting something like this on wikivoyage is hosting. If the wikimedia foundation set up an openstreetmap server, I bet it would be easy to find volunteers to do the integration with wikivoyage. --Cheriot (talk) 02:35, 26 March 2013 (UTC)
Joachim (Mey2008) has developed such a map, as well as POI maps and a lot more (see his user page). Can we join these map-making efforts, instead of doing same job again and again? --Alexander (talk) 21:40, 25 March 2013 (UTC)
I hadn't seen those. Very well done! It would be great to get any of these included on wikivoyage.org itself. --Cheriot (talk) 02:35, 26 March 2013 (UTC)
Both are nice indeed! I feel Joachim's map could be improved by showing the region's name when hovering. Cheriot, is your source code available somewhere like Github? Nicolas1981 (talk) 10:01, 28 March 2013 (UTC)
Let's create an Interactive Maps Expedition! It would the most recent experiments, with links to source code if available. It would be a place where users can suggest cool mashup ideas, and implementors check out the existing maps, and share OSM/Google Maps/overlays/integration tips. What do you think about it? Can I proceed and create the expedition? Nicolas1981 (talk) 10:17, 28 March 2013 (UTC)
I think that makes perfect sense. Wikivoyage:Roadmap/Dynamic maps should be merged & redirected there. --Peter Talk 17:03, 28 March 2013 (UTC)
Wikivoyage:Dynamic maps Expedition created! Listing the current projects already made the current situation much clearer in my mind. Waiting for your corrections and additions! Nicolas1981 (talk) 08:03, 31 March 2013 (UTC)
How often is the map updated once articles gain the Geo template? This will be useful in the ongoing task of choosing of sub-districts for Punjab!Travelpleb (talk) 20:06, 2 April 2013 (UTC)
The Wikimedia Foundation updates the data dumps once each month.96.241.26.218 16:26, 27 April 2013 (UTC)

Milestone[edit]

The maps from the complete listing template looks great. Is there a milestone for it to be considered non-experimental? I would love to start implementing them in Singapore, though that might be a little too high profile? Looking up the lat lng is pretty rough even with a batch geocoder, so I would rather spend my time on that rather than graphical mapping if this is going to come into fruition soon. Would this also mean a push towards listing templates instead of tags. I know it's a little hectic right now with the new Main Page, but just wanted to bring up this question amidst all the changes. -- Torty3 (talk) 04:59, 27 March 2013 (UTC)

Singapore might not be the best guide to start with, for the reason you identify, until it has been tried out somewhere less high profile. If you have figured out the ins and outs of adding dynamic maps, maybe try adding one to Wheaton? I have already added lat/long to all listings in that article, so it would be an easy test case. --Peter Talk 05:39, 27 March 2013 (UTC)
I have a few ideas of what could be done, but I'm not sure so about how it would work within a wiki. Where do we put an external css like leaflet.css? And then I'd probably have to look at poimapru.php and perhaps add on to it to return JSON. Have to experiment a little, though I'm about to take a break for Easter. -- Torty3 (talk) 13:15, 27 March 2013 (UTC)

Map features and location database[edit]

Swept in from the pub

Hello travellers and contributors, I've got some news here. We have some small features on our association's server running.

  • The Map with an overview of all articles. I think you know it already.
  • The Points of interest
    • Now you can click on the colourd numbers in the articles and see it on a map (including the other points of interest) see here. IN the map you can click on the point to see a picture of it (try the church number 1 (light blue)
    • You can also include a link to the map (example: Ko Samui click on the map symbol on the right side in the district section)
  • I have setup a kind of location database. It can provide an overview over our articles. To every destination it provides some information about the other language versions. So you can see what language version provides the biggest article to a destination, including whether it is a star article or was a destination of the month or whatever. On the second tab you will find all subsidiary places (declared by the IsPartOf tmeplate). It can handle multiple hierarchies, that we use in Germany. The position map is provided in German and Italian version only, because we use an additional map-code in our templates. It's the first draft of the feature. Next steps are: 1. making the tables sortable. 2. providing a distance search aroud your article (What articles are around my place up to 50 miles? or sth.) 3. Saving the VCards (for a later usage at WikiData) and 4. Saving the categories and providing intersections of categories (e.g. What articles are in category Brazil AND Destination of the month ). These are some of the ideas. But my free time is limited. It will take a while. Some information are not stated yet, because I do not know all the template names... how is the dotm template called at the Polish language version? and so on... I will aske around all language versions and add these information....If you see any bugs and have some other ideas just let me know. We have included the LocDB to our sidebar. So everybody has an easy access to the information site of an article. Here are some examples.

If you want to add some of the map features and need some help with the templates just let us know. -- DerFussi 11:04, 7 April 2013 (UTC)

Great work! Two questions: 1) Is it possible to see the POIs in artmap.php? That would be great, especially in big cities, where borders between districts can be very artificial. 2) Is there a way to embed a small poimap2.php map inside an article, like SlippyMap? It would be extremely useful in all destination articles. Nicolas1981 (talk) 02:28, 8 April 2013 (UTC)
Nice indeed :) I would like to add some map features if there's access to the server. Particularly a push towards a standard GeoJSON layer which should be a lot cleaner. -- Torty3 (talk) 10:15, 8 April 2013 (UTC)

New kind of map, feedback welcome[edit]

Swept in from the pub

Please have a look at the map at Tokyo/Roppongi :-) I just copied what is being done by Joachim at the German Wikivoyage. What do you think about it?

It is not perfect, but it strikes me as much more maintainable than hand-drawn maps. If we want to use this at a large scale, we should integrate this with the listings system, to avoid the current redundancies (see wikicode). Then, the next steps could be embedded slippy maps, and showing points of interest from neighbouring articles when scrolling... for more info see the Wikivoyage:Dynamic maps Expedition. Nicolas1981 (talk) 07:14, 12 April 2013 (UTC)

I like the concept. Would be good to integrate with listings so we can have an interactive map that shows eactly where points of interest are.Traveler100 (talk) 07:23, 12 April 2013 (UTC)
It's definitely more maintainable than hand-drawn maps, a map I made barely two months ago is now out of date (kinda my fault though). I think there should still be a static map present in the articles, say if some old computers have no Javascript enabled (maybe detect such settings), or if the coverage in OSM isn't the best. Working together with OSM will bring up some really interesting possibilities, like what Google is trying to do with Google Local. -- Torty3 (talk) 08:27, 12 April 2013 (UTC)
Easier to maintain, yes, but I'm a little concerned about the printability of such maps, and the fact that they really aren't helpful at all until you click on them and load another page.Texugo (talk) 12:57, 12 April 2013 (UTC)
Those maps are definitely cool and I've always found the slippy map feature on other sites useful. But I also share Texugo's concerns, particularly about printability. One of our goals is to be to print out guides and having an icon that links to another map breaks that. Hopefully we can find a way to bridge the two. -Shaundd (talk) 13:11, 12 April 2013 (UTC)
Plus, even without printing them, to make use of the reference numbers, you have to flip back and forth between our page and the map page.Texugo (talk) 13:18, 12 April 2013 (UTC)
No, you don't. Just click on the number, and you will see the name. --Alexander (talk) 13:21, 12 April 2013 (UTC)
Dynamic maps are fine in print, even in black and white. The only problem is that you can't select the area of interest, export to *.png, etc. I hope that one day Joachim will solve this problem. But the decision to start using the dynamic maps on ru.wv was very simple: dynamic map is better than no map. That's more or less all about it. --Alexander (talk) 13:21, 12 April 2013 (UTC)
The map thumbnail in the article doesn't show the same area that the large map does, and that's a problem for print. The map in the article is virtually useless due to its size, its exclusion of several POIs, and the giant Rappongi Crossing popup in the middle of it. Even the large map is framed to exclude one of the Buy listings; I had to scroll or zoom out the map to see Buy #3. Also, using plain colored squares in the article is unacceptable from an accessibility standpoint; color should never be the only distinguishing factor. LtPowers (talk) 13:44, 12 April 2013 (UTC)
Agree with all your points. The minimap is useless because it's so cluttered with buildings and colors, and the big map is not much better. It would be great if we could get a new rendering of the OSM maps in greyscale that emphasizes major features and obscures or omits most other things (knowing their architecture, it's doable, but we might have to host our own rendering and tile servers; it could be a big undertaking). Markers for the POIs could be done with icons (See, Do, Eat, Drink, Sleep all have somewhat obvious choices, and maybe the template could allow it to be overridden to select from additional icons). Overall, though, I like the concept and would love to see if it can be improved. Bigpeteb (talk) 13:57, 12 April 2013 (UTC)
I really like where this is going, and think it is a future feature of our project, but there are still many kinks that must be ironed out. The map would have to be embedded within the article before it is much use. I assume if we could embed the map and display it so that all the listings are shown, then it should print fine. Though there should be an option for users to click that would expand the map fully, and allow users to print the map over a full A4 piece of paper.
Regarding the map thumbnail, it's meant to simply be a reminder to users that a map exists, so click here. It's not meant to help users find their way around the city, show where listings are, nor be appropriate for print. Nicolas has already said that embeddable full maps are in the pipeline.
Following on from LtPowers' concern about colour, I think it may work better if every listing had its own, independent number. That way, it doesn't matter if people print in B&W; number 1 will always mean number 1 on the map. That's how Lonely Planet does their maps, and that seems to be working well for them. I really don't like the icons that the map itself uses for each listing type. The rounded square looks retro, and the shopping bag is barely distinguishable and looks awful. Let's just go for colour-coded squares with independent numbering. JamesA >talk 14:02, 12 April 2013 (UTC)
Believe me, re-numbering 20 listings is a headache. Re-numbering 100 listings is simply not an option. Regarding the icons, I would really like if someone comes up with a better proposal. Joachim simply used the standard icons from our old hand-drawn maps, because nobody has ever complained about them. --Alexander (talk) 14:44, 12 April 2013 (UTC)
(edit conflict) That still hides useful information behind colors -- namely the patterns of where restaurants or bars or shopping areas are clustered. If we have to we can choose different geometric shapes for each icon color. LtPowers (talk) 14:48, 12 April 2013 (UTC)
If we can make the numbering automatic, that would be preferable. Actually, it is more of a necessity. Or else we are just adding extra work for users which should be able to be easily solved automatically. Geometric shapes could be an option, but I don't think determining clusters and patterns of particular listing types is that important. If we are able to implement independent numbering, then it shouldn't be that difficult to determine type-clusters anyhow, as all the listings from a particular section will be the same group of numbers (ie, restaurants may all be around 21-35, so a traveller simply has to look for clusters of numbers in that range). I don't think there's a need to overcomplicate things. JamesA >talk 15:03, 12 April 2013 (UTC)
I should think it obvious that the numbers "21-35" hardly stand out upon quick perusal of a map. LtPowers (talk) 16:52, 12 April 2013 (UTC)
I agree with Powers that identifying venue type clusters is very useful to travelers and facilitating it should be a map goal. A good map is a picture that clearly and visually communicates the relevant information. --Rogerhc (talk) 18:10, 12 April 2013 (UTC)
Hmmm, okay. Well the only other idea I can think of is geometric shapes, so how about:
  • squares for See
  • circles for Do
  • triangles for Buy
  • diamonds for Eat
  • hexagons for Drink
  • trapeziums for Sleep
  • pentagons for Contact
I thought about using stars, but that may come across as being something special or "recommended", which is not a message we want to send. We would also need to decide on colours; the colours we've used in the past for our maps are fine I'd think. Thoughts? JamesA >talk 03:02, 13 April 2013 (UTC)
I think you should try to draw them and put them on the map. A big advantage of our present icons is their self-explanatory nature (house for Sleep, dish for Eat, bag for Buy, etc.) Maybe we could try to keep this idea and simply improve shapes and colors? --Alexander (talk) 04:38, 13 April 2013 (UTC)
The symbols are used by all language versions. Changes would have to be discussed together. - In the map, the symbols already differ in shape and color. They are equal to the available static WV maps [3]. In the article text no symbols are possible. The colored squares are there simple background colors to the numbering. - Joachim Mey2008 (talk) 06:47, 8 February 2014 (UTC)
Thanks for the explanation, Joachim. There is also discussion of this topic that has recently sprung to life again at #Green_flower_for_.22Do.22.2C_gray_dot_for_unspecified_listings... --118.93nzp (talk) 07:00, 8 February 2014 (UTC)

Some comments by the programmer. Embedding: Simply hold the shift key when you click on the map thumbnail. The map opens in a new window. That you can reduce to a desired size. Then you have both. Scrollable article text and a fully controllable map in a separate window. Icons: The colors and shapes of the map icons were used for years for the maps in WT. I think they are ok. Of course we can change them. Layers: The existing "transport" layer shows routes of public transport, including bus stops. Moreover, it is made in pale colors. More layers are not a problem. Zooming: If you click on a marker in the text then the map is enlarged and centered to this marker. This is by design. All markers are displayed when you select the button "Show me all markers". Printing: I'm experimenting with PDF ouput. But I still have no idea how I insert the markers in it. -- Joachim Mey2008 (talk) 05:53, 13 April 2013 (UTC)

I know I'm a little late to the party on this—but speaking as someone with no experience in Wikivoyage mapmaking who is, to put it mildly, not relishing the prospect of creating no fewer than seven maps for Buffalo's upcoming district articles, I welcome this innovation excitedly. -- AndreCarrotflower (talk) 06:12, 13 April 2013 (UTC)
Regarding the icons, I feel the old ones we had that looked like the category of listing were ugly and not appropriate. I'm happy to have another look at them, with the option of possibly streamlining them so they look a little nicer. Does anyone know where a file of those icons actually exists? I can't seem to find one. Thanks, JamesA >talk 06:21, 13 April 2013 (UTC)
All icons are only once per shape. The numbers are embedded by css. New icons should therefore also offer areas of single color for the numbers. -- Joachim Mey2008 (talk) 07:20, 13 April 2013 (UTC)
If we are to use the icons found in this map, we should request that their author User:MarkJaroski release them to the Public Domain to avoid tricky attribution issues.
Also, Joachim, I understand that you don't particularly like the idea of embedded maps, but embedded maps are a core goal of the English Wikivoyage mapmaking expedition, and I don't think we will be ready to start using them until it is possible to have them placed directly into articles (with a link above them to open in full screen for mobile devices). --Peter Talk 03:33, 14 April 2013 (UTC)
Icons are from [4], [5], [6], and so on so forth. No idea if there's a base svg. Any news about permission to access the server? -- Torty3 (talk) 04:41, 14 April 2013 (UTC)
OSM and CloudMade styles (sorry bout the jaggies)

I had a play-around with CloudMade's very nice style editor, and in very little time, came up with some Wikivoyage-looking maps [7] as an example of what could be done. The licensing is still a little iffy since the map data is CC-by-SA but CloudMade has their own legal jargon. It's a nice goal to work towards, as the cherry on top. -- Torty3 (talk) 04:07, 14 April 2013 (UTC)

Good work, Torty; I like the Wikivoyage-style. LtPowers (talk) 16:22, 14 April 2013 (UTC)
A new style for maps must be created in all 18 zoom levels. This is a hard work. Therefore, I have added a similar simplified style. A 'tourism' layer with some special icons and brighter colors. Example (please choose layer 'tourism') -- Joachim Mey2008 (talk) 17:52, 14 April 2013 (UTC)
The 'tourism' layer is very nice! Joachim, would you mind sharing the settings of the 'tourism' layer? Torty (and others) could then spend time fine-tuning them. Thanks! Nicolas1981 (talk) 02:30, 15 April 2013 (UTC)
If there're no issues in using CloudMade, then could you please change this/ add another layer:
var touriUrl = 'http://{s}.tile.cloudmade.com/912ff59aa0994ac989dd3ee085b02236/997/256/{z}/{x}/{y}.png'; to this:
var touriUrl = 'http://{s}.tile.cloudmade.com/912ff59aa0994ac989dd3ee085b02236/92751/256/{z}/{x}/{y}.png';
The "Fresh" style (id: 997) is not really suited because it still has restaurant listings that appear nowhere in our guides, resulting in additional icons, so "Wikivoyage2" style (id:92751) strips it down even more. I suppose showing buildings or not is a stylistic choice. -- Torty3 (talk) 04:10, 15 April 2013 (UTC)
I have added the Wikivoyage2 style. With a little revision that could perhaps give a nice solution. Example (please choose layer 'Wikivoyage') - Joachim Mey2008 (talk) 05:03, 15 April 2013 (UTC)
As you say, some users may want to see buildings and others may not. The nice thing about using OSM is that we could (in theory) set it up so users have a choice... we can provide 2 or 3 Wikivoyage styles, as well as the default OSM styles. I think for the sake of readability and printability, the WV styles should be mostly greyscale and very muted. The traveller comes first, and although buildings are mildly helpful for getting around cities, getting your bearings by identifying main roads is more important. Perhaps it would be helpful to compare with some printed travel guides and see what style choices they made in their maps? Bigpeteb (talk) 14:03, 15 April 2013 (UTC)
An embedded map is very impractical for the user. Scroll down in a long article to the "Sleep" section. The embedded map is no longer visible. It is above the visible portion of your monitor. Will you now look for a hotel in the map? Then you mightily to scroll up. Another hotel has a beautiful location in the map? Scroll down to the appropriate text. Too expensive? Scroll up. Happy scrolling. - A floating window for the map like in my suggestion above [8] is much more practical. You always have the map next to the text you are reading. - Joachim Mey2008 (talk) 05:24, 14 April 2013 (UTC)
I agree wholeheartedly. The only advantage of embedded maps is showing that Wikivoyage has its own, dynamic map. Otherwise, the map in the separate window is way more convenient. --Alexander (talk) 12:45, 14 April 2013 (UTC)
Neither Joachim nor Alexander are wrong. I do understand though, that we need to square the best interests of the on-line user with those that want a printed guide. -- Alice 13:01, 14 April 2013 (UTC)
If embeded maps are not possible/desirable, then how about at least having a WimediaLabs-hosted script that generates miniature images? That would free WikiVoyage editors from having to do this complicated&time-consuming screenshot+crop+upload+link step after every article modification. Nicolas1981 (talk) 02:30, 15 April 2013 (UTC)
My earlier proposal with the pop-up should be a symbol. Not Mini-Map for dwarfs with thick magnifying glasses. Some German authors therefore take an existing icon image of commons. I think it's not so nice. But perhaps a nicer symbol image would be the simplest solution. I am thinking in a symbolic map with some markers and a Wikivoyage logo. Perhaps an unknown artist produce something like that. - Joachim Mey2008 (talk) 05:25, 15 April 2013 (UTC)
While I understand your concerns about usability of an embedded map, it's still critical to have it. Having an embedded map does not prevent a user from opening the map in a separate window, as we will provide a prominent link. But without the embedded map (as Alexander notes), it's very possible that most users will not realize that we have dynamic maps at all. And it would be extremely useful to have an embedded dynamic map placed next to the get in/get around sections. So I ask the same question... is it possible? What do we need to do to make it possible? --Peter Talk 19:56, 15 April 2013 (UTC)
By the way, the new Wikivoyage layer looks great ;) --Peter Talk 19:58, 15 April 2013 (UTC)
Embedded dynamic maps are possible to implement, but that requires some development effort, and I don't think the foundation considers it a priority, so WE have to experiment, and maybe develop our own Wikimedia extension, which we would then propose for deployment on Wikivoyage. The good thing is that we don't need to wait: we can start standardizing the Poi/listing format, then enter lat/long coordinates data everywhere, that will not be lost work. Switching from the current external-window maps to embedded maps will be easy in terms of wikicode modification. For now, could anyone investigate how {{Poi}} may be integrated into the listing templates? (see below) Nicolas1981 (talk) 01:58, 16 April 2013 (UTC)
To embed the interactive "PoiMap" in a mediawiki is very simple. But on this wiki is missing the widget: Iframe. This example I created in another mediawiki. I'm not a wiki expert. But installation of the widget is seemingly simple. -- Joachim Mey2008 (talk) 07:31, 16 April 2013 (UTC)
Very cool! Your demo is perfect for desktop users, and the map even gets printed (with minor width and logo problems). I see two things that still require a bit of development: 1) Support for Android 2.2 browser (and potentially others, I have only tested this one) 2) Prevent editors from using the Iframe widget to anything else than http://maps.wikivoyage-ev.org/w/poimap2.php URLs (because this could be used for spam/etc). Cheers! Nicolas1981 (talk) 09:23, 16 April 2013 (UTC)
Printers and mobile devices could not test now. Security is not a problem. Including a external page will not let that page steal the data on your site, hack into your user accounts and so on because it is protected by an iframe. Widgets have their own namespace. Access can be restricted to administrators (+ me ;-). Web addresses can be fixed entered in the widget. -- Joachim Mey2008 (talk) 11:40, 16 April 2013 (UTC)
To get the widget installed, I assume we need to file a Bugzilla request? If yes, then should the request specify that we want access to the function limited to admins? Is there anything else to include in the request? --Peter Talk 17:56, 16 April 2013 (UTC)
Be it embedded or external window, an attacker could replace the map URL with the URL of a malicious website that exploit a browser vulnerability. The German Wikivoyage already uses this (making users click on external links as part of the normal Wikivoyage experience), and would probably revert malicious URLs quickly; but still, it is more dangerous than spam, so the baseurl improvement would be very welcome.
Peter, where is the Bugzilla for Widget:Iframe?
On Android 2.2 the IFrame map is misplaced like this. I isolated the problem further: An image in an IFrame loads fine, but a map in an IFrame is misplaced. Nicolas1981 (talk) 01:38, 17 April 2013 (UTC)
Some Android browsers have massive problems with iframes. Firefox for Android can show very well iframes without any errors. Even Windows Phone 6.5 and 7 have no problems. I will test other devices. I try to provide the Android browsers with the necessary information for a correct representation. -- Joachim Mey2008 (talk) 08:55, 17 April 2013 (UTC)
I haven't filed a bugzilla request, since I still don't quite understand what to ask for and how, and what we would need to do to manage security issues. Would there be a way to limit its use to links pointing to wikivoyage-ev.org? --Peter Talk 16:03, 17 April 2013 (UTC)
I understand it like this: Just this extension must be installed. This creates a new namespace: Widget. This namespace can edit only by members of the new group "widgeteditor". The admins of Wikivoyage determine the members of this group. The widget "iframe" can created later (copy and paste from mediawikiwidgets.org), even in this namespace. Similar to a template. Inside the widget URLs can be checked for validity. - Joachim Mey2008 (talk) 17:31, 17 April 2013 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

Proposal[edit]

OK, so that would also allow us to do the tech request first, and then work out the details of implementing iframe (and potentially other widgets) afterwards. That sounds desirable and immediately actionable to me. Would anyone object to this bugzilla proposal:

  1. install Extension:Widgets, creating namespace "Widget"
  2. create a new usergroup "widgeteditor", assignable by admins
  3. restrict editing of the Widget namespace to widgeteditors

--Peter Talk 17:43, 17 April 2013 (UTC)

Support - could the editing powers be spread to autoconfirmed users rather than just 'widgeteditors' or would we rather keep this on a smaller scale? --Nick (talk) 18:07, 17 April 2013 (UTC)
I basically anticipate giving them to anyone without process who wants them, provided the user is in good standing. So it should just be a matter of asking any admin. Autoconfirmed status is acquired after simply having an account for 4 days, so it doesn't necessarily convey a lot of trust. --Peter Talk 18:24, 17 April 2013 (UTC)
Oh right- I hadn't realised! Ignore that then; my support is unconditional! --Nick (talk) 18:27, 17 April 2013 (UTC)
Support - it is a necessary step. --Alexander (talk) 19:37, 17 April 2013 (UTC)
Support and question. If they do so, would it be applicable to all language versions or just here? Pt: has been skipped over on several technical updates (such as the listing xml>template redirection), and the community there is so small it would be hard to mobilize to make this happen there. Texugo (talk) 19:52, 17 April 2013 (UTC)
We are generally a lot less coordinated after having joined the WMF. It would be great to try and revive our liaison team, and that would probably be easiest to do via an email list. Texugo and Alexander would be natural candidates for pt and ru. Liaisons could just email the list any time their language version is submitting a bugzilla request to check whether the other versions would like to be included in the change. --Peter Talk 20:18, 17 April 2013 (UTC)
As far as I understand, WMF technical staff will not do any changes for a given language version without seeing consensus reached by people in this particular language version. Therefore, we can only follow discussions here, start discussions in our language, and file independent bugzilla requests. The listings-->template redirect was, however, something different, because it was an extension deployed for all language versions simultaneously. I am wondering why :pt can't use it in the way we did: just create your own {{listing}} template and let it go. --Alexander (talk) 20:31, 17 April 2013 (UTC)
We can do that, but there is no easy way to track down the xml listings already out there to change them. Incidentally, I don't expect to be able to get much of any consensus on anything there anytime soon. The only other vocal, daily user at the moment is basically a troll who will likely oppose anything I propose on principle, preferring instead to fight to throw out our basic guidelines on just about everything: first person pronouns, random secondary external links, consistency of formatting - he has vfd'd such pages as Avoid HTML and the entire image policy and even the VfD page itself. He rails on with ad hominem personal attacks and does not appear to support any existing policy, criticizes any proposal that resembles something from en:, and seems to do his best to turn every thread into this kind of mess. In that environment, and without more people around to join in a rational discussion about potential changes, I don't think we can get any kind of change to happen. Man, I wish that guy would go away. </cry for help>. Texugo (talk) 02:26, 18 April 2013 (UTC)
Sad to hear this. We also had this threat right after joining the WMF, but fortunately, none of such people stayed long, or we even put some effort into expelling them. --Alexander (talk) 05:56, 18 April 2013 (UTC)
Support - Very few people would need to modify widgets, so I would also agree if the proposal was "install Extension:Widgets, creating namespace Widget; restrict editing of the Widget namespace to admins" (removes one step, maybe augmenting the chances to get it done fast?). This proposal does not mean sudden adoption of map embedding for all articles: We would first work on a prototype article, and make sure it is browser-friendly, before making a decision. Nicolas1981 (talk) 01:25, 18 April 2013 (UTC)
Support - This looks like a key piece to introducing dynamic maps (once the quirks are worked out as noted above). -Shaundd (talk) 04:38, 18 April 2013 (UTC)
Support - If you believe this is an integral step towards Dynamic Maps, you have my support. If we are to allow trusted users to have the editwidget rights, I agree that admins should be able to simply grant them based on their own interpretation. I wouldn't like to see another bureaucratic process. JamesA >talk 05:06, 18 April 2013 (UTC)

After consulting Peter I sent the request: https://bugzilla.wikimedia.org/show_bug.cgi?id=47400 Nicolas1981 (talk) 08:52, 19 April 2013 (UTC)

How do we poke the bugzilla people about this? -- torty3 (talk) 16:49, 15 May 2013 (UTC)
I've found the Bugzilla process pretty confusing and a little frustrating (although I realize everyone is a volunteer). I suggested a while back that we start a Bugzilla project page here, where we could coordinate efforts in work on Bugzilla, and keep track of open requests. Does anyone else think that would be worth doing? --Peter Talk 20:42, 15 May 2013 (UTC)
I do. It would also allow us to keep track (archive) of past bugs for future reference, something which would have helped me out more than once recently... Texugo (talk) 20:53, 15 May 2013 (UTC)
A Wikivoyage:Bugzilla Expedition, then? Anyone else? --Peter Talk 02:13, 16 May 2013 (UTC)

Tags to templates[edit]

The listings are integrated in [9] and [10], but I think ru.wv is using the listing template rather than the listings tags that en.wv uses. There might need to be a change from tags to those type of templates directly? -- Torty3 (talk) 08:27, 12 April 2013 (UTC)

Well, we simply discussed with Joachim and talked him into writing a script that can handle the listings template. You can try to go further and suggest writing a parser for the listings tags, but I personally prefer to stick to the template. First, the template gives us more fields and more options (that was the primary reason for introducing templates at ru.wv). Second, most of the listings lack geographical coordinates. It is necessary to add them by hand, as well as check other fields, and this activity naturally combines with converting tags in templates. --Alexander (talk) 12:39, 12 April 2013 (UTC)
To make it clearer,
en.wv uses {{Poi|map|type|lat|long|name}}<see name="" alt="" address="" directions="" lat="" long="" phone="" tollfree="" email="" fax="" url="" hours="" price=""></see>
ru.wv uses {{listing|map|type|lat|long|name|alt|address|directions|url|phone}}
I would prefer the template too, but the massive problem here is the number of tags that would need to be changed. Or is there something I'm overlooking? -- Torty3 (talk) 14:42, 12 April 2013 (UTC)
Well, most tags lack geographical coordinates, so they have to be changed anyway. I think it is a good reason to clean things up and replace tags with templates. --Alexander (talk) 14:46, 12 April 2013 (UTC)
(double edit conflict) The tags here on en are just a wrapper for Template:Listing. Does that help? LtPowers (talk) 14:48, 12 April 2013 (UTC)
It's just a matter of sending a bot through and converting all the text. Not much of a hassle, apart from everyone getting used to it. JamesA >talk 15:05, 12 April 2013 (UTC)
No, it does not. Joachim's script reads the page, and it looks for specific things on the page, not in the template. --Alexander (talk) 15:18, 12 April 2013 (UTC)
Ok, Alexander kinda cleared up some things about the listings script, but it still doesn't seem feasible to change them all by hand, and as James said, a bot could probably do the work. Which means this could be carried out separately from dynamic maps (lat lngs themselves must be added later by hand or semi-aided in case of mismatches), as long as everybody can accept such a change towards a listing template. -- Torty3 (talk) 13:36, 13 April 2013 (UTC)
In fact, the POI number ('map' field) should be also added by hand, or set up automatically (e.g., automatic numbering). --Alexander (talk) 19:01, 13 April 2013 (UTC)
I did not understand everything. But in the German WV we use this converter [11] . Perhaps the author adds <listing> to the output. For a good bottle of wine. -- Joachim Mey2008 (talk) 05:48, 14 April 2013 (UTC)
After auto-numbering is implemented, the only PoiMap2-specific parameter would be the mini-picture. So I suggest adding the mini-picture field in our listing specification. Once PoiMap2 is well-tested and open-sourced, we can set the listing template to automatically generate a PoiMap2 POI for every listing that has lat/long. Nicolas1981 (talk) 02:30, 15 April 2013 (UTC)

VoyageMap widget[edit]

I just created the VoyageMap widget, which we can use on Wikivoyage once the Widget extension is installed. It works well on my local Mediawiki test server, but does not seem to work on mediawikiwidgets.org for some reason I don't understand yet. There are still things to do: 1) For mobile browsers, show only a link 2) Validate parameters to prevent any XSS. Nicolas1981 (talk) 06:12, 18 April 2013 (UTC)

I discovered that the Widget extension is inactive, and misses OS/browser identification. Last time he was seen, the developer said "This extension is not very actively developed right now, I myself don't even have repository access anymore". Also, I wanted to replace the embedded map with a link, for mobile browsers, but there is no OS/browser identification feature, so articles with an embedded map will become useless for many mobile users (those whose phone has IFrame bugs, not sure what proportion that means), which is very sad. The WidgetsFramework extension is more active, but I am not sure it can do OS/browser identification, and it requires a bit of PHP writing. Having the WMF install the Widget extension is a very good thing to continue experimentations and try different tricks, but eventually if these tricks don't work out, we might have no choice but to write our own extension. Nicolas1981 (talk) 07:27, 18 April 2013 (UTC)

I just got a new idea: we could do the mobile/identification in poimap2.php rather than on the Mediawiki server. In case of mobile, poimap2.php would return a link to the fullscreen map. That solves the IFrame compatibility problem :-) Joachim, could you please open the poimap2.php source code, or try to implement this mobile detection? Thanks a lot! Nicolas1981 (talk) 08:20, 18 April 2013 (UTC)

Working now: VoyageMap widget Nicolas1981 (talk) 04:00, 19 April 2013 (UTC)

Sub-expedition: Fill all the latitudes![edit]

Swept in from the pub

Dynamic maps are only great if all attractions/hotels/etc have latitude/longitude... and everybody can help with that :-)

There are mostly 4 methods to get latitudes/longitudes, please use one and start improving your favorite articles! Nicolas1981 (talk) 10:43, 25 April 2013 (UTC)

Fill all the latitudes[edit]

Realistically, I don't think we're going to be able to fill in the lat/longs in listings sitewide manually. Does anyone have any ideas on how to auto-scrape that data from somewhere else? --Peter Talk 22:03, 1 May 2013 (UTC)

Technically speaking, it is easy enough to scrape the data from WV and OSM. The main problem I'm running into here is putting it back into the wiki, although someone more proficient and with more time should be able to work something out. Also this would be really trivial if the listings were actually held in a database (perhaps WikiData? a database would also be easier to maintain, entries can be sanitised, plus additional reviews could be strapped on).
The second problem is that we are restricted to OSM, which while fairly good, is no comparison to Google Maps in terms of geocoding results, failing at typos for example, and brings up a lot of false results that should not be automatically inserted into an article. I've just explored WikiSherpa and found that they have a handy listings mapper which has some great features, but they too rely on the Google Maps Geocoding service rather than Nominatim.
Also what do you think about changing xml listings to templates? I feel that might ease some of the parsing issues. -- torty3 (talk) 00:38, 2 May 2013 (UTC)
I believe that :de has gone ahead and recreated their location database, having become tired of waiting for Wikidata to get moving, so that may be the place to put this information.
I assume that using the Google Maps Geocoding service is a non-starter because of licensing issues?
And I think most everyone likes the idea of moving fully from xml to templates in the listings, but I'm not familiar with the issues involved. Perhaps start that discussion at Wikivoyage talk:Listings? --Peter Talk 01:51, 2 May 2013 (UTC)
Can't we fill in latitudes progressively as we implement new dynamic maps? JamesA >talk 08:09, 2 May 2013 (UTC)
I've ironed out most of the kinks in parsing for Geobatcher so it should be easier, although Nicolas has suggested some other good improvements to be made. I might wait if tags are going to be templated (will bring that up in Wikivoyage talk:Listings).
Yeah short-term wise, filling them out progressively would be alright, but in the long-term, it limits the scope of this expedition. Actually it might work if we roll it out region by region, as I'm reasonably sure that OSM geocoding will work great in places like the UK, Germany and the US or any place else with an active OSM community. They should have better block-by-block data, so there won't be so many false results and an address like 50 Park Rd will not return the latlngs for 1 Park Rd for example. If editors could manually run some articles through Geobatcher and confirm whether the results are 90-100% accurate for that area, then we could look at automatically doing the rest.
Google Maps Geocoding API requires users to also use Google Maps to display the data found, plus attribution to its commercial map data providers. We should actually be giving some credit to Mapquest for using their geocoding API/data right now. -- torty3 (talk) 05:12, 3 May 2013 (UTC)

Autonumbering[edit]

Perhaps we're going about this the wrong way? Autonumbering is definitely a must, but maybe we should handle it on the map server instead of the wiki? Something that might look like the current Google Maps interface when you search for something (ie A: listing 1, B: listing 2). Not sure how that would display on the wiki though. -- torty3 (talk) 00:54, 2 May 2013 (UTC)

Now that the geo template links to the map and listing templates were implemented. it's pretty evident some sort of autonumbering tool needs to be built. Otherwise maps like [12] will occur if the map number isn't entered. Probably on the list with batch geocoding. -- torty3 (talk) 15:59, 28 May 2013 (UTC)
Real-time automatic numbering in the map is not a problem. For each article or per section. But in the listings, I see no way for autonumbering. -- Joachim Mey2008 (talk) 16:43, 28 May 2013 (UTC)

Local city level travel map example[edit]

Here is the website Uexplore [13] on travel listings of Indian city, Ahmedabad. It might give some new ideas for local level map. --Nizil Shah (talk) 21:53, 13 May 2013 (UTC)

Icon design[edit]

Just want to put forth some ideas for icons here.

  1. Could they be made a tad smaller, say 24px and corresponding text one size smaller too?
  2. The gray "Do" dot really doesn't show up well, perhaps switch it to the colour of "Drink", and switch "Drink" to dark purple? -- torty3 (talk) 16:04, 28 May 2013 (UTC)
Smaller icons would certainly nicer. But then the numbers would be difficult to read. Maybe descriptions instead of numbers would be the better solution [14] . Then the problem with the automatic numbering would no longer exist. Other icon shapes are possible then. For example, the icons in editor bar above. -- Mey2008 (talk) 06:50, 29 May 2013 (UTC)
I think it will be important to keep them numbered, for users who want to print out the map. They won't be able to zoom in when it's printed! --Peter Talk 07:04, 29 May 2013 (UTC)
Is an automatically generated and matching map legend maybe the solution? [15] Then we do not need numbers to the listings as before. The legend might be turned off if required (tablet pc). When printing a sheet for map and a sheet for the map legend would be generated. -- Joachim Mey2008 (talk) 07:51, 29 May 2013 (UTC)
Yes, that looks very nice. The maps can then work separately on their own and also with reference to WV. Only a question of how to implement it, seems trickier than the current solution right now. But I'm sure you'll figure something out :) -- torty3 (talk) 13:53, 29 May 2013 (UTC)
I agree, the legend solves the problem neatly. It still would be ideal if we could have the listings in the article auto-numbered, because the legend covers portions of the map. But if that's not possible, a legend is the best solution. --Peter Talk 16:33, 29 May 2013 (UTC)

Things to refine[edit]

Now that in-wiki dynamic maps and auto-numbering in-wiki and in-map are pretty set (great work Joachim!), there're probably still several more refinements to be made. I think a map legend would still be a worthwhile effort to display even with auto-numbering, so the PoiMap2 application can work separately from the wiki.

After looking at the test article a bit more, the icon sizes really stand out. I feel like the map numbers could at least be reduced to a slightly larger font size compared to street names, as right now they are probably two or three sizes larger. The second thing is the Wikivoyage image which shows up when clicking markers, perhaps we could remove that if the image parameter is empty. Third issue is the size of the attribution, which is unfortunately long. I found a Bugzilla: 34910request which states that attribution to Leaflet could be placed on an About page. We would have something that looks like this. -- torty3 (talk) 11:25, 12 June 2013 (UTC)

These things I have noted. I'll change it as soon as possible. But on 15 to 29 June, I'm on vacation. Also, my computer has then earned a break. In small mountain huts there is (hopefully) no Wi-Fi. - Yodel-dee-ree! -- Joachim Mey2008 (talk) 14:22, 12 June 2013 (UTC)
Joachim, you have been doing amazing work, and deserve a vacation ;) Have fun! --Peter Talk 15:33, 12 June 2013 (UTC)

Manual drawing[edit]

A few things will need to be drawn by hand: 1) article borders (see light gray vs. dark gray areas on File:Bronzeville.png); 2) itinerary routes; 3) individual neighborhood boundaries (see File:Southwest Side master map.png).

  1. will be something we want for all city/district maps, and is actually a requirement for star status.
  2. will be necessary for itinerary articles that take place in one city/district (not a large number of maps).
  3. will be desirable for a small number of maps, and I think is the same challenge as #1.

How will this be possible? Will we need to register accounts on OpenStreetMap and draw these things there? Would OpenStreetMap allow this? --Peter Talk 15:33, 12 June 2013 (UTC)

For programming, I use "Leaflet". The possibilities are extensive. Have a look at the website [16]. I am currently working on integration of gpx files. Here is a first example [17]. Any number of tracks can be displayed. The tracks can be divided into track segments. Waypoints would also be possible [18]. So you could already represent some. Gpx files can be easily stored as text files [19]. - Official municipal boundaries and district boundaries can be included in OpenStreetMap. But the representation in the layers is difficult to see. Lack of roads, buildings, type of use (built-up, green areas, etc.) can be easily entered into OSM itself. Bing aerial images are the legal basis. -- Joachim Mey2008 (talk) 16:58, 12 June 2013 (UTC)
I should have known that you already have a solution ;) Is there an interface for adding polylines, curves, and points (just using a mouse)? Or is it necessary to do all editing by javascript? --Peter Talk 18:39, 12 June 2013 (UTC)
For reference, here is a list of GPS track drawing websites [20], but I found [GPS Visualiser http://www.gpsvisualizer.com/draw/] easiest to use. Drawn GPX/KML tracks can be saved (upper right corner). But we need to decide where to store these files. Wikipedia uses a template called Attached KML, don't know if we should follow their lead. Also can we use KML too? -- torty3 (talk) 17:32, 1 July 2013 (UTC)

Geobatcher for templates[edit]

Swept in from the pub

Got Geobatcher working with templates. Copy and paste listings into the textbox and search for up to 100 coordinates all at one go. It's now new and improved with drag-and-drop icons that will automatically insert coordinates into the wikitext when adjusted. Needs a little bit of patience (say 30s) waiting for results to be found and mapped. It's also not as accurate as I would like, but setting it to search by name usually returns good enough results. POI name matching could be automated in the future, though probably only after a listing/vcard database gets set up. If you want a challenge, set it to search by address, which is hit and miss depending on whether the block addresses are present in OpenStreetMap, and you'll need to check if the addresses are correct and not say 1 Main Street instead of 50 Main Street.

If there are any problems or ideas, just bring them up at Wikivoyage:Dynamic maps Expedition. It should work for de and ru, but needs tweaking for other languages. Have also noticed little bugs such as Mapquest not liking umlauts.

PS also any more refinements for the dynamic maps in-wiki? What's a good target for deployment? -- torty3 (talk) 17:17, 24 June 2013 (UTC)

I think what's remaining is really a guide for how to create them. I'm pretty sure everything we want to be able to do is now doable, but it's a little hard to judge without seeing the step-by-step process for getting them set up (defining boundaries, drawing boundaries, finding and entering listings coordinates, etc.). --Peter Talk 19:47, 24 June 2013 (UTC)
Still many things to do before we can switch on dynamic maps for everyone: 1) Test it on many desktop browsers (anyone can help, please report any bug) 2) Write offline generation of map images for mobiles 3) Write the code that displays these static images on mobiles 4) Write some code to do automatic POI number incrementation 5) Merge the PoiMap2 and see/eat/etc templates 6) As Peter said, document how to transform an article that has zero maps into an article that uses dynamic maps 7) Get Mey2008 to release the wikivoyage-ev source code as open source. Nicolas1981 (talk) 05:02, 1 July 2013 (UTC)
Number 3 is done since it falls into the general no-javascript area where a static map will show. Number 4 is done except for decision on continuous/non-continuous, and the fact that once this is included, every single listing with coordinates will be numbered. Number 5 is tied in with number 4, so it will effectively be merged (if this is what you mean). To me, number 2 is nice to have but low priority and a current weak workaround is taking a screenshot.
But yes, testing is a major problem, but now we're stuck in limbo where it cannot be implemented because it could affect the entire site, yet the entire site cannot test it because it is not being implemented. Furthermore we are trying to jump straight from zero to full deployment. I think the Javascript for Mapframe has to be added, or there won't be any further movement.
I'll start up a firmer proposal in Wikivoyage talk:Dynamic maps Expedition#In-wiki testing, about targets and implementations, etc etc. -- torty3 (talk) 17:29, 1 July 2013 (UTC)

Geobatcher[edit]

The Geobatcher is looking great! I tried using it for Kensington, though, and got a weird result because it favored the neighborhood of Kensington in London over the town in Maryland. That's despite {{geo}} being properly defined in the article (which I pasted in full). --Peter Talk 19:48, 24 June 2013 (UTC)

Similar issues for Rural Montgomery County—it favors the New York county, despite us not having an article for that. The search by name also thought that Tom & Ray's fried chicken is being served somewhere north of Novosibirsk ;) --Peter Talk 19:52, 24 June 2013 (UTC)
Coordinates biasing is a bit iffy, refining the search terms like using Kensington, Maryland instead of plain Kensington works better. It actually works independently of the geo template now but I suppose I should use it and roll my own boundary restrictions instead of letting the geocoding engine do the work. The search terms were short-circuited by the ampsersand sign, so I'll adjust it.
Should I trust your map or the other map for the Music Cafe in Damascus? :) -- torty3 (talk) 01:13, 26 June 2013 (UTC)
Whoa, I just realized that you can drag & drop listing icons and generate the right coordinates that way! (I guess I should have read the instructions.) That's really fantastic! I don't think I'll never bother getting my coordinates any other way now. And yes, adding ", Maryland" solved the issue I had. I mistakenly thought that the "city" field was supposed to match the article title. --Peter Talk 04:05, 26 June 2013 (UTC)

I'm having trouble getting Geobatcher to work with Denver. When I find coords, it only maps one listing (History Colorado Center), and puts it in the Sahara. --Peter Talk 23:29, 2 August 2013 (UTC)

Sorry, yes there's a problem with the Mapquest Open API right now, even my examples from London aren't working right when they did before. Not great timing. -- torty3 (talk) 13:19, 5 August 2013 (UTC)
Are there still issues? Geobatcher had about a 20% success rate with Winnipeg. I just resorted to using this site and entering in attractions one at a time. -- Alvanson (talk) 04:34, 6 August 2013 (UTC)

Dynamic maps working inside wiki![edit]

Swept in from the pub

The tech people thought that the Widget extension would take too long to review, and suggested a different method: inserting iframes using Javascript. I've got it working! Could someone test the code by copying User:Torty3/common.js into their common.js? Then check how it looks like in Singapore/Chinatown and Wheaton. Those without the code will see a tiny empty square, but in future that empty square could be a screenshot of the map which will be replaced by the real thing if one has the proper Javascript. This would give a static map to those who may be on a crappy computer somewhere and full mapping to others. -- torty3 (talk) 10:15, 9 June 2013 (UTC)

Excellent! Can one make the map itself clickable instead of putting the link into the caption? --Alexander (talk) 10:27, 9 June 2013 (UTC)
That's really fantastic! This is definitely something worth rolling out site-wide if we can! --Nick talk 10:40, 9 June 2013 (UTC)
(edit conflict) Wow, this is fantastic! A big well done to all involved. A few more niggles to work out and then I think we're set for a wider test. Alexander, I'm not sure that would be possible, as the embedded map is draggable and you can click on individual listings, rather than clicking to expand. James Atalk 10:41, 9 June 2013 (UTC)
Woo-hoo! It looks perfect, and simple! I even tried replacing the map at Tokyo/Roppongi, and it looks approximately 17.3 times better than what we had before. What we still need to work out then is what changes the listing template will need, i.e. how to keep the listings numbered. It would be great if we would get them to automatically number themselves in ascending order as they appear in the article, possibly starting over with "1" for each section. I don't think manually inserting numbers is a good option at all, and I really want to avoid having the numbers in the article appear in random order. Texugo (talk) 14:07, 9 June 2013 (UTC)
What tiny empty square is that? • • • Peter (Southwood) (talk): 15:09, 9 June 2013 (UTC)
I think the code was modified so that a static, "Wikivoyage-style" map will appear when a user's JS is disabled or there is some kind of other error. So now no one should see a tiny empty square! James Atalk 02:19, 10 June 2013 (UTC)
The statistics of the WV-ev server counts only 1 per 1.000 visitors without Javascript. For this a symbol image (linked to the dynamic map) would be enough, I think. -- Mey2008 (talk) 05:17, 10 June 2013 (UTC)
Auto-numbered listings and iframe map
Lots of exclamation marks here! There's still a tiny empty square in Wheaton, though a symbol image would work great too. Ok, for auto-numbering, there's a really elegant solution using CSS. If an admin is happy with that, it would be best to copy that quick because otherwise there's an extra space before listings with coordinates (couldn't find another way). -- torty3 (talk) 09:56, 10 June 2013 (UTC)
Looks good. However, I think the auto-numbering should continue across headers, rather than restarting for each section. It will assist those printing in black and white or those with colour vision difficulties. I haven't copied the code across yet, because some temporary, minor display issues on two pages isn't much of a problem while we're discussing. James Atalk 12:18, 10 June 2013 (UTC)
For continuous auto-numbering by article I already have a new PoiMap2 version [21]. -- Mey2008 (talk) 13:09, 10 June 2013 (UTC)
I actually think continuous numbering across section headers would make things harder for people with color blindness in a way, since it would be easier to confuse numbered icons with preceding numbered icons. Shouldn't different shaped icons take care of James' concern? --Peter Talk 18:21, 10 June 2013 (UTC)
Not quite sure what you mean. Wouldn't it be easier to confuse numbered icons with previous ones if they were the same numbers, rather than if they were different? Shapes are a possibility, but I'd like to see what it looks like. Will the shapes also be present on the actual article, as well as the map? If not, there would be inconsistency. I suspect having lots of different shapes may look a little odd and disorganised. Lonely Planet, Frommers and other guidebook writers have used B&W, continuously numbered, non-shape listings for years, and no one seems to complain about that. James Atalk 12:08, 14 June 2013 (UTC)
Well, I do complain (quietly). Numbers above 100 are difficult to comprehend, and even with two-digit numbers LP maps are not very easy to use (this is partly because they mix POIs shown on different maps). Personally, I prefer to use separate numbering for each section. But it is a matter of taste, and perhaps a general decision: do we want to be similar to printed travel guides, or rather different from them? --Alexander (talk) 13:29, 14 June 2013 (UTC)
I am with Atsilirn on this, and I would much prefer to limit the number of features in each section displayed on the map to 10. Anything more and we are better off splitting into districts. With four major sections with POIs featured on the map, it is already almost 40 POIs to track.
As concerns clearly linking the shapes on the map with particular sections in the article, a subsection banner with an icon included would do the work brilliantly, as we discussed at Wikivoyage talk:Banner expedition. Perhaps a workaround could be found to make those available despite MediaWiki not supporting sectional headings and TOCs. PrinceGloria (talk) 14:38, 14 June 2013 (UTC)
10 listings per section is ridiculously small for most of our travel guides. Our district articles aren't even that restrictive. Look at San Francisco/Civic Center-Tenderloin, for instance. LtPowers (talk) 14:44, 14 June 2013 (UTC)
Yes, 10 POI's/section is way too small. The idea is to have a reasonable number of districts according to local history and geography, not to the POI density on the map. Our current situation is such that big cities described in a single article, or districts of big cities will easily run above 100 POI's. Therefore, we either accept three-digit numbers (requires some designer work on the map symbols!) or keep individual numbering in each section. --Alexander (talk) 14:54, 14 June 2013 (UTC)
That only adds to the argument of keeping individual numbering per each section. PrinceGloria (talk) 15:03, 14 June 2013 (UTC)
Wonderful! Of course it is not ready yet, but when it is ready, is deploying this JavaScript for all users something that can be easily done? I guess it will require some "paperwork" as well, right? A good thing is that JavaScript can recognize the browser, and for instance show something different for mobile browsers. I guess JavaScript could do the numbering, too. If JavaScript and maps.wikivoyage-ev.org use the same numbering convention, there is nothing really difficult I guess. Nicolas1981 (talk) 14:24, 10 June 2013 (UTC)
Isn't deploying it for all users a simple matter of plopping it into Mediawiki:Common.js? Texugo (talk) 14:45, 10 June 2013 (UTC)
S'ok, should have really made it clearer that what I did affected more than two articles. Was trying to sandbox it but also didn't realise that the change was that disruptive (empty pink boxes). The hard part is testing it in tandem, the CSS automatically finds and numbers the template, so they both have to be done together. So that's combined deployment into Mediawiki:Common.js, Mediawiki:Common.css and Template:Listing.
I would lean towards non-continuous numbering, though I'm fine with whatever everybody agrees upon. -- torty3 (talk) 01:01, 11 June 2013 (UTC)
I think different icon shapes on the map should allay any concern about usability. I personally think that the fewer double-digit icons we have to use, the less noisy and more easy-to-use the map will be, plus there is just something random about continuing the number from wherever a previous section left off. I fail to see how that could be better. Texugo (talk) 01:30, 11 June 2013 (UTC)
Continuous and non-continuous both have advantages, anyone feel free to decide. I implemented the new kind of map on Tokyo/Roppongi, below the static+link map (which I let for users who haven't modified their Common.js). Nicolas1981 (talk) 06:27, 11 June 2013 (UTC)

Hey this is crazy and this is crazy but this is crazy so this is crazy - how do I access and modify my commons.js? I want to see Nicholas's map :( PrinceGloria (talk) 07:03, 11 June 2013 (UTC)

If you go to 'Preferences' and then click the 'Appearance' tab, the 'Custom JavaScript' link should take you to a page where you can just copy the code in at the bottom. Hope this helps! --Nick talk 09:48, 11 June 2013 (UTC)
It sure did! Works and looks brilliantly, thank you Nicholas and everybody involved! PrinceGloria (talk) 15:35, 11 June 2013 (UTC)

Offline/printed guides and use on mobile devices[edit]

The dynamic maps look nice and will certainly be a great/useful addition to Wikivoyage. However, dynamic maps will only (easily) be useful when connected to the internet. Here are the goals of Wikivoyage (numbers added for ease of discussion) from Wikivoyage:Goals and non-goals:

  1. Online use by travellers on the road – for example, travellers huddled in a late-night internet café in some dark jungle, who need up-to-date information on lodging, transportation, food, nightlife, and other necessities.
  2. Offline use by travellers on the road – for example, travellers sitting in a train with a subset of Wikivoyage on their mobile device.
  3. Online use by travellers still planning – for intending travellers who want to review destinations, plan itineraries, make reservations, and get excited about their trip.
  4. Individual article print-outs – for people who want to print, say, a list of museums or karaoke bars and put it in their back pocket for when they need it.
  5. Ad-hoc travel guides – for people who want a small fit-to-purpose travel books that match a particular itinerary.
  6. Inclusion in other travel publications – for travel-guide publishers and advisers who want up-to-date information.

As far as I can tell, dynamic maps do not meet goals 2, 4, & 5 and don't work with goal 6 in print and some web reuse (only ok for reuse online and where the editor has the ability/knowledge to add the code to create a dynamic map). This isn't an attempt to derail the addition of dynamic maps, but rather to think through all implications before rolling out on more articles. The following situations need to be addressed in the code before being rolled out:

  • Compatibility with mobile devices (Android, iOS, Windows phone...any other systems worth catering to?) and the mobile version of Wikivoyage. Will the presence of a dynamic map slow down the time it takes for a page to load on a mobile phone data network and/or increase the download size of the webpage on a mobile device significantly. Depending on mobile network and whether at home, roaming abroad, or using a local pre-paid SIM abroad, there can be significant charges for data traffic...if a dynamic map changes a page size from 50KB to 1MB, that can make a big difference in terms of cost and download time (like on a 2G network).
  • Download time and ease of use on slower connections. How slow of a network is reasonable enough to cater to? 56kb/s? 100kb/s? 500kb/s? (Not just on a computer, but on a mobile phone network as mentioned above).
  • Use in print and offline, including the under-used & under-developed books extension.

With regards to the last situation, could a program be written that would allow a user to define 4 point (coordinates) that would serve as the corners of a map which would be downloaded at an appropriate scale and saved as a PDF file or .png/.jpg image (offline use on electronic devices) or printed at a reasonably legible scale? This would take a lot of work, but it's at least a reasonable suggestion...any solution will probably require a lot of effort to develop. Existing maps could be displayed on the mobile Wikivoyage and when printing or using the books extension as an interim fix, but that won't work if dynamic maps are added to a large number of article where there is no existing map. AHeneen (talk) 03:21, 11 June 2013 (UTC)

Mobile on-line use: The maps should not embedded in the articles in the mobile version. They can be loaded on demand via a link. The load volume is about 300 kB per view on a 7-inch device. A static map of the same size is about 1000 kB - 3500 kB because you always have to load the complete file. - The mobile application "PoiMap2" was successfully tested on many current mobile devices.
Mobile off-line use and printing: With a simple PDF printer driver, you can save the article as a PDF file [22] . Map sections in A4 format are also possible [23] .
Mobile maps not want to imitate hand-drawn maps. They have advantages and disadvantages. Mobile maps are much better than no maps for most articles now. Extensions are later also possible. -- Joachim Mey2008 (talk) 05:55, 11 June 2013 (UTC)

I have geographic data for every classified road in the UK and Ireland (examples here here here) and I'm working on some code (for another project) that will take a lat, lon, zoom and polyline trace file and return a static image centred on OpenStreetMap with the lat / lon at the zoom provided and draw the trace on top. The idea being a bot can then scrape relevant geodata and produce static images that would then be available for an app to cache online. Preliminary discussions and a bit of code [here]. Ritchie333 (talk) 08:25, 12 June 2013 (UTC)

Interesting project and ideas Ritchie333. That would definitely make static maps much easier. Care to join in at Wikivoyage:Dynamic maps Expedition and possibly post updates there? Though I'll keep tabs on it myself. -- torty3 (talk) 11:57, 12 June 2013 (UTC)
Ritchie333, you seem to be able to save us all! Batch-generating static maps would solve all problems :-) Each article would contain the static map, and JavaScript would load the dynamic one. That way, the article is still totally usable by mobile users, people who turned JavaScript off can still, people who printed the article, people who save the article as HTML+images. Let's get started! Is there a server somewhere that can generate a static map from the dynamic map linked in the article Tokyo/Roppongi, for instance? Depending on the load of the server, we could re-generate static maps at every edit of the corresponding article, or once a week, or on demand. Nicolas1981 (talk) 08:53, 13 June 2013 (UTC)
Okay, I have quickly knocked something up for your Roppongi example at www.sabre-roads.org.uk/maps/static.php?lat=35.66262&lon=139.73060&zoom=16. That should have put the map on lat 35.66262 lon 139.73060 zoom 16. There's no javascript, it's vanilla html (provided your browser can handle absolutely positioned divs, which most can), and will always be up to date with respect to OpenStreetMap. Currently, you can only get a 384x384 map - to get anything larger requires "spidering" the tiles out to more than the 2x2 matrix I have currently, but hopefully that's not rocket science. However, on a mobile device, 384 square is probably an acceptable maximum, I would have thought, and it keeps OSM usage down to a minimum. Ritchie333 (talk) 11:18, 13 June 2013 (UTC)
Nice! But it is 4 different images, right? So we will need a script that combines the 4 images into a single one. ImageMagick (available in PHP) is probably able to do this. In fact, the PHP script should be able to deliver just the image (in PNG format), not an HTML page. The "Data CC-By-SA by OpenStreetMap" mention could be added via a template, so no need to worry about it, I think. Also, any chance you can get the POI (Point Of Interest) marks in the image as well? Mey2008's source code would be very helpful to implement this. Nicolas1981 (talk) 08:36, 14 June 2013 (UTC)

Here is a Leaflet extension whose purpose is to generate a PNG image of a given map: https://github.com/tegansnyder/Leaflet-Save-Map-to-PNG Nicolas1981 (talk) 10:55, 19 June 2013 (UTC)

Hi I created page about ShareMap tool (I am on its developers) that has features mentioned above. Please visit Wikivoyage:ShareMap an leave you feedback or map request for article. Thanks --Jkan997 (talk) 00:05, 6 July 2013 (UTC)

In-wiki testing[edit]

We don't seem to have a proper agreement on when and how to implement dynamic maps, so here's a try. Embedded map should be good to go, ready to be included in Mediawiki:Common.js. Autonumbering is also done, albeit more contentious. Continuous numbering is easier to implement, but non-continuous numbering will look better for articles with lots of listings. There may also be questions on style: shapes, colours, size of icons etc.

Stage 1: Limited testing[edit]

Put embedded maps and continuous autonumbering on a few chosen pages, so there are at least live examples:

  1. Copy code from Template:Mapframe/MapFrame.js to Mediawiki:MapFrame.js (also remove pre tags)
  2. Add importScript('MediaWiki:MapFrame.js'); to Mediawiki:Common.js
  3. Add the following code to Mediawiki:Common.css
/*** counter for mapping listings ***/
.page-Wheaton span.listing-map:before {
    content: counter(mapnumber);
    counter-increment: mapnumber;
}

.page-Singapore_Chinatown span.listing-map:before {
    content: counter(mapnumber);
    counter-increment: mapnumber;
}

First steps first. Once this is added, everybody can view the maps and comment instead of altering user JS and CSS. Continuous numbers are used because of technical issues (see below). Are we all OK with this and the above?

Stage 2: Site-wide[edit]

To get here, there needs to be an agreement on the look of the map and icons, as well as the numbered listings. A short guide on how to use Mapframe and find/use coordinates must be written.

Now it gets tricky. I'm also of the opinion that a dynamic map is better than no map, so if everybody is happy with stage 1, then I say remove the article-restricted bits for CSS and change the listing templates. What this means is that all listings with coordinates will have a direct map link and number. {{Mapframe}} would also be open to use.

I imagine this could get mixed consensus, depending on how high maps are a priority to everyone. This would be a really major achievement though, and hopefully will done soon enough. Work will be continued on mapping boundaries regarding their look and where to upload GPX tracks.

Stage 3: Full featured maps[edit]

Yay nearly there. Boundaries can be detailed and mapped for a few test articles. It's going to be a long while for articles to get their own gpx data, especially for WV-peculiar regions. Things to complete: full guide from zero maps to embedded map with boundaries and numbered listings, image tool to copy static maps from dynamic maps.

Comments[edit]

Further thoughts? -- torty3 (talk) 17:32, 1 July 2013 (UTC)

This looks very solid. Adding in-article dynamic maps would still be done manually, right? (As opposed to the links from listings.) --Peter Talk 19:34, 1 July 2013 (UTC)


Stage 1 feedback[edit]

If you want to keep feedback about the process separate from feedback on what we're seeing now in Stage 1, please feel free to move this to a new section. In Stage 1 you mention that you were using non-continuous numbering, but it looks like Wheaton and Singapore/Chinatown are using continuous numbering. The Singapore/Chinatown example in particular is a pretty good illustration of why continuous numbering can look pretty confusing on the map! Also, looking at Wheaton, is the plan to have the map icon shapes with numbers next to the listings in-article, instead of just the color boxes? --Peter Talk 19:34, 1 July 2013 (UTC)
Unfortunately, I had implemented continuous numbering in the maps. I had not read this proposal. I removed the numbers. I will adjust later to the non-continuous numbering. -- Joachim Mey2008 (talk) 03:42, 2 July 2013 (UTC)
A non-continuous numbering should include the general '{{Listing |' template. This template can occur in different sections. Furthermore, I see problems with the 'itineraries' articles. There are no fixed sections (See, Do ...) [24]. A continuous numbering would be the better choice in both cases, I think. -- Joachim Mey2008 (talk) 03:59, 2 July 2013 (UTC)
A technical knock out! Good points, Joachim, can't think of a workaround for now. I'll be OK with continuous numbering.
And we're not actually in stage 1 yet, I can't edit the Mediawiki pages, so could you do that Peter? The plan is to have the numbers in the square colour boxes, but the map icon shapes could probably replace the colour boxes if wanted. And in-article dynamic maps will have to be added manually. I suppose it could be automated eventually, same as coordinates. -- torty3 (talk) 04:45, 2 July 2013 (UTC)
I have edited the MW pages, and double checking my edits would probably be wise ;) Re: numbering, would the only way to get non-continuous numbering working be to have a unique "tag" on listings in each section? And yes, itineraries should not use non-continuous numbering, but I don't think this is an issue anyway, since our itinerary articles don't use listings templates (e.g., The Wire Tour, Loop Art Tour, Along the Magnificent Mile, etc.). --Peter Talk 04:56, 2 July 2013 (UTC)
Looks good, non-continuous numbering is working although I sneakily changed the CSS code to continuous numbering when you weren't looking :) (see above) and MediaWiki:MapFrame.js needs to have the '<pre>' tags removed. -- torty3 (talk) 05:04, 2 July 2013 (UTC)
Removed. And hmm—the numbers are now happily there next to the listings, but have disappeared from the map itself! --Peter Talk 06:11, 2 July 2013 (UTC)

@Joachim, could you go ahead and activate the continuous numbering again? Also any news about changing icon size? It seems hardly right that the icons are larger than highway shields, and you can still read the numbers.

@Peter, I made a mistake in the javascript file, forgetting to close a comment --> add a matching */ at the end of this phrase /* for embeddable dynamic maps. Relies on HTML5 data parameters. from Mediawiki:MapFrame.js. Looks like we have to change to continuous numbering for now, so have to remove .page-Wheaton h2 { counter-reset: mapnumber; } and .page-Singapore_Chinatown h2 { counter-reset: mapnumber; } from Mediawiki:Common.css.

Hope that fixes everything for now. I thought of a few things that would allow non-continuous numbering, but it will get messy, particularly in coordinating efforts. -- torty3 (talk) 02:05, 3 July 2013 (UTC)

Done, although I'd like to double check that you didn't also mean to add a */ after the Usage: inserts... line in MediaWiki:MapFrame.js. --Peter Talk 04:11, 3 July 2013 (UTC)
@torty3: I turned on the continuous numbering again. But even to a non-continuous numbering I could switch immediately now, if desired (reset on all H2 headings). Maybe we should test both possibilities in practice. -- The size of the icons I will shrink in the coming days. -- Joachim Mey2008 (talk) 05:27, 3 July 2013 (UTC)
It would be great if we could test both. Maybe activate the CSS and change the listing templates for the Rheinsteig itinerary? By the way, I noticed that the numbers stay at 1 for southern hemisphere countries, see Cape Town [25] and Melbourne [26]. -- torty3 (talk) 11:38, 3 July 2013 (UTC)
The article Rheinsteig I copied to User:Mey2008/Sandbox for testing. The original article is being updated frequently. -- Joachim Mey2008 (talk) 10:17, 4 July 2013 (UTC)
In the map, the southern hemisphere is now numbered correctly in both versions (cont. / non cont.). - But I see only not clickable markers with "1" in Wheaton article text. ?! -- Joachim Mey2008 (talk) 14:53, 3 July 2013 (UTC)
Looks like it does need a reset counter. @Peter, could you change the CSS code again to this? General CSS seems fine, and will only apply to pages with the {{Listing/sandbox}}.
/*** counter for mapping listings ***/
body { counter-reset: mapnumber; }
span.listing-map:before {
    content: counter(mapnumber);
    counter-increment: mapnumber;
}
Yes Done. The problem appears to be fixed. James Atalk 13:11, 4 July 2013 (UTC)

Hi, could someone change Mediawiki:MapFrame.js to match Template:Mapframe/MapFrame.js. It removes the extra caption. Thanks. -- torty3 (talk) 08:33, 11 July 2013 (UTC)

Maplinks[edit]

And for the maplink, I was trying something out because I noticed the printable version is messed up [27]. Any ideas to fix it? Maybe Javascript again... -- torty3 (talk) 09:38, 4 July 2013 (UTC)

There's a tool for suppressing links and / or coordinates in the printable or PDF versions (German WV). - Example -- Joachim Mey2008 (talk) 10:10, 4 July 2013 (UTC)
Cool, how do you do that? -- torty3 (talk) 13:23, 4 July 2013 (UTC)
Go to your German account. Then select Einstellungen / Helferlein / Druck [x] . Then use print option in your browser. The link in the side panel is still buggy: No one needs hyperlinks in a printed copy. -- Joachim Mey2008 (talk) 12:43, 5 July 2013 (UTC)
Certainly, but that might stir up a different set of issues. Will have to install that tool here as well then - is that just a display:none for external links? -- torty3 (talk) 12:59, 5 July 2013 (UTC)
There is <div class="noprint"></div> that can be added to certain elements so it does not appear in print. You could have a play around with that. James Atalk 13:26, 5 July 2013 (UTC)

GPX tracks[edit]

Nice work on the GPX tracks! Uploaded a quick version on Singapore/Chinatown, is it better in mainspace or template space though? As in Wikipedia has an "attached KML" template [28], then the text file is "Template:Attached Gpx/Placename" rather than "Placename/Gpx". I'm not sure which is better practice but bringing it up now at the start. Template style - can see how many GPX files there are, while Placename/Gpx is more closely related to location. -- torty3 (talk) 13:10, 5 July 2013 (UTC)

Nice! How did you go about generating the GPX tracks? --Peter Talk 08:14, 9 July 2013 (UTC)
There are many possibilities. The simplest: go to route editor. Click all points for your own track. Save as mytrack [TRACK]. Create a Gpx subpage in the wiki. Copy gpx text to wiki. Change the header like this: [29]. -- Joachim Mey2008 (talk) 10:41, 9 July 2013 (UTC)
Very cool! --Peter Talk 05:45, 10 July 2013 (UTC)

I've created a GPX file for Virgin Gorda, which is a crude polygon grouping the islands covered in the article. But would look a lot more elegant to use GPX tracks that would follow the polylines that OSM uses to outline the islands themselves... is there a good way to grab and convert them? --Peter Talk 06:16, 1 August 2013 (UTC)

To clarify, I mean converting a way like this one into a GPX track without manually copying down all the coordinates for each individual node. --Peter Talk 06:20, 1 August 2013 (UTC)

There are the following solution: Start JOSM | file | download object: way 157837054 | export to GPX. You may shorten the file with Notepad++ (time-tags etc.). -- Joachim Mey2008 (talk) 05:38, 2 August 2013 (UTC)

That works! I experience one problem, though. It seems that the map will only display a set number of GPX track segments. Because there are many coastlines defined for Virgin Gorda, everything below Mosquito Island on Virgin Gorda/Gpx does not show on the map. Do you know how to fix this? --Peter Talk 08:07, 2 August 2013 (UTC)
The GPX functionality is still somewhat limited. Only one track with a maximum of 48 segments is possible. Only the segments may have <name> and <desc> tags. The segments are presented in a fixed order in 12 different colors. By clicking on a line, name and description are displayed. -- Joachim Mey2008 (talk) 10:50, 2 August 2013 (UTC)
Thanks again for your help with this! Is there any way to control the line colors? For tracks showing the outlines of islands in an individual article, it would be best for them to all be the same color. --Peter Talk 21:54, 2 August 2013 (UTC)

Awesome functionality. Is there anyway to have the GPX option switch on for the geo map at the top of the page? Would be useful for Itineraries. Traveler100 (talk) 08:24, 1 August 2013 (UTC)

The Template:Geo has two new (experimental) parameters: zoom and layer (not: layers). A description you will find here: [30]. -- Joachim Mey2008 (talk) 13:45, 1 August 2013 (UTC)
It occurs to me that the GPX tracks should really be in another namespace like Template. Otherwise if we have one GPX for each article, we get a total of 50,000 articles counted, from an actual 25,000. What do you think Joachim? -- torty3 (talk) 02:16, 6 August 2013 (UTC)
GPX files can cause a lot of work. Collect, prepare and generalize data. GPX data have a great benefit for some users. You can download them and use them for hiking or cycling. Therefore, you might also count these sites. Rather than the many articles with nearly empty destinations. - In a filing as a template the GPX files should all have a common name. For example: Template: GPX-article name (GPX-Boston/Downtown). These templates should be all the 'Gpx data' category. Then you can easily access it and also find. - Or to make a template Gpxdata|filename. Then you can use any file name. - You decide, I will adjust the program accordingly. - Joachim Mey2008 (talk) 05:27, 6 August 2013 (UTC)
Fair enough, I think that's really true for GPX tracks especially, and I don't really care about the article count. I will leave it alone for now, but I think it could lead to a ton of discussion about what is an article and I rather not start another long debate over there. How is de.voy treating it? -- torty3 (talk) 12:53, 7 August 2013 (UTC)

I've created GPX tracks for Winnipeg. Is it possible to control the colour of each track? Also, is it possible to shade the regions bounded by the tracks? I can see these features being useful for districting, or in Winnipeg's case, for highlighting some of the more touristy neighbourhoods (in lieu of full districting). -- Alvanson (talk) 04:30, 6 August 2013 (UTC)

The sequence of colors is hard-coded at the time. It changes per section. OSM relations often consist of many sections. With JOSM and "merge lines (C)" can be summed up these sections. As a result, there is only one color per relation. - Shades and other functions are not possible. The GPX feature is not yet complete. There will still be changes. - Joachim Mey2008 (talk) 04:56, 7 August 2013 (UTC)

How do I create a custom GPX track for a district? I still can't get it to work. With Gnuher, I can only make a line, but I cannot finish it as a shape. Globe-trotter (talk) 16:33, 10 August 2013 (UTC)

Download from Gnuher as track. Open Gpx.file in an editor (eg Notepad++). Copy the first track point line. Paste it to the end. Start point = end point. Done. - Joachim Mey2008 (talk) 17:25, 10 August 2013 (UTC)

Icon sizing[edit]

I've noticed that the icons are very large, which can obscure other features on the maps, and cause a lot of icon overlap. The icons themselves are a lot bigger than the text they contain, and even the text is a significantly larger font than the article text. Optimizing it like I have (obsessively) in hand drawn maps like this one is something I think we should work towards. The numbers should be readable at a slightly smaller font than the article text, provided they are bolded, and the icons can be shrunk so that they do not cover much space beyond the numbers. --Peter Talk 06:19, 20 July 2013 (UTC)

I've made this point really, really obvious by putting a dynamic map next to a static one at Virgin Gorda. The static map's icons are readable at about 1/4 the size of the dynamic map's icons. --Peter Talk 06:29, 22 July 2013 (UTC)
I have reduced the icons to 75% of the original size [31]. The numbers are now 10 pixels high. An even smaller font is hard to read on high resolution monitors. After some testing I will update the current version. -- Joachim Mey2008 (talk) 14:53, 22 July 2013 (UTC)
I think that looks much better. When will the smaller icons appear in mapframe (in-article)? Also, is it possible to use a "thicker" bold font, like DejaVu Sans Condensed? That shows up more clearly at small sizes, I think. Lastly, I think the size of the shape could be reduced for see, do, and buy listings, without changing the size of the number. (Every little bit of space saving will make the map easier to read in-article.) --Peter Talk 19:04, 22 July 2013 (UTC)
Today I took the smaller icons to the working directory. I have taken the font bold 'Tahoma'. This font is available on Windows, Mac and Android as a standard. -- Joachim Mey2008 (talk)
Would it be possible to scale icon display sizes to user preference? Could we have three options for users to choose from: small, medium, large? --Peter Talk 06:05, 10 August 2013 (UTC)
That is possible. Also, map scale, and screen resolution can be considered. That makes some effort and is only rewarding if the dynamic map is generally introduced in WV. -- Joachim Mey2008 (talk) 06:24, 10 August 2013 (UTC)

In-article icon sizing has been commented to be too big. Does this look better? 10 compared to 1 Name. -- torty3 (talk) 13:10, 5 August 2013 (UTC)

ShareMap.org - evaluation welcome[edit]

Hello, I am one of developers of open social mapping portal ShareMap.org. This portal allows multiple users to collaborate on maps (in wiki style) that are later available in multiple formats - static one - SVG,PNG and interactive one on ShareMap site or within wikipedia - take a look on this article clicking the globe icon in top right corner.

ShareMap has a tool to import data directly from OSM, from GPX tracks or by tracing old raster map.

This tools is already used with Wikipedia articles and there are some comments of well known Wikipedians specialised in mapping that commons:User:ShareMap evauluated is usefulness.

But because requirements of WikiVoyage is slightly different I'll be glad to hear from community how ShareMap can help with designing expedition maps.

Examples of usage scenario of ShareMap are available on YouTube channel.

Here there are examples of maps done already created with ShareMap

--Jkan997 (talk) 14:51, 2 July 2013 (UTC)

I've been trying out some of the maps, and it's an impressive endeavour. Static maps would work great, but would it be possible to number some of the waypoints? And ideally uploading our own desired markers. As an example, Cape Town would get a static map of something that looks like this.
Collaboration-wise, I think this could really help during regions/districts discussion. Not too sure about pinning listings, because we need the information to go along with the coordinates. -- torty3 (talk) 09:53, 4 July 2013 (UTC)
Thank for comment - yes we consider adding ability to add custom markers and add some SVG markers that has some VARIABLE inside (for example number) - I will let you know when it will be ready. What do you mean by pinning listing? --Jkan997 (talk) 14:17, 5 July 2013 (UTC)

ShareMap now haves its page on WikiVoyage - please visit Wikivoyage:ShareMap.

Shanghai map[edit]

The Shanghai article now has a dynamic map and presumably the districts can get them once we add geotags. Nice going, people.

However, when I go to the map all the street names are shown in Chinese characters even though I am coming from English WV and the URL shown includes "lang=en". Can this be fixed? Pashley (talk) 12:18, 4 July 2013 (UTC)

Street names can only be displayed consistent with OpenStreetMap data. English street names were not included in this area. An example from Taipei shows also Latin letters for the street names. -- Joachim Mey2008 (talk)
To elaborate, the "lang=en" code in the link only refers to our own en:wv articles. Technically the official OSM stance is to name the roads locally, and give a separate tag for English/any other language names . We could then set up our map server that specifically sets the language [32]. The WMF actually hosts some map servers that show how this would work [33]. But this is pretty costly, and we are using Mapquest now. Taipei doesn't seem to be following the naming scheme, same for some of the Shanghai roads like Century Avenue (which suggests a shifty solution). -- torty3 (talk) 13:22, 4 July 2013 (UTC)
The explanation makes sense, I have nothing but praise for the work so far, and the current map is far better than what we had until a few days ago, but as I see it we still have a serious problem. For most visitors, English street names would be far more useful, so I'd say that in the long run we need them quite badly.
On the other hand, I will not push at all to get this done quickly since both this team & the server resources have constraints that I do nor pretend to understand.
Checking around a bit, I find the problem is fairly general. e.g. Riyadh, Tehran and Tokyo show most street names in a non-latin alphabet. I do not think changing names in Vienna to English is even worth considering and, at least to me, leaving Moscow names in cyrillic seems fine too. but I'd say Chinese characters and the Arabic alphabet do not belong on our maps. Pashley (talk) 19:27, 4 July 2013 (UTC)
I think the language doesn't matter, but the script does. Every map should use Latin script together with the native script. I hope OSM will reconsider their decision because maps like Bangkok are now largely useless for those not familiar with the Thai script. Globe-trotter (talk) 19:46, 4 July 2013 (UTC)
I agree. Pashley (talk) 19:51, 4 July 2013 (UTC)
Yep, I also agree about the Latin script, but the OSM practice is understandable as they rely even more exclusively on local development and use, so no surprises why local names are preferable there. Plus the fact that OSM has very few servers compared to the thousands that Google has. Might be worth following up more on downstream tile providers like Mapquest, who have partial English internationalisation for place names but not street names - oddly enough.
Short-term solution may just be to include Google Maps as a layer (not default of course), which would also cover our other problem where OSM has less detail than Google Maps. Though they don't necessarily have it all in English either. This is a case where custom maps clearly outshine dynamic maps, but even placing coordinates will help mapmakers. -- torty3 (talk) 13:27, 5 July 2013 (UTC)
I could install a Google layer or Bing layer. - The registered association "Wikivoyage eV" is recognized by the German government as a charitable and non-profit organization with tax-exempt status. Therefore, we could probably get a free Bing Basic Key [34]. But my English is not adequately. Can someone check? -- Joachim Mey2008 (talk) 14:03, 5 July 2013 (UTC)
I do not think we can directly use Google maps or make dynamic use of Google translate because of copyright issues, though using either to support development work should be fine. However, I am not a lawyer. Someone should ask the WMF legal dep't before any action is taken on these. Pashley (talk) 20:28, 5 July 2013 (UTC)
As I understand it, the limitation is that we cannot have any of it on the wiki page itself, so it's more of a problem for the in-wiki map. Externally on the PoiMap2 webapp it should be fine? It still is a rather grey area though, and we do use OpenStreetMap as the default and I see additional tile providers as just another option for the user. But I'm not a lawyer either.
The Bing Basic Map is limited to 125,000 transactions a year. Don't think it's much better though :) Check out a comparison of the maps.
Don't think we'll be using Google translate anywhere - just that Joachim points out that Google amusingly translates Wikivoyage as Wikitravel - both German to English and English to German. -- torty3 (talk) 07:06, 6 July 2013 (UTC)
Looks like we will need to sit and wait. We could use tiles from Toolserver but it loads very slowly. It is in the middle of moving to WMF Labs, although they are focusing on development and not production-ready tile rendering. w:de:User:Kolossos and others have very promising plans, where plain map tiles are used and labels are applied as layers [35], which makes it easier to label maps in different languages. See article in German and in English. -- torty3 (talk) 10:36, 7 July 2013 (UTC)

Legal issues[edit]

Following discussion about legalities, I did more reading which has given me quite a headache...

  1. For starters, to be completely safe - probably no usage of Google Maps at all. This includes coordinates and boundary sets, ie we cannot even use coordinates derived from Google Maps, especially if we want to work more closely with OSM. They are reluctant to import Wikipedia coordinates as they feel the data has not been vetted and attributed properly. All future marking and tracing should be done over OSM datasets.
  1. Secondly, there are questions of what makes a derivative database - especially since we may be potentially pulling in tons of geocoded results from OSM. This follows on from their new Open Database License which covers data compared to the CC-by-SA-3.0 license for content. A further license conflict may occur with Wikidata which is CC0 - public domain works. I reckon that Wikivoyage combines enough information with the map data to be considered a Produced Work. But we may need stronger attribution. -- torty3 (talk) 10:23, 7 July 2013 (UTC)

Special:Nearby on Wikivoyage?[edit]

Swept in from the pub

Hi en Wikivoyagers!

The WMF mobile team recently built a new feature for Wikimedia mobile sites (and soon the regular desktop sites, too): Nearby, which shows you a list of all the places and things near you that have Wikipedia articles. We're populating this list by harvesting the geo-coordinate data from articles that include the Coord template. It seems like Nearby could be a great feature for Wikivoyage, too, especially on mobile. However, I notice that you don't currently use the coord template to mark geo-coordinates in Wikivoyage articles, and instead rely on {{geo}} to supply this information.

My question is, would you be interested in a Nearby feature on Wikivoyage? If so, the technical framework is all built; all that's missing is the coord template. So, if you go to en.m.wikivoyage right now and navigate to Special:Nearby, you'll see that the feature exists, but no articles show up. If you'd like to see some Wikivoyage articles there, please consider switching out your geo-coordinates templates :) If not, let us know and we'll disable the Nearby link from the Wikivoyage mobile view so the empty feed doesn't confuse people.

One last thing: it would be good to get the other language Wikivoyage communities in on the conversation, too, since they'd also have to switch their templates to get Nearby to work for their projects. Is there an International travellers' pub or some cross-Wikivoyage noticeboard where I can post this to let them know? Cheers, Maryana (WMF) (talk) 20:21, 9 May 2013 (UTC)

Meta:Wikivoyage/Lounge is where we coordinate. But I'm a little confused. Is this Nearby feature really entirely dependent on the presence of a particular template, with a specific hard-coded name? Must the template have some sort of specific functionality that {{geo}} doesn't, or need it merely exist? Would it work to redirect {{coord}} to {{geo}}? LtPowers (talk) 20:36, 9 May 2013 (UTC)
I would definitely like to see this feature implemented here. But I'm also confused about the difference between using {{coord}} and {{geo}}—just the name? --Peter Talk 20:38, 9 May 2013 (UTC)
It looks like (on EN at least) we're going to have to do something sooner rather than later with the co-ordinates for our articles in order to make them fit with the new TOC (see above) anyway, so perhaps we could do both at once? Either way, this does sound like a really nice feature, although like LtPowers and Peter before me, I'm a little confused about the difference between the 'coord' and 'geo' templates. --Nick (talk) 20:42, 9 May 2013 (UTC)
My understanding is that it's not so much the specific template that matters, but the invocation of the parser function which stores the geo-coordinates and exposes them through the API. That parser function, {{#coordinates:}}, is available on this wiki as well, and documented at mw:Extension:GeoData. It should be possible to make that work with any template. If I'm wrong, I'm sure someone from the mobile team will correct me. :-)--Eloquence (talk) 00:42, 10 May 2013 (UTC)
This is also something I'd really like to see. If it means we have to change our Geo template, so be it. I do think we need to change the way that is used, anyway. Wikipedia's solution of having a popup map works well, or even the dynamic maps that are currently under experimentation. But the separate Mapsources page is just tedious.
Also, I'm presuming the feature just lists nearby articles at this stage. It would be great if we could also list nearby listings. It might be much more helpful if a user knew there were cafes or hotels nearby, rather than entire cities. We could have two separate "Nearby" lists: Destinations, and Listings (or even subdivide further into Attractions, Eateries, Accomodation, etc). It could then be integrated to bring up the listing text and display the dynamic maps. The possibilities are endless! JamesA >talk 01:46, 12 May 2013 (UTC)
Yes, this is an important point. I started drafting the needed functionality here. Also, we need to decide upon new types of points: I can think of food, museum, transportation, hotel - thoughts on the full list? My vision is that every destination page should have a primary coordinate for the city itself and a bunch of coordinates for different POIs e.g. {{#coordinates:10|20|type=food|name=Joe's Pizza}}. If the number of WV-related point types will be short enough (but sufficient), we can whip up a nice UI to switch search between them. Also, we could track every POI's location on page and allow people to go directly to it from search results, e.g. <span id="Joe's_Pizza">{{#coordinates:10|20|type=food|name=Joe's Pizza|anchor=Joe's Pizza}} Joe's Pizza is the most kick-ass eatery in Villageville - what else did you want for a town with a population of 168?</span> Thoughts? MaxSem (talk) 17:26, 14 May 2013 (UTC)
Keep in mind, that functionality would need to be pulled from each instance of {{listing}} on a page (or the corresponding xml redirects), which already have coordinate attributes.Texugo (talk) 18:43, 14 May 2013 (UTC)
Sounds good, Max. In the short-term, if the WMF wants to implement Nearby just for destinations, that'd be great. About listings/POIs, we have categories/headers that are set in stone, which may come in handy to categorise nearby POIs. Check any article and you'll see them: See, Do, Eat, Drink, Sleep, Contact, etc. That functionality will be built into our new listing template solution which is due to be deployed by a bot in the next week or so. JamesA >talk 11:40, 15 May 2013 (UTC)
If the point about {{#coordinates:}} is correct, then most articles should now be ready for the Special:Nearby function after editing the {{geo}} template. It's currently disabled per [36], so I can't quite test it and I suppose we have to submit another request to re-enable it? -- torty3 (talk) 15:21, 20 May 2013 (UTC)
Personally I'd like to see an additional feature for Wikivoyage which adds a nearby button to each individual page. When clicked it would allow you to see a map of where everything mentioned in the page is. I think the Special:Nearby page itself should list nearby places in a similar way that Wikipedia does. Sometimes, especially when backpacking it is highly useful to know what places are nearby that you could go visit. Jdlrobson (talk) 22:10, 3 June 2013 (UTC)

Icon priority[edit]

Is there any way to control which overlapping icons will be displayed on top on the map? I ask because on the map for Valle de Cocora, the sleep listing is raised above the #1 see listing, which is far more important. --Peter Talk 23:17, 19 July 2013 (UTC)

By default, marker images index is set automatically based on its latitude. I have changed the order: The markers now appear in the order of their numbers. Number 1 at the top. - Joachim Mey2008 (talk) 05:23, 20 July 2013 (UTC)

More data?[edit]

I ran across Global Database of Events, Language, and Tone (GDELT) in another context, wonder if some of their data might be useful here. Pashley (talk) 13:56, 20 July 2013 (UTC)

Picking and choosing features[edit]

In comparing the dynamic and static maps at Virgin Gorda, I wonder how we can better pick and choose the features (in this case labels) that we want to display. For this guide, the most important labels are the names of bays, islands, and the one major road. Mapnik and Tourism do show the island names, but not the bay names. Do I just need to add them myself on OSM? Then how do I make sure that they display on the layer I want to use in the article? --Peter Talk 06:32, 22 July 2013 (UTC)

I made the place labels visible for the Wikivoyage layer, and they will render accordingly depending on zoom levels. Bay names were not shown because they weren't in OSM and should be added, but I can't find a clear way of how to mark them. Policy seems to be create an area for the bay and tag it as natural=bay. The major road name isn't in OSM either, so I've just added it in. One big problem with the Wikivoyage/Tourism Cloudmade layers is that they don't update their map database very quickly, maybe even a couple of months behind altogether compared to the almost instant Mapnik and Mapquest Open layer. -- torty3 (talk) 12:20, 22 July 2013 (UTC)
Is there a way to specify at what zoom level the features will display? Right now the Virgin Gorda map is set to zoom=12, which makes sense for the overview, but the island names are visible only at zoom=13 (in the Wikivoyage layer—they display at zoom=12 in the Mapnik layer), bay names at zoom=14. I'd love to bump both of those up one. --Peter Talk 06:09, 1 August 2013 (UTC)

Wikivoyage:World cities/Large[edit]

The linked page lists 100 of the world's largest cities plus a few others that are important for tourism. The last column shows which ones have dynamic maps, and most do — nice going, guys & thank you. However, some don't; you can get a list by sorting on that column.

Would anyone care to take on a small project & fix this? Pashley (talk) 16:02, 23 July 2013 (UTC)

Done (use GeoMap). -- Joachim Mey2008 (talk) 16:52, 23 July 2013 (UTC)
Bravo & thanks. Pashley (talk) 16:49, 28 July 2013 (UTC)

Smaller icons, mapping selected listings, autonumbering[edit]

First off, let me just say that you guys ROCK. You are doing a brilliant job and are creating perhaps the most outstanding feature of Wikivoyage. I cannot really express how excited I am to see what you are doing and try it out in practice. That's simply wonderful!

I started tooling around with dynamic maps in Dresden and, once I discovered how they work, have created a small one for the Altstadt already. Well done me! But I didn't come here to boast but rather ask about three features I could use:

  1. This map was linked from the Pub sometime ago and I see it features smaller icons and refers to an "x" rather than "w". I could very much use the smaller icons for my small maps and was wondering if there is any way of forcing the Mapframe template to display the "x" map (or just smaller icons in any other way)
  2. Autonumbering - it was mentioned at the Pub sometime ago. Is there any way to have my listings autonumbered on a map, or do I have to number them manually using the Template:Poi?
  3. Displaying only selected listings / listings from one section / one type - Dresden is a tricky city (which is why I chose to try out the maps there), as it has quite a lot of POIs, but they are either crammed together on a very small space or spaced very far apart, so one map just won't do, at least not to give the readers a good introduction to the parts of the cities. I would love to have dynamic mini-maps for small parts of the city centre like the Altstadt, perhaps detailing only the "See" or "Do" listings, and afterwards some larger maps with all types of POIs (e.g. one for the centre and one for the non-central POIs). Is there any way I could do this using dynamic maps?

I also see you are now working on a new type of listing template that would include all the stuff that the dynamic maps need and could be used instead of Template:Poi. Is there any chance it could be deployed anytime soon?

Thanks in advance for helping me get the most out of dynamic maps. I am a huge fan of your work! PrinceGloria (talk) 19:21, 24 July 2013 (UTC)

The main issues blocking the new listing template now are the print and mobile versions, and I will need to fiddle with the settings to see whether autonumbering will work everywhere. I think the Poi template could be reserved for in-text items rather than anything else. Time-wise, probably by the end of next week. Note that all {{listing/sandbox}} will then have to be changed back to the normal 'see'/'do' templates.
The 'x' version is for development only where Joachim can test issues without messing anything in the main site, like font type/icon size, so I think we will just have to wait a little bit longer (not any more) till he rolls it out to the 'w' version. Personally I would also want the symbol colours to change to something like in File:District_Map_of_Sentosa.png, because the blue for 'see' and grey for 'do' are too dull and blends into the map.
Detailing only 'See' and 'Do' listings would be pretty nice. I don't think there will be more than one map on a page though, there needs to be unique ids and stuff.
I haven't gotten around to writing a guide yet, but hey, you and at least four others figured out how to use the dynamic maps :) Should start a skeleton soon, and the more difficult bits are probably images and boundaries. Oh and most important of all - licensing issues: using OSM coordinates from GeoMap and Geobatcher should always be used over Google Maps. -- torty3 (talk) 06:10, 25 July 2013 (UTC)
Thanks for replying Torty, I adore what you're doing here and the fact that you took the time to address my concerns in detail and explain it all to me. As concerns you assumption that there won't be more than one map per page, I am just saying that by trying to apply the dynamics map to the Dresden article I have just found that it would be very worthwhile to be able to. Dresden is, on the one hand, a very compact city, so districtification would be adding unnecessary complication for the tourist, but then there are areas rife with POIs (like in the Altstadt, where a single building can have a few POIs), and then quite many POIs at a significant distance from each other.
Trying to fit all POIs in one map at a time would result in hopeless overlapping and little readability. Basically, it would be an undecipherable mess in the centre with rings of scattered POIs around it. I figured out that it would be the best to introduce each district separately, focusing on the "core" POIs (see and do), and only then add a full-scale map with all of the POIs at once for users to be able to have an overview once they figured out how Dresden works, and even that seems questionable to me, as it will still look messy and be of little value. People will need to zoom in to get a good idea of what's up in the centre, and would probably be better served if the general full-size map will not feature the clutter in the centre but just a few key POIs and all of the POIs farther from the centre. If you're still following my convulted writing - I believe Dresden, and many articles like that, will need more than one map.
I'll hold off with adding further map listings until next week, when hopefully the new listing template(s) will be rolled out. I will be more than happy to contribute to the guide as I will be working on deploying the maps, sharing my experiences and helping explain how to do it (hopefully correctly and legibly). PrinceGloria (talk) 06:40, 25 July 2013 (UTC)
It'd be good if the user themselves could open a dialogue on the map and select which types of listings they wanted to display. That way, they can choose whether they want to see everything, just See and Do, just accommodation, etc. James Atalk 12:47, 25 July 2013 (UTC)
Yep, has been on the to do list for a while. And should be relatively easy to set up compared to the other bits PrinceGloria is suggesting. I understand and actually agree with many of your points, and I seriously hope there aren't going to be articles with more than 100 listings, but I was referring more towards the number of technical hoops we have to jump through to set such maps up. How would we select which listings to show for one. Maybe set a range of the numbers of the listings? Or perhaps put in a radius factor to only show listings inside/outside that circle? That's quite a lot of work, though Joachim (who really deserves most of the credit :) should weigh in here, whether in German or English. -- torty3 (talk) 05:46, 28 July 2013 (UTC)
I believe the "range of numbers" thing might be easier for the time being, but it would be the best if Joachim could actually drop us a line on that. I am fine with German, my attempts in writing in German may be a source of endless amusement but I believe I understand it well. Joachim, kannst Du uns bitte bewusst machen ob das eigentlich moeglich ist?
I firmly believe we shall have >100 listings per article. I raised that issue at the Pub, stating that if we want to have continuous numbering across sections, we would need to keep listings to a 10-piece maximum per city/district, and that was refuted as impossible. I am now doing a relatively minor (as a tourist destination) city of Chemnitz, and I guess when I am done I will have crossed the 100 mark. I am all for separate numbering per each section.
I also noticed several issues:
  1. When there is italicization or bold type (the latter one accidentally left out, as it is not needed) left out in the POI name, the listings editor cannot access the listing
  2. Umlauts and other special characters seem to confuse the listings editor at times
  3. Template:Mapframe apparently only allows one call per article, while I need at least two for cities with a densely-packed centre and then further POIs spread out across a large municipality
Mit freundlichsten Gruessen, PrinceGloria (talk) 06:51, 28 July 2013 (UTC)
A dynamic map will never replace a classical drawn map. You should not even try. Show in 'Mapframe' simply the most interesting part of town on a large scale Dresden. For other areas, a link is perhaps sufficient [Map of Dresden-Neustadt]. For individual objects you can simply click on markers in the article.
The maximum number of POIs is now 999. A automatic separate numbering for each section is also possible. In my lab, I have just finished a version including "marker clustering" [37]. Maybe that solves the problem of overlapping? The development of the program is not a problem. For example, the selection of individual types of marker (see, do, etc.). But I think you can already use the program in its present form. -- Joachim Mey2008 (talk) 11:05, 28 July 2013 (UTC) (Listing editor, auto numbering and Mapframe are User:Torty3's part.)

I know Mapframe only allows one call per article, which is what I meant by having a unique id. Just think of it this way, each time an article with a Mapframe is loaded, this is the equivalent of opening one article and one webpage linking to [38]. If you want say 5 different Mapframes, that is the same as one article and five different tabs linking to the server, which also reads the article five different times when each tab is loaded. This is manageable but not good practice.

How about coming at this from a different angle. What if it was easier to create static maps from the dynamic map, would that be better? This would maintain one main dynamic overview map, and you could create static maps for the rest.

Continuous numbering is used because it's difficult to match the numbers on the wiki to the map otherwise (unless JS is used), but if I had to pick between manually inserting a map number and continuous numbering, I pick the latter every time. @Joachim, so automatic separate numbering for each section is possible? Will there be issues with the generic listings having the same number? Like if something in Understand has the green 1, what will the other number in Connect get? Or is there one running number for the green listings only? If so, I could probably adjust it straightaway.-- torty3 (talk) 15:28, 28 July 2013 (UTC)

For the listing editor, you probably missed the Pub update, but check over at Wikivoyage:Roadmap/Improved editing interface. Did you notice which special character exactly? -- torty3 (talk) 15:28, 28 July 2013 (UTC)

Mey2008, or rather Dear Joachim,
The program is just BRILLIANT as it stands already and I gladly use it. It is one of the best things about Wikivoyage. HUGE thanks to you and everybody involved. There is no doubt you've done a marvellous work, and any requests for extra features are not meant to overshadow the appreciation we have for the existing version.
I am a spatially-oriented person and to me, maps are absolutely necessary to figure out the place in my head. I believe an article should have as many maps as needed to correctly let people visualize the area, distances and locations of POIs with relation to each other, the districts, the main streets, other transit infrastructure etc. I love guides (both print and online) that have minimaps at certain sections that correspond to the huge map somewhere else in the guide. The large map is great for many uses, but when you are deep into a particular subsection, it is best to be able to read and glance at a very focused map at the same time.
I further explain why I wanted to use dynamic maps for that in the section of my reply addressed at torty3, below.
Marker clustering as you've shown is just brilliant, especially the feature that shows the outline of the area covered by a given cluster with the POIs in the corners. It is one of the best POI clustering solutions I've seen.
That said, I am quite worried it might not be a very good solution for local maps. Sometimes, POIs are really close together, but do not overlap - a user should be able to see this without zooming in too far. This would require for the user to remember where they were in the zoom level where they see a cluster, zoom in to discover what the cluster is for, and zoom away remembering where that was. Pretty complicated and doesn't help understand the map at first glance.
What I was thinking we might use is a solution that displaces the "POI flag" (the shape with the number) from its lat/long-defined location, but leaves behind a thread or an arrow to the correct position. That way, we could have many semi-overlapping or even fully overlapping (having the same geographic location) POIs on a map that would be clearly visible. One challenge I see is potentially overlapping the important elements of the backgroundmap, but this happens currently anyway.
Would you believe the above would be possible, or would it require too much effort?
HUGE thanks again for the great work you do! PrinceGloria (talk) 16:49, 28 July 2013 (UTC)
The new Geomap looks purrty, but when I try to use it from Safari, all I get from any search is "TypeError: Result of expression near '...}.bind(this))...' [undefined] is not a function".
torty3
It would be brilliant if we could generate a static map from a dynamic map automatically and easily. I want to use the dynamic maps for "local area minimaps" because they get updated automatically and one does not need to do a screenshot and reupload it to Commons everytime a POI is added or modified (e.g. the order rearranged). I can do it, but how about all those users who are not really that well-versed in Wikivoyage and would just like to add a tiny bit to a guide, e.g. a new POI?
If "behind the scenes" a set of "screenshots" positioned at a given place, with set dimensions and zoom level could be generated from a single mapcall and then dynamically inserted as static images (rather than fully functional dynamic map frames), it would be even better. I was actually to complain that the controls, copyright bar et al. for the dynamic map are far too large for a minimap I feel the need to be used for small areas rife with POIs. A static map without the controls, but dynamically generated using the current version of the article the user is viewing, would be a much better solution.
BTW, I know it is a hard nut to crack, but if we could add a new listing to a subsection rather than just the top-level sections, it would be just brilliant.
I don't think I did miss the update or I fail to understand which update you meant. The problem occurred this morning, one/two hours after you posted your last update to Wikivoyage:Roadmap/Improved editing interface. It was ü (U mit Umlaut). And also any apostrophes, like those used for italicization. Plus two multi-word POI names with similar first two words, like "Holiday Inn" and "Holiday Inn Express", still get confused (I reported this earlier).
PS. After checking the new clustering feature with a few existing map with many POIs, I believe the clustering has too large catchment areas - it makes maps unintelligible. It would be good if it activated once the POI icons start overlapping, but otherwise would not. There is no point in clustering two POIs on the opposite sides of the street that do not overlap and are perfectly visible at most zoom levels. Once the user zooms out and the icons start overlapping is when clustering would come in handy. Is there a possibility of limiting the clustering catchment area? BTW, the cluster icon could then be made smaller as well.PrinceGloria (talk) 05:22, 29 July 2013 (UTC)
Thanks for the detailed feedback. That is what a programmer needs ;-). The clustering can be adjusted. But I have to shrink the cluster symbols first. That takes some times. 'OverlappingMarkerSpiderfier' (I do not know the English word), I have already implemented [39]. -- Joachim Mey2008 (talk) 06:09, 29 July 2013 (UTC)
Wooow! The "Spiderfier" is brilliant! Could we have that instead of clustering (i.e. the spiderfier displays rather than the cluster symbol) for the time being and see how it works out? PrinceGloria (talk) 06:16, 29 July 2013 (UTC)
Thanks for the feedback and comments, it really is much appreciated. It's just easier to separate the dynamic maps and listings editor discussion, or we'll have to keep whispering and I can address issues there rather than here. -- torty3 (talk) 10:28, 30 July 2013 (UTC)

I don't think it's an improvement. Now a lot of user interaction is involved, while before all the listings just showed up as-is. It's quite confusing and makes the map a bit into a puzzle. Globe-trotter (talk) 06:41, 29 July 2013 (UTC)

I agree with Globe-trotter. Clustering looks better, but hurts usability. I'd rather see them overlap (and still be able to hunt a bit with the mouse using hover text) than have to keep guessing where to zoom in to hunt for the desired numbered listing. --Peter Talk 21:39, 29 July 2013 (UTC)

Automatic separate numbering[edit]

Separate automatic numbering for each section I have enabled in my lab version. But general listings (green icons) are numbered continuously [40]. -- Joachim Mey2008 (talk)

Ok that's excellent, I will go change the sandbox and CSS now. -- torty3 (talk) 07:58, 29 July 2013 (UTC)
After a short test I put the new version online. Seems to work. -- Joachim Mey2008 (talk) 09:15, 29 July 2013 (UTC)
Whoops, we just got a brand new shiny toy and I already managed to break it... For some reason in the Leipzig article the only two "Buy" POIs BOTH display with a "1". Please see the map above the Buy section. PrinceGloria (talk) 14:48, 30 July 2013 (UTC)
The following logic has been agreed: All sections are numbered separately. Special templates {{see|, {{do| {{buy| etc. may be used only in appropriate sections. Only the general template {{listing| may be used in all sections and is numbered continuously. - I have modified the section accordingly. Please refresh the page (depending on browser settings) two times again. Thus, the change is visible. -- Joachim Mey2008 (talk) 17:44, 30 July 2013 (UTC)

Marker clustering[edit]

I will revise the function yet. Clustering as little as possible, and 'spiderfier' [41] in fact of completely overlapping points. This will take some time. - Joachim Mey2008 (talk) 04:19, 30 July 2013 (UTC)

Is it possible to turn off the clustering function before it gets revised? PrinceGloria (talk) 05:52, 1 August 2013 (UTC)
I don't really see the advantages of clustering. When printing, you can't see the individual listings, so it essentially makes the map worthless. Globe-trotter (talk) 12:43, 1 August 2013 (UTC)
If no other opinions are, I will reset the function tomorrow. -- Joachim Mey2008 (talk) 13:27, 1 August 2013 (UTC)
I have locked the clustering for the town-levels now (zoom 15 to 19). -- Joachim Mey2008 (talk) 11:54, 2 August 2013 (UTC)
That's brilliant, Joachim! Would you mind to lock it for levels 14 and possibly 13 as well, I am using them for districtless mid-sized cities (level 15 and beyond is too zoomed-in to cover even the centre of an entire city). Thanks for considering this, PrinceGloria (talk) 15:04, 2 August 2013 (UTC)
I think they should be turned off completely. A user should never have to click random bubbles to find the listing icon they are looking for. This is still a huge problem for a map like that of Virgin Gorda, and even for a simple one like Valle de Cocora. The clustering was brought up as a reason to oppose a star nomination for that article. --Peter Talk 18:48, 2 August 2013 (UTC)
No problem at all. Turned off. -- Joachim Mey2008 (talk) 20:35, 2 August 2013 (UTC)

Geomap update[edit]

Should geomap be updated, now that we are using lat/long within Template:Listing, instead of Template:POI? The copy/paste text should be a more simple:

lat=39.041399 | long=-77.052678

--Peter Talk 07:24, 26 July 2013 (UTC)

In the selection box at the top right, you can choose many formats. Select (*) Lat/Long for the desired type. Tip: Open Geomap always in a separate tab ([Ctrl] key + mouse click left). Then your choice need not always to be adjusted. -- Joachim Mey2008 (talk)
The Geomap was revised. New Layer 'Bing aerial' for OSM low-detail areas and other small improvements. -- Joachim Mey2008 (talk) 11:16, 28 July 2013 (UTC)
Has that use of Bing been cleared by the WMF legal department? If not, I'd say it must stop. Pashley (talk) 13:14, 28 July 2013 (UTC)
I have reset satellite images to Mapquest aerial. Those used Wikipedia as well. -- Joachim Mey2008 (talk) 14:23, 28 July 2013 (UTC)
Does that use comply with http://info.mapquest.com/terms-of-use/?
My understanding of the law is that you cannot copyright data, so we can use information from anywhere but then it gets complex — the arrangement, organisation, presentation or access methods can be copyrighted in some jurisdictions, names like Bing, Google or Mapquest are trademarks, and some access methods may be patented — so we need to be really careful about how we use it.
Moreover, the law is complex and varies from country to country, so I think we need to check with the legal department about any use of copyright material. Pashley (talk) 14:47, 28 July 2013 (UTC)
Probably best not to use Bing Maps, but Mapquest Open (OSM/Aerial) is OK to use [42], which is not the same as the main Mapquest link you are quoting. The main concern is attribution, and we have followed Wikipedia's lead in terms of how it has been phrased [43], ie Data, imagery and map info provided by Mapquest. That said, if you could follow up with legal, it would be great. -- torty3 (talk) 15:02, 28 July 2013 (UTC)
The latest revision, using our listings template format as the default "lat/long dropper" is really fantastic! --Peter Talk 21:40, 29 July 2013 (UTC)

Hi Joachim, I've added a link to GeoMap in the listing editor, but is it possible to input parameters into it? If the name/address is filled in then it could link to http://maps.wikivoyage-ev.org/w/geomap.php?location=Name&lat=50.03&long=120.00 where the latitude and longitude comes from {{geo|50.05|120.00}}. and acts as a location radius to search in, ie return an address close to that latitude and longitude? -- torty3 (talk) 10:54, 1 August 2013 (UTC)

The parameters of the 'GeoMap' are: lat, lon (not: long) and zoom. I could insert the parameter 'layer' quickly. I'm using a new search module since yesterday. Searching within a given radius should be possible. I need some time to test this feature. You can insert the parameter 'location' already for testing purposes. -- Joachim Mey2008 (talk) 13:04, 1 August 2013 (UTC)
The link to GeoMap has been added, but [44] leads to a grey map when it didn't before. Adjusting the map? Thanks in advance, looks like everything is coming together. -- torty3 (talk) 13:03, 7 August 2013 (UTC)
Entschuldigung! I have mixed a couple of brackets. Now I've got it sorted. Hopefully correctly? -- Joachim Mey2008 (talk) 14:55, 7 August 2013 (UTC)

Meeting myself coming back[edit]

When I use GeoMap to geo-cord the Centre of New Zealand it gives me "lat=-41.27287 | long='''-186'''.70048" instead of lat=-41.27287 | long=173.29952

and then clicking the resulting clickable icon (understandably) generates an error of "Incorrect longitude"

  • 2 The Centre of New Zealand. A short walk up a hill close to the city centre and reachable from the Botanic Garden (where the first game of Rugby was played in New Zealand). Good view from the top and an interesting walk through exotic and native vegetation to get to the Trigonometrical Point and Marker at the top.

If it were done right, no error is generated

  • 3 The Centre of New Zealand. A short walk up a hill close to the city centre and reachable from the Botanic Garden (where the first game of Rugby was played in New Zealand). Good view from the top and an interesting walk through exotic and native vegetation to get to the Trigonometrical Point and Marker at the top.
You've turned the globe and have exceeded the 180 ° meridian. That's what these values. Bad foul. Back quickly. I have it written down. I will install a lock, so that it is no longer possible. - Joachim Mey2008 (talk) 17:57, 6 August 2013 (UTC)
Thanks, Joachim, that'll do the job. --W. Franke-mailtalk 14:44, 7 August 2013 (UTC)

Green flower for "Do", gray dot for unspecified listings[edit]

I know I have been making a lot of comments and requests recently, so I hope that you won't take it the wrong way - or think that I am petty... But when I look at the maps with different colours and icons for each type of listing, I can't help but think it might be better to use the green "flower" thing for "Do" listings, while leave out the anonymous gray dot for the "unspecified" listings (those described using Template:Listing, rather than a specific one such as See, Do, Eat, Sleep etc.). What do you guys think? PrinceGloria (talk) 08:20, 29 July 2013 (UTC) PS. By the way, we do not seem to be using some eye-catching colours, such as bright red. Is this on purpose?

Shapes and colors of the icons may need a revision in fact. The current colors and shapes are the smallest common denominator of the five participating languages ​​versions. Any changes will therefore be somewhat difficult. The taste of colors is very different. -- Joachim Mey2008 (talk) 04:33, 30 July 2013 (UTC)
Thank you for reminding me that we're not the only ones using your brilliant map! Is there a centralized place we could discuss the colours, and functionalities, with other language version communities to avoid pulling in opposite directions each? PrinceGloria (talk) 05:54, 30 July 2013 (UTC)
Let's bring that up at the next summit, which comes up in a couple days. Lots to talk about there, even just from this one month! --Peter Talk 06:13, 30 July 2013 (UTC)

Did anything ever come of this discussion? I think this is a change worth moving forward with. –Thatotherpersontalkcontribs 04:41, 8 February 2014 (UTC)

We should certainly consider our colour blind readers and those who may be reading on monochrome screens such as e-readers. The icons need to be small but still hold a numeral of up to 2 digits while remaining visually distinctive in monochrome. Shapes to consider are
  1. our current square
  2. a triangle
  3. an inverted triangle
  4. a pentagon
  5. an octagon
  6. a lozenge or diamond
  7. a rectangle with the two short sides aligned vertically for our sleep listings (reminiscent of a bed)
  8. a disc --118.93nzp (talk) 05:33, 8 February 2014 (UTC)
Are you suggesting the pool of icon shapes needs to be redone from scratch? I was just interested in swapping two icons, so the eye-catching green flower would be in the Do section and the plain gray circle would be for generic listings like Connect and Cope.
Thatotherpersontalkcontribs 10:13, 8 February 2014 (UTC)
Where may I see the current pool of choices, please? An URL or a diff would be helpful... --118.93nzp (talk) 04:46, 9 February 2014 (UTC)
I'm referring to the icons that show up on the dynamic map itself, not the squares that display next to the text of the listing. All seven types (See, Do, Buy, Eat, Drink, Sleep, Listing) can been seen on the dynamic map at Ottawa. –Thatotherpersontalkcontribs 10:26, 9 February 2014 (UTC)
Yes, I thought you were talking about the dynamic map, but what confused me is that I have never seen a green flower - only a green hexagon for the generic listing and a grey disc for the "do" type listing.
It is a pity that the icon in the text can not match the shape on the map, but Joachim has written that is not technically possible. --118.93nzp (talk) 11:56, 9 February 2014 (UTC)
That green shape is what's being referred to as a flower. I don't mind the markers next to the listings all being square, but the map display would make more sense if the plain gray circle was the icon for miscellaneous listings rather than major tourist attractions from the Do section. –Thatotherpersontalkcontribs 03:09, 10 February 2014 (UTC)
I agree, but then there may be a tradition that we don't know about in some other language version... --118.93nzp (talk) 06:16, 10 February 2014 (UTC)

(indent) The flower does sort of have more of a "Do" feel, but I don't like the green. I'd prefer purple or lavendar. It has a similarity to the blue of "See" (which "Do" is associated with), is an unused color, and is also an actual flower color. ChubbyWimbus (talk) 06:53, 10 February 2014 (UTC)

Purple is the color we traditionally use for Drink listings, though the dynamic map code seems to ignore those conventions. Powers (talk) 14:26, 10 February 2014 (UTC)
Colors of the markers were originally identical with the traditional colors of the static maps [45]. Variations resulted from suggestions of other language versions. At that time there were no dynamic map in the English language version. -- Joachim Mey2008 (talk) 06:58, 12 February 2014 (UTC)
Do we have a record of why those changes were suggested? Did anyone specifically request the gray dot for "Do" listings? –Thatotherpersontalkcontribs 07:18, 15 February 2014 (UTC)

Mitigating the additional download times for readers[edit]

As someone who loves maps I'm excited by the possibilities that are opening up with the wonderful work being done with dynamic mapping here.

However, we also need to give some thought as to how we can give a choice to our readers on slow or expensive connections to avoid the massive data download hit associated with embedding dynamic maps in articles.

As I write this our policies clearly allows using images hosted at Commons in articles and, as far as I know, linking them via caption text to primary external sources.

As a stopgap until I know of better technical methods, I've experimented here with a lower bandwidth png and suitable hyperlinked caption text. However, when the Poimap2 is opened after clicking the caption, it no longer shows the automatically generated and numbered POI icons (presumably because it is missing the parameters provided by the {{Mapframe}} template). How do I fix this, so the map opens in a new window and does display the automatically generated and numbered POI icons, please? --W. Franke-mailtalk 14:13, 6 August 2013 (UTC)

PLEASE do not do this:
  1. The point of the dynamic maps is that they update automatically and provide more customization options for users, both of which are negated by using screenshots instead.
  2. I'm not sure what data hit you're talking about - with an empty cache Nelson (New_Zealand) downloads 674kb of data using your screenshot approach and 795kb using dynamic maps according the Google page tools network monitor. However, since much of the dynamic map Javascript is shared, it is only downloaded once and then re-used across pages.
-- Ryan • (talk) • 14:56, 6 August 2013 (UTC)
Your response does not address any of my concerns, Ryan.
1)a) I understand the point about the automatic update from listings (if you'd actually examined my edits at Nelson, New Zealand you'd understand that I fully understood the wonderfulness of this.
b) When they click my static map caption, the dynamic map is (except for the missing POI icons that I am requesting help on) exactly the same as my previously embedded dynamic map - except that it is full screen rather than half-screen. It has exactly the same "customization options for users".
2) That's not the correct measurement you're using, Ryan and certainly does not allow for latency. Using a friend's tablet and a slow mobile connection, the "static image of a map version of the Nelson article" finishes loading in 6 seconds; using the "dynamic map version of the Nelson article" took 68 seconds. These loading times obviously varied depending on the local mobile phone network loading, but the "dynamic map version of Nelson" always took an order of magnitude longer. Try it yourself on a slow connection - but don't use 3G or 4G!
Your point about Javascript is well made.
I do agree that if there were not this enormous performance issue, personally I'd love to use dynamic maps everywhere there is not a better (lovingly) hand-drawn map. However, one of the Wikimedia foundation's objectives is to make its products more accessible in third world countries with slower/expensive connections.
Now, if there is someone who could help me with the correct hypertext syntax, we can progress... --W. Franke-mailtalk 15:24, 6 August 2013 (UTC)
If you would like to experiment please do so in userspace, not in mainspace. Replacing dynamic maps with screenshots is not a viable option to implement sitewide, and furthermore if your friend can download 674kb in six seconds then the issue is not a bandwidth problem. -- Ryan • (talk) • 15:38, 6 August 2013 (UTC)
Have you now been able to do some proper testing, Ryan? There is indeed a significant loading time hit with a dynamic map displayed as these figures show: [46]. Joachim knows this - hence his good advice below. --W. Franke-mailtalk 22:58, 8 August 2013 (UTC)
@W.Frank: Please only use the mobile version for mobile devices. The link can be found at bottom of each article. Pages then load in a moment. - Joachim Mey2008 (talk) 18:21, 6 August 2013 (UTC)

Template:Annotated image from Wikipedia[edit]

Can we import the Template:Annotated image from Wikipedia so that clicking anywhere on my "stopgap png" would open the dynamic map? --W. Franke-mailtalk 14:30, 6 August 2013 (UTC)

Performance test[edit]

I just did a performance analysis of the Tokyo/Roppongi article with Yslow, and here are my findings: [47]. As you can see, base page takes 1265kb, and map takes 859kb, of which 535kb should not be loaded, so that's down to 324kb when the bug is fixed: 20% of the page's weight. Nicolas1981 (talk) 01:36, 9 August 2013 (UTC)

Destination link opens inside the map's IFrame[edit]

Steps to reproduce:

  1. Open Tokyo/Roppongi.
  2. Click on the "Destinations" button.
  3. Neighbooring destinations appear. Click one, and then click the link that appears.
  4. Result: The article opens within the IFrame.

Of course, the page is unusable because the map frame is too small. Is there a way to avoid this by opening as the whole page, or as a new window?

Cheers! Nicolas1981 (talk) 05:39, 9 August 2013 (UTC)

I have bookmarked for program development. Workaround: Hold down the Shift key while clicking on the 'Destinations' link. -- Joachim Mey2008 (talk) 06:15, 9 August 2013 (UTC)

Toggle[edit]

For the ""Destinations" button, would you change the button so that each press toggles between displaying markers of nearby destinations and the original view/not displaying destination markers. I realise that the same effect can be achieved by changing the "radio buttons" in the top, right hand corner "layer menu", but most of our readers are casual and may never find this feature.

I'd make the same "toggle" request for the "Show all markers" button, so it would toggle between that (usually low zoom)option and the zoom level of the original dynamic map. --W. Franke-mailtalk 15:22, 10 August 2013 (UTC)

Missing images and missing maps[edit]

Swept in from the pub

Have been look around preparing for the talk and not only are there a lot of pages missing images many are also missing maps. Looking at this previous destination of the month and IMO it would be a huge improvement to have a map showing where Jiuzhaigou_Nature_Reserve is just in case I want to go there. All articles should have a map.Travel Doc James (talk · contribs · email) 03:36, 1 August 2013 (UTC)

What are peoples though of this geohack tool on the toolserver? Hopefully it will move over to Wikimedia labs eventually.Travel Doc James (talk · contribs · email) 04:10, 1 August 2013 (UTC)
For those wondering, here is an example of a map generated by GeoHack. I think it would be better than nothing, indeed. A more advanced tool is PoiMap2, though. The French Wikivoyage has started deploying it on a wide scale, as seen for instance here, even for articles that contain no POI. How about going ahead as well and deploying PoiMap2 on more articles? Nicolas1981 (talk) 06:16, 1 August 2013 (UTC)
We essentially do in the form of the {{geo}} map icon link at the top right of all properly tagged destination guides. But I assume you are talking about displaying it in-article using {{mapframe}}? --Peter Talk 06:25, 1 August 2013 (UTC)
Apparently the Wikivoyage:Dynamic maps Expedition isn't very clear if you came to ask about Geohack here. It isn't suited to travel needs at all, and that's what {{PoiMap2}} and {{mapframe}} are for. I think {{mapframe}} and the listing/sandbox are ready to be deployed site wide as well, not experimental any more, by Saturday if no one objects. Please look at Wikivoyage:How to use dynamic maps for a guide on how to use them.
By the way, when I marked the template as experimental, I really meant it was experimental and while nice, did not expect it to be spread far and wide. Please check the latest Mediawiki:MapFrame.js which patches a pretty serious security hole which I overlooked and should not be in a wide release. -- torty3 (talk) 10:33, 1 August 2013 (UTC)
I remain concerned that the dynamic maps may discourage future hand-crafted maps. Also, I think we should standardize on a rendering appearance for these dynamic maps; the default Mapnik is, IMO, horrible for travel purposes. LtPowers (talk) 13:23, 1 August 2013 (UTC)
In Russian Wikivoyage, we have been using dynamic maps since the moment they appeared, which is about half a year from now. The maps proved to be a very useful feature, because every new article comes with a built-in map. Additionally, they give us an impetus for updating and revamping existing articles. The total number of maps increased dramatically. The travel guides became more useful, which is a good reason to implement this feature as soon as possible.
Regarding the static maps, I personally decided that I would not draw city maps with individual listings any longer, because I simply don't have time for that. I wonder how many people still draw static maps, but I guess that we did not have more than 10-20 new maps since the launch of Wikivoyage. Therefore, our choice is between having dynamic maps or having no maps at all. Finally, from my previous map-drawing experience, I think that it is very useful to have all locations visible on the dynamic map. It helps you in choosing the right area and saves a lot of effort in finding individual places that were added by different users. If anyone still wants to create hand-crafted maps, he/she is welcome to do so. I can make a very long list of places that will benefit from a hand-drawn map, but I don't see a queue of volunteers who would be working on it. --Alexander (talk) 14:47, 1 August 2013 (UTC)
How do you go from "10-20 new maps" in six months to "no maps at all"? LtPowers (talk) 17:24, 1 August 2013 (UTC)
English Wikivoyage has ~28,000 articles. 10-20 new maps in six months means ~0.1%/year. It is nothing. Readers will never find them. We do have several hundreds of city maps drawn in the past, but many of those maps are not updated and eventually become useless. --Alexander (talk) 18:36, 1 August 2013 (UTC)
POI2 looks great and it has already been implemented on at least Travemünde and Roppongi. Dynamic maps are also easier to update which is useful in city and city district articles as they contain stuff like hotels and restaurants which appear and disappear more easily than monuments and parks do. Not to mention that drawing a map in the first place takes longer than just adding a few coordinates (of course that isn't a problem if you're good at drawing maps and love doing it). ϒpsilon (talk) 20:00, 1 August 2013 (UTC)
Static maps do have some advantages over dynamic maps (and thus provide a really good comparison to help us figure out how to improve the dynamic maps), but for the vast majority of bottom-level guides, it's just not practical to keep maps updated by hand. My association with WTP kept me on point for updating Chicago and D.C. maps, but that's certainly slid since. It's also not realistic for us to expect all city, park, district, etc. guides to be illustrated with drawn maps—there is a steep learning curve for producing them, and even after mastering the process, they are time intensive. I don't really intend to keep making standalone static maps, and I plan to replace the years of hard work I've done in district article maps with the auto-generated sort ;)
There are a few issues still being ironed out on these maps, and the relevant discussions are all over Wikivoyage talk:Dynamic maps Expedition, but the big one left is working on the printable version, which is still very Beta. And LtPowers, note that {{mapframe}} supports many layers for tiles, one of which has our own custom built Wikivoyage-aesthetic. (That needs work still too.) --Peter Talk 01:14, 2 August 2013 (UTC)
There have been giant leaps in auto map tile production too over the past couple of years. Tools like maperative, would allow us to replace the hand painted style of maps quite quickly - if that's what we wanted. Tilemill would allow us to build our own style, emphasising features important to the traveller. --Inas (talk) 01:37, 2 August 2013 (UTC)

I must say I LOVE the progress on the Dynamic Maps front and what the guys are doing. I frankly don't see much benefit in "hand-made" static maps over dynamic maps. Dynamic maps have the great advantage that they reflect the current state of the article, so if anything gets added or modified, which it constantly should as destinations change everyday, it will get reflected on the map and what the traveller needs is a guide that is up to date and a map that matches it, not a map that might match it in a few days if a merciful editor with the appropriate knowledge and skills comes round and has the time and interest to do the map. Furthermore, we need to broaden the editor/user circle, and chasing after editors to have them toil away hours by making "hand-made" maps would not be a great way to enticing them to stay.
Just to make sure - I have nothing against hand-made maps, and most of those that I saw were nothing short of brilliant. I do use them and print them out, for one they were great for my recent visit in Copenhagen. It would be brilliant if people continued to make and update them, and more people did them as brilliantly as the current maps were done. But I am just not seeing this as the way to go forward with mapping all of our articles quickly, and I firmly believe each article should have at least one, fully up-to-date map, ASAP.
Let's roll out the dynamic maps and associated template numbering ASAP and work on it together to make it even better. This is what really sets Wikivoyage apart and open so many exciting possibilities (like "Special:Nearby" and such). PrinceGloria (talk) 05:55, 2 August 2013 (UTC)

Dynamic maps are the way to go, the learning curse for static maps is high and they don't update as the content updates. Only a few dedicated editors have taken the time to learn to use a vector program. And all this had to be done off-wiki, dynamic maps can be updated by everyone without needing to download and learn external tools. However, I do think the dynamic maps could look a bit more professional. We should choose one layer and stick with it. I think Mapquest Open looks a lot better than Mapnik and the custom-made Wikivoyage layer, can't we just use that one for all articles? Globe-trotter (talk) 09:11, 2 August 2013 (UTC)
Is there anyway to role them out in a semi automated manner? Travel Doc James (talk · contribs · email) 12:45, 2 August 2013 (UTC)

I don't even know how to respond. The learning curve for creating maps is not steep at all. Hand-designed maps are plainly superior to algorithmically generated maps, which is why cartography is still a profession. The location of points of interest does not change "daily" by any stretch of the imagination. I just... I can't believe this. I feel like I don't even know this community any more. LtPowers (talk) 13:03, 2 August 2013 (UTC)

I don't think any of us opposes hand-crafted maps... They should be left as a preferable option, but they will never cover even our guide articles, which is only a small fraction of the Wikivoyage content. We have to be realistic about that.
Regarding the locations and their changes, I do try to maintain some articles (again, in ruvoy) on a yearly basis. I think that every year between 10% and 20% of listings are changing, because some places close down and others open or simply come to my attention. If I keep changing the article without updating the map, the period of 3-4 years is enough to make the map irrelevant to its article. We see it quite often, and we have no mechanism to circumvent this problem. It is sad, but again, we have to be realistic. --Alexander (talk) 13:59, 2 August 2013 (UTC)
Exactly that, it is a matter of scale. Consider that OSM is nine years old, has over a million contributors and an active user base of 6000 people which include professional cartographers and GIS specialists, focusing exclusively on map data. Yet when I click through to some places, there's not much coverage at all. Can we realistically hope to compete with that? Or is it better for us to focus on the general travel content and reviews.
Even maps of big cities rated as star articles get neglected. What more about little towns that aren't even on the radar of people?
And I don't believe that dynamic maps and hand-crafted maps cannot go hand in hand. It does make hand-crafted maps less required, but I feel that dynamic maps in fact help make it easier to make one. I wouldn't be comfortable making maps of areas that I've only visited, let alone never been, but if Nicolas for example were to request me to make a custom map of Tokyo/Roppongi right now, it's a lot clearer and more instructive. Then insets and other adjustments that would make it a great map could be included. -- torty3 (talk) 14:31, 2 August 2013 (UTC)
(edit conflict) Whether the learning curve is high or not, hand-making maps is a very time-intensive endeavor, and it would take literally several thousand hours of work to get hand-drawn maps for even a fraction of our articles, not to mention the task of revisiting them all periodically to keep them updated. We simply do not (and will likely never) have the manpower to do things that way. I do agree that despite some limitations, the hand-drawn maps do look much nicer, and I wouldn't necessarily advocate deprecating them entirely, but dynamic maps are the only way we will ever be able to provide maps for every article, and they are really coming along and getting better all the time. And, at least for now, I really only envision them for cities and districts at the bottom of the hierarchy; hand-drawn maps will remain important for continent, country, region and metropolis articles to show how we have broken down our coverage and show highlights of things which would otherwise not show up on a map zoomed out that far. Texugo (talk) 14:37, 2 August 2013 (UTC)
But how do we encourage people to create star-worthy hand-drawn maps if there's already a good-enough hand-drawn map on the article? LtPowers (talk) 15:15, 2 August 2013 (UTC)
I am not sure I understand how that question relates to dynamic maps, unless you meant "if there's already a good-enough dynamic map on the article". But as far as I know we haven't talked about whether to lift the requirement for star articles to have a traditional hand-drawn Wikivoyage-style map. Texugo (talk) 15:35, 2 August 2013 (UTC)
Yes, that's what I meant. But I'm not concerned only about star articles. The point is that hand-drawn maps should be our ideal, and the absence of a map on an article is an impetus to create them. How do we mitigate the loss of that impetus? LtPowers (talk) 18:14, 2 August 2013 (UTC)
OK, I understand your point, and I don't have an answer for you, but I would say it's not nearly worth preventing 25,000+ articles from getting an instant, workable, automatically updated map just so we can encourage people to hand-draw a perfect map for each one. Texugo (talk) 18:30, 2 August 2013 (UTC)
I disagree with the assertion that hand-drawn maps will always be the preferable option in the future. Today we have some issues with dynamic maps, but those issues are being addressed. In the future I fail to see how a map that automatically updates when someones adds lat/long coordinates to a listing, that can scale easily based on people's preferences, and that allows you to easily browse to surrounding locales would not be preferable to a static map. I would contend that a static map should eventually become the exception, useful for countries or in situations where we need to show a Wikivoyage-specific regional breakdown, but that our goal should be to make the dynamic maps the optimal solution for the vast majority of our articles. -- Ryan • (talk) • 18:40, 2 August 2013 (UTC)
^^^^ I am with Ryan on that ^^^^ PrinceGloria (talk) 18:44, 2 August 2013 (UTC)
And I am not. Hand-drawn maps give us the freedom to decide what to show and what to skip. Dynamic maps always rely on a certain tile that can't be customized for every particular destination. Additionally, dynamic maps do not solve and probably will not solve the problem of printing and offline usage. Most cities require several maps that have different scale and show different listings, as in paper travel guides. However, this should not prevent us from using dynamic maps as broadly as possible. I see no problem in leaving the option of hand-drawn maps for those who are willing to spend time on them.
To Powers' concern: I have not seen any strong impetus, at least not over the last 3-4 years. Some of the most productive map-makers have left the project, while others say that they won't spend the effort when dynamic maps are available. I simply can't imagine who will make use of this impetus, and I don't think that many new people will jump on map drawing, no matter how large the project grows. Using Inkscape is not difficult, but many (or even most?) people never used vector graphics and won't learn it only because of Wikivoyage.
I think that leaving static maps as a requirement for star articles would be a reasonable compromise, at least for the time being. --Alexander (talk) 20:37, 2 August 2013 (UTC)
I think we should be doing the opposite, actually. We want the maps to be easily updateable, and by anyone. Any time someone does something as simple as removing a closed geocoded listing, they will be updating the map. Maps will be updated continuously by the enormous efforts of OSM contributors worldwide. They're infinitely more wiki and more practical in this regard. A good case in point is the map at Valle de Cocora (the star nomination of which LtPowers has now voted against for having a dynamic map). I could draw a static map from the same data, but that would make it harder for others to update, and would rob us of immediate updates when a hiker walks a new trail with a GPS device, or marks a new lodgings POI.
Several of the concerns brought up, I think, are also misplaced. Another benefit of dynamic maps is that they provide us with multiple layers per map. If you don't like the aesthetics of one layer, just click another one right on the map. The map becomes personally customizable to anyone at the click of a mouse. --Peter Talk 23:16, 2 August 2013 (UTC)
And not to "pull rank," but I can say with some confidence that I've done more updates on static town and district maps than anyone else here. It's painstaking work each time. Renumbering all those listings every time one is removed or another added, and then trying to keep the legend synced to the new icon numbers is incredibly tough for maps of busy districts. --Peter Talk 23:20, 2 August 2013 (UTC)
We cannot let "perfect" kill "good enough". I would not propose adding dynamic maps were hand drawn maps already exist. I am talking about adding dynamic maps were NO maps exists (which by the way is almost all articles). Travel Doc James (talk · contribs · email) 01:22, 3 August 2013 (UTC)
Yet everyone seems all too willing to let "good enough" kill "perfect". Star articles should have the best maps possible, and these slipshod dynamically-generated maps look nothing like what you'd find in a quality printed travel guide. I am stunned and disgusted that anyone would think they're actually better than a good hand-drawn map. LtPowers (talk) 01:36, 3 August 2013 (UTC)
Would not making it a requirement to have hand drawn maps / best possible maps for an article to become star not address this? Travel Doc James (talk · contribs · email) 01:42, 3 August 2013 (UTC)
[edit conflict] A map that updates itself and can be modified for different purposes on the spot is preferable to one that does not. Static maps like this are perfect only at the point in time when they are made. And your point above about cartography seems, along with your over-the-top rhetoric about this, a little strange—cartography in the modern era is GIS. And yes, our competition does use dynamic maps (Tripadvisor, Lonely Planet, Foursquare, etc.). We call our star articles perfect, while letting them fall behind reality. Keeping the maps updated for, say, Chicago is absolutely the biggest piece of the work in keeping those articles up-to-date, and it's the main reason why they're not. --Peter Talk 01:48, 3 August 2013 (UTC)
(edit conflict) Yosemite#Get in and Ann Arbor#Get around are two star articles with "perfect" hand-drawn maps that haven't been updated in ages and would (IMHO) be far more useful as dynamic maps. Our dynamic map capabilities aren't as good as our best static maps right now, but others have enumerated their functional and maintenance advantages, and they are improving daily with respect to the cosmetic issues that seem to be your primary concern. I don't think anyone disputes that some articles (mainly those that show Wikivoyage regional hierarchies) are probably better as static maps, but just as no one would suggest that Google maps would be better if it was a non-interactive series of static images, I'm not understanding why a dynamic map that offers so many more capabilities than a static map and that is constantly updated with the latest information would not be the "best map possible", particularly as cosmetic concerns are being addressed. Also, what Peter just said. -- Ryan • (talk) • 01:55, 3 August 2013 (UTC)
All articles are better as static maps, because a static map has been customized for the unique situation that is every place on the globe. Google Maps is great, but it already exists, and does a better job of mapping than any open-source solution we have available to us. But even then, its best maps don't compare to a good printed map where the labels have been conscientiously placed and icons carefully considered for both density and clarity. Unfortunately, just as I seem to be inadequate to the task of explaining good graphic design precepts to the participants in the logo selection process (since I am only an amateur graphic designer), I cannot sufficiently explain the many advantages of a hand-drawn map because I am not a professional cartographer. (And of course, by hand-drawn, I don't mean literally; I know professional cartographers use GIS data! But they craft their maps with an eye to readability, clarity, and aesthetics that no computer algorithm can match. That's what we should do as well, at least for articles which we are claiming to surpass the best printed guides!) LtPowers (talk) 14:45, 3 August 2013 (UTC)

Don't be dispirited, LtPowers.
I think many of us appreciate your cogent points that all dynamic maps are aesthetically inferior to the best hand-crafted static examples. Do you appreciate the points being made about their ease of insertion into articles and maintenance?

I think there is still much work to be done in improving the way icons are displayed and other aesthetic improvements and your eye for good readability, clarity, and aesthetics could provide valuable insights there. --W. Franke-mailtalk 15:40, 3 August 2013 (UTC)

Well, yes, they certainly are easy. And if there was nothing more to this than "these are a useful stopgap until we can create good maps for all destinations", I'd welcome their proliferation. But their mere presence will serve to strongly discourage future hand-crafted maps, and others above state that they're actually better than hand-crafted maps. Both are significant problems that I'd like to see addressed before we go forward with any more of these maps. LtPowers (talk) 22:56, 3 August 2013 (UTC)
People only make hand-crafted maps for star articles and I think leaving the current star nomination requirements as needing a hand-crafted map addresses your concern, and that is a separate issue blocking star nominations and not dynamic maps in the first place. Anyway I've been typing and re-typing my response, but I am unexpectedly busy this weekend, so this is as much as I'm going to get in today. PS do not use {{Poi}} in the first place. -- torty3 (talk) 00:20, 4 August 2013 (UTC)
Only for star articles? Absurd. Look at Childs, Rochester (New York), Niagara Falls (New York), Letchworth State Park... LtPowers (talk) 00:43, 4 August 2013 (UTC)
Non-star articles do not require any maps. I think that static maps should be welcome as long as they are up-to-date. --Alexander (talk) 07:54, 4 August 2013 (UTC)

Powers, could you explain your ideas regarding the development of maps and cartography in Wikivoyage? --Alexander (talk) 07:54, 4 August 2013 (UTC)

Regardless, there is absolutely no way to say that the new dynamic maps are not a million times better than nothing, and I would not accept holding up their implementation in the 99% of articles which currently have no map on the basis that someone wishes they were the same quality as a hand drawn map. That is asking too much. Texugo (talk) 12:38, 4 August 2013 (UTC)
If that's what you think I'm saying (and if Alexander doesn't understand my ideas at all), then I guess I've utterly failed at communication here. LtPowers (talk) 13:58, 4 August 2013 (UTC)
No, I don't understand your ideas well enough. However, I don't want to ignore your opinion, even though I feel that dynamic maps are absolutely crucial for this project.
OK, let me try to ask you a different question. Do you feel that Wikivoyage has sufficient number of maps and decent rate of map-drawing? If not, how could we improve this situation? --Alexander (talk) 14:05, 4 August 2013 (UTC)
I agree completely with Texugo just above.
Taking Shanghai and its districts as an example, since I know that moderately well, we find four types of map are involved.
we have one fine hand-drawn map at Shanghai#Downtown
dynamic map links for every district
maps for the borders of each district, grabbed from Commons
A recommendation in "get in" that travellers grab the tourist bureau's free map handed out at the airport
All of those are useful, and none of them are perfect. See Talk:Shanghai#Map_stuff and Wikivoyage_talk:Dynamic_maps_Expedition#Shanghai_map for discussion of some problems.
I'd say all have a role and, as a rather non-graphical person, I'm content to let the map-makers work out where their effort is best spent. Making more hand-built maps here? Improving our interface to OSM maps? Contributing to OSM work? I can see benefits to any of those, but have no idea what the priorities should be, and anyway it seems possible different people will contribute in more than one place. Pashley (talk) 14:05, 4 August 2013 (UTC)
Where to start. Again, I reiterate that dynamic maps will make it easier to make hand-crafted maps. All the current instructions already rely so heavily on OSM, which continue to come out with a bunch of output options. Maperitive itself has custom rulesets so you can actually set a shared Wikivoyage colour scheme instead of manually changing them by hand. I'm vague on the details, but as far back as WTP days I think there was a coordinates to SVG tool which would significantly cut down on the time needed to map listings. This would all come down to a base SVG map with various layers that could be tweaked in Inkscape.
Of course, this is all moot if everybody feels that dynamic maps are the way to go. Admittedly the expedition has been more focused on the technical aspects, and this is probably the largest philosophical discussion we've had over dynamic maps. The quality of hand-crafted maps is recognised, but the sad fact is that even for star articles (Ann Arbor has 250 listings (!) of which I'm willing to bet at least 10% have closed), they are not maintained at a rate that I would expect from a quality printed guide. Hence the argument for perfection doesn't even seem to apply currently, especially so for huge cities where listings may open and close everyday. Ideally yes, reach for perfection but realistically I don't see it happening, with or without dynamic maps. -- torty3 (talk) 12:45, 5 August 2013 (UTC)

I understand LtPowers, and agree that a perfect hand-drawn map is better than a perfect auto-generated map, especially on static media (paper, offline HTML) where maps can't be scrolled/zoomed/clicked anyway. How about we allow dynamic maps on all articles, but require at least one quality up-to-date static map for star? That would re-establish the incentive to create such maps. Nicolas1981 (talk) 06:57, 6 August 2013 (UTC)

Hear, hear. Well said, Nicolas1981!
As someone who loves maps I'm excited by the possibilities that are opening up with the wonderful work being done with dynamic mapping
However, we also need to give some thought as to how we can give a choice to our readers on slow or expensive connections to avoid the massive data download hit associated with embedding dynamic maps in articles. --W. Franke-mailtalk 12:52, 6 August 2013 (UTC)
Nick, are you proposing that some articles have both a generated map and a hand-designed one? That seems excessive. I'm also not sure how much of an incentive it is, as not everyone can or wants to work toward getting an article up to star quality. LtPowers (talk) 20:24, 6 August 2013 (UTC)
(Note: There is another person here really called Nick) I don't think static and dynamic should be mutually exclusive. When there are both, I suggest embedding the static map as a wiki image (as usual), and adding a link to the dynamic map in its legend. By the way, do you agree that some articles requires several maps (for instance one for the whole city and suburb POIs, and one for the tiny historical center where all of the good small restaurants are packed). Requiring static maps for stars is already quite a strong statement. Placing incentives for volunteer work is risky, because it takes the form of "You want to contribute X? Then you must contribute Y too!". Like any of our rules, it can make contributors flee.
Another advantage of dynamic maps: I believe they encourage visitors to add new POIs with latitude/longitude, just for the pleasure of seeing their work appear immediately on the map. Also, map-minded people will easily spot POIs that are missing ("the history museum is great, why is there no pin on it yet!"), leading to more participation.
A dynamic map is a great first step before creating a static map. It allows the map creator to envision the final result, decide what is the best scale, clip the right area, find an appropriate place for the legend, easily place POIs. Inexact analogy: It is a bit like adding a new POI with no contact details: Offline people won't be able to use it, but it is better than nothing, and within one year another contributor will probably come and add the contact details. Nicolas1981 (talk) 03:15, 8 August 2013 (UTC)
I just did a performance analysis of the Tokyo/Roppongi article, and I found out that dynamic maps actually don't take much bandwith. [48] As you can see, base page takes 1265kb, and map takes 859kb, of which 535kb should not be loaded, so that's down to 324kb when the bug is fixed: Only 20%. I find it very acceptable. Nicolas1981 (talk) 10:08, 8 August 2013 (UTC)
I absolutely agree that some articles need multiple maps. I just think that the dynamic map doesn't offer anything to the reader (vs editor) that a good static map wouldn't. LtPowers (talk) 13:57, 8 August 2013 (UTC)
For one, I love the ability to zoom in, and the ability to scroll and see what is further down that river... exploration :-) Nicolas1981 (talk) 00:58, 9 August 2013 (UTC)
Absolutely; browsing a zoomable world map is an entertaining pastime. But I don't go to a travel guide to do it; I go to a mapping site. There seems to be a push to be all things to all people: some want to provide hundreds of links to Wikipedia to save a few users the trouble of seeking out an encyclopedia; others want to provide comprehensive world maps to save users the trouble of seeking out a map site; next, I assume we'll have a proposal to add hovertext definitions of words to save folks the trouble of consulting a dictionary? LtPowers (talk) 15:04, 9 August 2013 (UTC)
LtPowers, you're missing the mark in a spectacular way here. Dynamic maps have a bunch of advantages over static maps, to the point of making static maps largely obsolete in almost all fields. So let's go over some as they pertain to our purposes, starting with the benefits to readers, most of which have to do with the ability to customize your own visual, thematic, and content experience (this is basically why they are called dynamic maps). We don't have all of the following potentials realized yet, but they're all possible:
  1. Readers can customize their experience to their own aesthetic preferences. If a reader prefers the familiar OSM Mapnik scheme, they can choose that, or switch to our Wikivoyage layer at the click of a button. If a reader needs a high contrast colors map, a map with larger or smaller icons, etc., again, they can get that with one click.
  2. Readers can customize their experience to their own content needs. A reader could click a button to show only restaurant listings, or can zoom in to only look at one area. This is obviously of enormous use in printing maps customized to the reader's needs.
  3. Readers can customize their thematic experience by clicking for other features, like a topo layer, bike paths, bus routes, etc. A topo layer is often going to conflict with (crowd out) other information presented, but a user might have a special use for it.
  4. Readers can navigate elsewhere via the map itself: a user looking at the map for Washington, D.C./East End could pull up the icons showing nearby geocoded articles to jump to adjacent district articles like Washington, D.C./National Mall or Washington, D.C./West End.
Those four are enormously useful, and are just what come to mind off the top of my head without thinking much about this. But the notion you are advancing about advantages to editors not being relevant to readers is just 100% wrong. (And I'm not talking about the ease of creation--they are superior even when you have a motivated editor pushing an article up to star status.) Here's why:
  1. Maintenance workload. I personally have contributed 101 maps with listings currently displayed on our site (I just checked). I can count on two fingers the number of times that I've seen someone else upload a listings update to any of them--the wiki method that allows us to keep content up-to-date is absolutely not working with city/district maps. So let's say I update each once a year, budgeting maybe 25 minutes for the chore per map. That's 42 hours of work to keep them updated on just a yearly basis, and that doesn't include time spent checking that the articles themselves are up to date! Moreover, there's far too high a likelihood that I screw up the numbering between the legends and all the individual icons. The end results are simple and are to the detriment of our readers: a) outdated maps, 2) significant error introduction, and 3) time wasted that would-be mapmakers should put to much better use in developing content.
So what are the advantages of static maps? There's really just one: control by the final mapmaker. When drawing a map in an SVG editor, the mapmaker has pretty much full control over every aspect of display, in terms of what to include and how to show it. Here's a pretty one that I made, with selectiveness of display terms of which street names are displayed, as well as labels for the sports stadium and only one of the parks. The other biggie is icon size, but that's something I envision we'll be able to let readers customize—remember that all this extra control to the mapmaker is taken out of the hands of the end user!
If the proposal from this thread is that our best articles should omit dynamic maps, then I think we've reached very wrong conclusions. Maybe this will only become clear to some as our capabilities with dynamic maps improve—they're just in their infancy right now. --Peter Talk 22:46, 9 August 2013 (UTC)
If the proposal from this thread is that our best articles should omit static maps, then we've reached very wrong conclusions. A good cartographer can beat a computer every day of the week and twice on Sundays. The profession of cartography isn't going away anytime soon, no matter how good Google Maps gets, and there are good reasons for that that I'm apparently completely failing to communicate here. That's on me, but I don't know how else to put it. The dynamic maps are nice toys for online use, but they are not suitable for printing in any way, shape or form; relying exclusively on them is a step back, not a step forward. LtPowers (talk) 23:48, 9 August 2013 (UTC)
LtPowers - you are making your point very clearly, and Peter has outlined his counter-arguments. If you disagree with any of his points let's discuss, but if the argument is simply that a cartographer can make a better looking printed map then that doesn't appear to be a persuasive reason to ignore all of the benefits that Peter has enumerated. If our primary goal was to make maps that people print out and hang on walls then I would agree with you, but since 1) our primary goal is to produce free, complete, and up-to-date travel guides, 2) we can continue to improve the printability of dynamic maps, and 3) for the reasons Peter outlined dynamic maps are far, far better references for online use (our most common use case), I agree 100% with him that the technology has reached a point where they should become our focus. -- Ryan • (talk) • 00:29, 10 August 2013 (UTC)
(edit conflict) You keep alluding to esoteric knowledge that you cannot communicate, but you are instead communicating a lack of familiarity with the field of cartography. Google Maps is produced by cartographers. Virtually any print maps of any kind you see today are printed more or less directly from dynamic systems. You aren't bothering to acknowledge any of the long list of very meaningful advantages of dynamic maps enumerated in my last comment or prior throughout this long thread, and you aren't explaining the advantages of static maps beyond weird blanket statements and straw men like "nice toys," "not suitable for printing in any way, shape or form," "the dynamic map doesn't offer anything to the reader (vs editor) that a good static map wouldn't," "I am stunned and disgusted that anyone would think they're actually better than a good hand-drawn map," etc. That's making this discussion frustrating and less productive than it should be. --Peter Talk 00:33, 10 August 2013 (UTC)
Modern printed maps are computer-assisted, but their final aesthetics rest in the hands of expert cartographers. This parallels our process with taking data from sources like OSM and carefully arranging the information for readability and clarity. I have acknowledged that the dynamic maps are easy, and fun to play with, and useful; I'm not sure what more you want on that front. As well, only Peter and Ryan appear to be unable to recognize the strengths of hand-designed maps, so I could make a similar complaint: this discussion is more frustrating and less productive because you aren't bothering to acknowledge the many advantages to static maps that I've laid out in the past. To Ryan: Where I disagree with Peter's points is in his dismissal of "the advantages of static maps" as "just one": "control by the final mapmaker". Embedded in that seemingly small 'advantage' is a very big point, though: the entire purpose of maps! The purpose of a map is to show, clearly and understandably, where things are in relation to each other. That requires precise control by the mapmaker. Have you not seen these dynamic maps with icons overlaying text, and each other? And I am appalled that we are dismissing the print version so easily; last I checked that was still one of our bedrock Wikivoyage:Goals and non-goals. Do you want our maps to be competitive with those in printed guides or not? LtPowers (talk) 17:28, 10 August 2013 (UTC)
Our core disagreement seems to be this: you say that creating a good map "requires precise control by the mapmaker", while Peter and I dispute that statement and are arguing that any display issues with dynamic maps are minor inconveniences that are easily rectified by zooming or hiding layers, and that the list of advantages Peter outlined (that I assume you do not dispute) far outweigh any disadvantage due to the default display issues. Given those two positions, we may have to agree to disagree that moving control of map display from a "cartographer" to a user who can now customize what the map shows and how it shows it is detrimental enough to outweigh the many advantages offered by dynamic maps. A strong argument that Peter has made is that giving the user (rather than the "cartographer") control is an additional advantage, as that user can now easily create a customized map that is tailored to their specific travel needs. -- Ryan • (talk) • 18:13, 10 August 2013 (UTC)
I'm not sure why you keep putting "cartographer" in quotation marks... Customizable maps are good, to an extent (it's easy to go too far), but I don't see any rational way to achieve that without sacrificing the many advantages offered by a well-constructed hand-designed map:
  1. A carefully designed static map can achieve a level of clarity, aesthetics, and simplicity that even the best dynamic maps cannot.
  2. Static maps provide the information they need to provide right there, without requiring input from the user.
  3. Relatedly, the interactive features of the dynamic map are useless in print, leaving a hand-designed map the only way to present a useful guide to the print reader.
  4. A hand-designed map can be designed explicitly for the unique properties of a given destination, rather than needing a single solution that works for all.
It's unquestionable that these dynamic maps will greatly enhance our guides that do not have maps. But I would be disappointed to see hand-designed maps fall by the wayside simply because dynamic maps are available, and I really could not countenance the deprecation of hand-designed maps. LtPowers (talk) 21:04, 10 August 2013 (UTC)
OK, maybe we can now have an actual conversation about this... I definitely agree with your point #1, although I think you critically underestimate the influence that you as an individual contributor can have over the default appearance of a dynamic map. It requires some very basic work setting up defaults in the article itself, and may require some work on OpenStreetMap itself (which is much easier than trying to import their huge files and edit them in SVG format).
Number 2, though, strikes me mostly as a disadvantage. Preventing users from being able to use their own input to get what they want from the map (focusing on only the content they want, the appearance they want, etc.) is one of the most obvious reasons of why static maps are inferior (in both online and printed environments).
Number 3 is dead wrong for reasons I've already covered above (I'm resisting a temptation to just copy-paste my earlier comment). Users can choose what sort of map they want to print via clicking layers. Readers with visual impairments can select a scheme that is more readable in terms of color, text size, etc. Users can choose to print only the content they are interested in (turn off icon layers & keep only bike layers, turn off all icon layers other than restaurants, turn on topography, select only a small portion of the map, etc.). Brilliantly, we don't even need to maintain the information in those layers, since OSM will do it for us. I would never contest that static maps have their advantages for printing—I'm intimately familiar with the advantages, but to claim that dynamic maps don't have advantages for printing is absolutely, positively, completely wrong.
Number 4 is also wrong, in missing the whole point of what a dynamic map is: it's dynamic. The notion of one-size-fits-all goes out the window when readers (and editors, in choosing defaults) can choose how the map displays. Topography is usually not too important, but it's great to have for a mountainous hiking route, so just turn on that layer (editor-chosen defaults, or user selected); want biking routes?—click the layer; color schemes; content themes (just attractions, just restaurants, etc.). The opposite, however, is true of static maps—they are one-size-fits-all for users. The map editor makes their best judgement of what to include and how to present it, but those choices are denied to the end user.
These are all reasons why map editing with graphics software is not something that geography departments are even bothering to teach any more—GIS technology has developed so rapidly and our capabilities today are so radically different from even 10 years ago, that static presentation of maps is fast becoming obsolete. Intervention before printing is possible in the dynamic system itself. This is why "cartographers" is starting to show up in quotes, because you're attributing a meaning to it that absolutely is not shared by professional cartographers, who view computers and GIS systems as their tools, not competition. We were stuck in the 90s before, because we didn't have any developers interested in creating custom mapping tools for our own project. Somewhat to my amazement, that's no longer true, and we should take full advantage of this.
Lastly, it would be absurd to ignore the enormous advantages in maintenance and accuracy of dynamic maps. Human error (mostly typos) is a big problem, especially when performing listings updates on icons numbering in the hundreds. I have a lot of experience with this. Allowing all users to take part in the maintenance (by just editing the article text, or by "external" editors working on OSM) allows us to finally crowdsource this work, instead of relying exclusively on a handful of superusers. This will mean maps that are more up-to-date and more accurate, which is just another huge advantage for the reader. --Peter Talk 20:33, 12 August 2013 (UTC)
I'm sorry, but I just can't get past the fact that these maps look like crap. They really do. Icons overlapping text, missing text labels, inefficient icon and text placement. Why would we want to make our users fiddle with settings just to get something that looks mediocre? I can't deny the advantages of dynamic maps, but I just don't see how we can consider any of our travel guides to be among the best on the planet without a good travel-style map that prints up as well as any in Lonely Planet or Fodor's. It's nice that users can customize their maps for printing, but you're trying to have it both ways a bit; one of the mitigating factors for dynamic maps is that it's okay if they're not perfect layout-wise because users can scroll and zoom them, but that mitigation is not applicable to print versions. Also, I also view computers as GIS systems as tools; it is you who is viewing them as mapmakers themselves. I still say it requires human intervention to create a good map, and that intervention should rest on us, the authors, not our readers who may not have the technical savvy to fine-tune a map that looks good. LtPowers (talk) 02:22, 13 August 2013 (UTC)
Some of the things you say in this thread are amazing to me. I just said, verbatim, that cartographers view computers and GIS systems as their tools. And then you state the exact same belief and say I claim the opposite? What's the deal, seriously? Are you having a laugh at my expense? Human intervention occurs at nearly every step of the way in a GIS, but we'd be able to crowdsource that work, instead of having a handful of people (mostly me and PerryPlanet?) do virtually all of it.
The technical fiddling required to see different street names and deal with icon placement (an issue at lower zoom levels) is just double clicking. People overwhelmingly use online mapping services like Google Maps instead of the printed maps you used to buy at gas stations, so they're pretty used to that functionality, and clicking layers is likewise familiar (street map/satellite/etc.) and easy. Static maps do require less manipulation to get a good print copy, and you don't have to worry about perfection of display at multiple zoom levels (you do have to worry about whether it will print legibly in-article, and whether what's readable to you is even vaguely readable to everyone). That's probably their biggest selling point. But with all the other advantages of dynamic maps... I think the cost/benefit analysis has to favor the dynamic maps. Having created 101 static maps with icons literally numbering in the thousands (I think Chicago alone has more than 1,000) to keep updated, I feel the need to diffuse the workload more deeply than most, perhaps. And FWIW I've always thought commercial travel guides had awful maps—ours are usually way better. If the bar is to get our dynamic maps printing better than the in-guide LP maps, then I expect we'll arrive there soon. --Peter Talk 03:42, 13 August 2013 (UTC)
And you scoffed when I said I was having trouble explaining myself... I agree when you say cartographers "view computers and GIS systems as their tools". We do the same thing. What I was trying to say is that you seem to be of the opinion that these computers and GIS systems can do it all by themselves, producing the dynamic maps that everyone seems to like so much. I'm saying that computers and GIS systems are just tools; they can't produce good maps by themselves, and need a human cartographer to refine the information into an aesthetically pleasing, easy-to-understand form. As for the rest, I strongly disagree that the advantages of dynamic maps outweigh the disadvantages to the point of deprecating hand-designed maps. When you can find a computer that can produce a map comparable to File:Map - Walt Disney World - Hollywood Studios.png (including the orientation selection), then maybe we can talk. Until then, I can't imagine telling anyone "No, we don't need your map; we have computers!" LtPowers (talk) 23:41, 14 August 2013 (UTC)

It would be foolish for me to assume from the silence on this issue that I've brought everyone around to my point of view. Are we going to continue on the road toward deprecating hand-designed destination maps in favor of mass-produced "good enough" dynamic maps? LtPowers (talk) 14:09, 30 September 2013 (UTC)

I like both, and would prefer to see both when possible. A good custom map is a thing of beauty as well as a way of displaying the information the maker considers most useful, while a dynamic map gives a wider range of options. On the other hand, a good custom map can be a lot of work, and a dynamic map can be better than a crappy custom map, and certainly better than no map at all, which is the default condition of most articles. Ideally, I like to see a location map, giving the position at a glance, and a custom map showing the detailed layout and the scope of the destination. A dynamic map can often be more useful when working out how to get to a specific place. • • • Peter (Southwood) (talk): 15:03, 30 September 2013 (UTC)
@LtPowers - I can't speak for others, but silence on my part has been due to a lack of anything new to add to what's already been said. My position remains that I think the dynamic maps are superior to static maps in the ways that have already been enumerated (and I would emphatically state that they are not just "good enough" maps), and where they have layout or aesthetic disadvantages (which I would continue to argue are disadvantages that are far outweighed by their advantages) are being addressed as the technology rapidly improves. As PeterS notes, there will always be some places where a static map makes sense, such as with dive sites, Wikivoyage region maps, or "overview" maps where the data the map is trying to show (underwater topography, region boundary, simplified overview) is not handled well using OSM data. However, for cases where the map is showing listing locations I'd like to see dynamic maps eventually become the default for all of the reasons that have been previously discussed. -- Ryan • (talk) • 15:56, 30 September 2013 (UTC)
I don't understand how you can admit that dynamic maps often have "layout or aesthetic disadvantages" while simultaneously disagreeing that they're merely "good enough" and not ideally suited to every destination. LtPowers (talk) 18:32, 30 September 2013 (UTC)
To flip your statement around, would you say that static maps lock users into a specific map area, are quickly out of date, lack the benefit of data generated by OSM, are potentially unusable to visually impaired readers, prevent a user from zooming in on areas of particular interest, cannot be customized to a specific traveler's needs, etc, but are superior because the creator can ensure that they never have "layout or aesthetic disadvantages"? We fundamentally differ on the value of aesthetics vs the value of the additional functionality offered by dynamic maps. -- Ryan • (talk) • 19:02, 30 September 2013 (UTC)
Certainly both approaches have some disadvantages, but you specifically claimed that dynamic maps are better than "just 'good enough'", implying that they are in fact ideal. I apologize if I misread your intent. To answer your point, all of those functions can be achieved using other tools, tools which will almost always be better designed, faster, and more familiar to readers than our own dynamic maps. A good-quality static map is pretty much unique to the travel-guide realm. I don't think I'm just being self-aggrandizing when I say that this map has inherently more value to the traveler than this one, even (or especially) if the latter were to be peppered with numbered icons. LtPowers (talk) 00:39, 1 October 2013 (UTC)


Guidelines for deploying dynamic maps[edit]

Swept in from the pub

The author behind dynamic maps (Joachim) will soon make his source code open source, which was one of the concerns blocking wider deployment. While the discussion above is not settled, we should brainstorm how deployment should be guidelined. Ideas, feel free to edit:

A) In which articles can a dynamic map be inserted? A1) All articles, just centering the map on the place. A2) All articles that have at least one geolocatlized POI. A3) All articles that have at least 5 (or more than 70% of all POIs) geolocalized POIs.

B) Where to put it. B1) Always in the up-right corner, infobox-style, like on the French Wikivoyage (example). B2) Right-aligned at the top of the See section. B3) As an external link, like on the German (example) and Russian (example) Wikivoyages. B4) Right-aligned at the top of the Get in or Get around section section as in Troy (Michigan).

C) What size? C1) Same size as at Tokyo/Roppongi. C2) Smaller. C3) Larger. C4) Ad hoc.

D) What legend (small text below the map)? D1) Similar to Tokyo/Roppongi.

E) How many dynamic maps per article? E1) At most one. E2) A main plus plus one per interesting part of the destination. E3) Same as E2 plus a higher-level map showing the destination in its wider region.

Personnally, I would say A1-B2-C1-D1-E2. What do you think? Cheers! Nicolas1981 (talk) 08:34, 6 August 2013 (UTC)

In fact, Russian Wikivoyage is switching to another format with the collapsible map inserted after the introductory paragraph and right before the Understand section. Here is an example. Click on the map icon or "Открыть карту" text next to it. --Alexander (talk) 09:07, 6 August 2013 (UTC)
I think placement should be in the Get in or Get around section as the POI are going to be for listing from See, Do, Buy, Eat and Sleep. Near the start of the article so readers understand the context but not at the top or in specific POI sections where hopefully are some interesting images. --Traveler100 (talk) 09:31, 6 August 2013 (UTC)
I would say:
A) All destination articles at the bottom of the hierarchy-- the function of maps in metropolis, region, and country articles is to show how we have broken down the coverage. The dynamic maps do not serve that function at this time.
B) At the top of the Get around section. It needs to be down lower since people will be scrolling between listing sections and the map. Putting it in See would strike me as odd since it has listings for the subsequent sections too, but it is generally essential for getting around in all cases.
C) I would be OK with the size at Tokyo/Roppongi or a little smaller, but do I think the size should be standardized between all articles.
D) I don't know what the other options are, but Tokyo/Roppongi looks fine to me.
E) Just one. More than one takes up too much space and seems redundant.
Texugo (talk) 11:13, 6 August 2013 (UTC)
I agree with Texugo for A&B, although we should give ourselves a bit of leeway with B when it doesn't fit quite right with other right-aligned content. I don't think we need to force a one-size-fits-all approach for C: some that have little detail can be quite small, while others will be better suited to a larger frame; ditto width-height ratios. Could you restate question D?
E is kind of the biggest question, and maybe one we'll have to feel out. Having more than one mapframe is kind of redundant, since they are zoomable & scrollable. But there are display advantages to having one loaded with an overview of a city, and one loaded with just a view of the central tourist area. I'm thinking of Vladimir as an example: there's the whole city, but it would be nice in the see section to have a map preloaded of just this area to show the main sights. I believe that, right now, it is not possible to add more than one instance of {{mapframe}} to one article. --Peter Talk 23:02, 9 August 2013 (UTC)
  • A) All destination articles at the bottom of the hierarchy. Maps of regions etc. could follow later.
  • B) At the top of the Get around section. So you can always find the map in mobile version at same place. The sections are there collapsed as standard.
  • C) Map window should have a standard size. The window only needs to show a 'hotspot', not the entire article area. The button 'Show me all ...' do that quickly.
  • D) D1 is OK for me.
  • E) Just one mapframe. In addition, you may always click on the colored markers in the article. Then you will see immediately the correct map section.
Joachim Mey2008 (talk) 04:53, 12 August 2013 (UTC)
I agree with most said above, but firmly disagree about "one map per article" - the articles also need to be printable, and in many cities there are many "hotspots" which one map cannot cover legibly, and/or there are many POIs outside of the centre and many in the dense centre, so we need at least two maps to cover them in a legible way. I've just used the maps for a road trips of 8 cities and printed each of them in several zoom levels and focii - but this was because I knew how to do that and that I would have to do that. Other users without much in-depth knowledge would simply print out the article and be baffled not to find many POIs with POI icons in the article displayed on the map and get frustrated.
For the same reason, I am not quite sure about standard size. PrinceGloria (talk) 06:06, 12 August 2013 (UTC)
Printing is another thing. It is possible to print specific sections in different scales. Not limited by the screen. The whole city, the center, the special destination. But the programming takes a little time. - Joachim Mey2008 (talk) 07:17, 12 August 2013 (UTC)
First simple demo. PDF for off-line map or A4 print [49] . -- Joachim Mey2008 (talk) 20:14, 13 August 2013 (UTC)
Nice! Would it be possible to have an arrow indicating the North, as it might not be obvious? Nicolas1981 (talk) 05:36, 14 August 2013 (UTC)
It looks like a messy jumble of shapes to me. It's not very readable. LtPowers (talk) 23:42, 14 August 2013 (UTC)

Numbering[edit]

The numbering of the Poi template is not in line with the Listings template. See Bangkok/Rattanakosin#See. Another problem is that the numbers potentially don't match with the static map. Globe-trotter (talk) 21:42, 10 August 2013 (UTC)

I have changed the tl:poi to tl:listing. Please review the text. Tl:poi is not automatically numbered. Therefore, please do not use in the same section with tl:listing. The template listing will soon be adapted for in-line use. See my sandbox, "Do" section. - The tl:Poi was only in the notation {{Poi| recognized (typical German). I will correct that.-- Joachim Mey2008 (talk) 13:17, 11 August 2013 (UTC)
I understand now the templates shouldn't be combined. I'll wait until it supports in-line use. Thanks for working on it! Globe-trotter (talk) 14:57, 12 August 2013 (UTC)

BUMP Any word in modifying for in-line use?

(See Template_talk:Listing#Switch_to_remove_.22edit.22_hypertext_label) --W. Franke-mailtalk 16:30, 25 August 2013 (UTC)

OSM with style[edit]

How can I join in the effort to improve the custom layers (in particular, the Wikivoyage layer)? I often see simple things that should change, and would like to help. Right now, it would be to ensure that "bridlepaths" and "generic tracks" show up as trails. --Peter Talk 21:38, 12 August 2013 (UTC)

Why don't we just use Mapquest Open for all maps? I think those look professional and good. Globe-trotter (talk) 23:47, 12 August 2013 (UTC)
Because its grossly inferior in many objective areas
Why on earth would we want to force folks to use a usually inferior non-standard layer of OSM? Compare and contrast:
Standard OSM with "Mapnik layer            mapquest open native website
Being able to switch between custom layers rather than having someone else's choice forced on you is also great so leave the choice up to the user - a bit like thumbnail sizes really! --W. Franke-mailtalk 00:05, 13 August 2013 (UTC)
I think the ability to switch between custom layers is one of the principal advantages of dynamic maps, so I don't think mandating a single "one-size-fits-all" style would make sense. But could we go back to my original question—how can I help develop the Wikivoyage layer? --Peter Talk 00:45, 13 August 2013 (UTC)
It is currently only possible Mapquest Open as the default layer. Only Mapquest has no limitations when retrieving the tiles. OSM (Mapnik, Traffic) prohibits mass access. CloudMade (Wikivoyage layer) is free only up to 500,000 tiles per month. But at the time access is not counted. Nevertheless, this layer is of interest for specific requirements.
@Peter: Only the CloudMade layer (WV-Layer) can be changed in some of the properties. Only the owner User:Torty3 has access, but anyone can copy the style "Wikivoyage2" and make suggestions in his own style of map. So maybe we'll find an even more better adapted WV-layer. Click here for Style Editor. -- Joachim Mey2008 (talk) 06:08, 13 August 2013 (UTC)
To add other advantages of Mapquest Open, their tile server and renderer is much faster than either OSM and Cloudmade. Another big one is the use of English for labels. Compare Muscat, [50] in Oman for example. I've also noticed that Cloudmade doesn't update their map data very frequently. And if the plan is to add coords to the Christ Church Cathedral then the label just interferes with the icon.
For really long-term plans, setting up a tile server in WMF labs [51] is probably the way to go. I think they are in the middle of a migration, but basically the plan is to host map tiles for the different WMF languages. We could probably ask them to instate a specific style designed to our specifications, then the maps.wikivoyage-ev.org server can access their tiles too. -- torty3 (talk) 07:23, 13 August 2013 (UTC)
PS search for 'Wikivoyage2' in the Style Editor. Then clone the style and when you modify it, just list the id number here so it can be substituted. I've some other projects on it so can't make the account open. -- torty3 (talk) 07:42, 13 August 2013 (UTC)

ShareMap as dynamic POI generator[edit]

Hello we recently created ability to export from ShareMap data in MapFrame template format Here is screencast tutorial: ttp://www.youtube.com/watch?v=Xc5F98q87uo

Any feedback is warmly welcome In future we also plan to incorporate some GPX related features that can useful within WV project (in the same way in which ShareMap can export KML that are embeded as dynamic maps within English Wikipedia)

--Jkan997 (talk) 22:57, 17 August 2013 (UTC)

Very nice! And welcome to the expedition ;) --Peter Talk 04:16, 18 August 2013 (UTC)

Problem with Dresden[edit]

For whatever reason, the dynamic map for Dresden started displaying only a few POIs this morning. Anybody knows what went wrong and how to rectify it? PrinceGloria (talk) 06:25, 18 August 2013 (UTC) PS. Feel free to delete/archive this topic and its contents once this gets rectified, unless there is a general thing that everybody should know of and avoid / always do.

With dynamic map there are almost daily updates. These updates are tested with a set of articles, browsers, etc. Sometimes errors affect only a few articles, as in this case. Therefore I need error messages from user community. - The correction is now done (hopefully successful). - Joachim Mey2008 (talk) 13:16, 18 August 2013 (UTC)
The reason for misinterpretation of contents was the 'less than character' "<" in "children <16: free". I thought that was reserved for HTML tags. I'll have to look for another solution. - Joachim

Default zoom & position[edit]

The main work in adding a dynamic map to the article is in grabbing/guessing the proper center for lat/long & choosing the optimal zoom level. But couldn't we just default it to what is shown when clicking "show all markers," eliminating the need for all that, and allowing the map to auto-upate if listings are added outside the current view? --Peter Talk 03:31, 21 August 2013 (UTC)

Great idea! But having the ability to override this default is important in articles where a single POI is far away (example: small fishing village with everything within a few blocks, plus the lighthouse a kilometer away on the long jetty) In such cases, you would probably ignore the lighthouse, and focus on the interesting part. Right? Or not? Nicolas1981 (talk) 09:39, 21 August 2013 (UTC)
Right! --W. Franke-mailtalk 15:11, 21 August 2013 (UTC)
I would say not. Leaving it off the default view means users will probably miss it, unless they're very familiar with our site. Since finding the interesting part is just a matter of double clicking near the clustered icons (which everybody understands how to do from using other online mapping services), I think that showing all markers as default is a more user-friendly solution. --Peter Talk 18:36, 21 August 2013 (UTC)
I strongly disagree. On the one hand, I always try to put all the relevant POIs in a given article, regardless of their positioning. On the other hand, in many destinations, this results in a map being all over the place - e.g. in many cities, I mark the airport for orientation, but the airport tends to be far away from other POIs. Opening the article with a map showing an undecipherable cluster of POIs in the middle and some random POIs at the edges of the city is neither visually pleasing (which a guide, after all, should be), nor very clear to the readers.
A well-positioned map adds to the experience of reading a guide a lot. One will quickly figure out how to manipulate it, but there is much value in a seasoned editor's choice of zoom level and area shown. Besides, this lets the user enjoy the article without having to zoom in and out all the time, only doing this when a particular POI is out of scope.
Finally, there is printing. We tend to forget our guides are used that way, but they are. I just started doing that and I find we still are not doing enough to make them more printer-friendly - but having the default map display as an undecipherable, unusable mess would surely make the situation even worse for printers, and it will be major PITA to have to set up the map for in-article printing everytime one prints it.
What I would see gladly, though, are indicators at the edges of the map where the POIs not shown in current focus and zoom level area (i.e. in which direction does one need to scroll to find them). That would be very useful for both online and offline use. PrinceGloria (talk) 19:14, 21 August 2013 (UTC)
Perhaps the way forward might be to have the "top right icon" map default to what is shown when you click "show all markers", but when either a zoom level has been set in the {{geo}} template or if there is a {{Mapframe}} template present, observe the handcrafted and editor chosen view? --W. Franke-mailtalk 19:39, 21 August 2013 (UTC)
As Nick suggested, a useful compromise would be to make a custom zoom and center possible via a parameter, but leave the default as when clicking "show all markers." That would take care of PrinceGloria's concerns. Regarding printing, I believe that is going to be handled quite differently—Joachim is working on it, and will almost certainly involve putting the map on a separate page (so not printing what you see in the web version). --Peter Talk 03:23, 22 August 2013 (UTC)
Joachim appears to be running some tests with zoom=auto. {{Mapframe}} defaults can be tweaked as necessary later. Try {{Mapframe|zoom=auto}} for now? (if enabled on 'w') Regarding printing, I agree that it should be done on a different page. The purpose of the in-wiki maps is kinda being stretched, which in my mind is to alert users to its presence and for light navigation. -- torty3 (talk) 05:30, 22 August 2013 (UTC)
I am not a fan of "not printing what you see in the web version". This will make things confusing and harder to grasp for the casual user, who will NOT want to learn the intricacies of Wikivoyage, at least not until they try it for a few times, find it useful and EASY to use and then starting to get involved. Any printing solution MUST print what's visible. Moreover, it will be far more complicated to edit articles BOTH as WYSIWYG for online use AND also do a printable version that nobody normally sees. I would also hate to look at a guide, find it reasonable, and then find something totally else coming outta my printer. It needs to be WYSIWYG for both displaying and printing, period.
An auxilliary printing facilitator for the maps, e.g. when a user opens the fullscreen map and then zooms in (or out) on some area, would of course be a very welcome feature, especially if it included a legend with at least the POI names (if not an option to include visible POIs with photos and/or other fields from their templates, such as "content", "address" and such as well).
What I am reading above is that the "show all POIs" thing will be turned on as a default, but we will still be able to configure the Mapframe to show a specific area, and I understand the "fullscreen map" will open starting with the zoom and focus as set in the in-wiki map if called from there (and perhaps with "show all markers" if clicked from the upper-right-corner icon), and I am very happy about it. If we could also get the ability to add multiple calls of Mapframe in the articles for cities with dense groupings of POIs in different areas, it could be brilliant as well. PrinceGloria (talk) 06:13, 22 August 2013 (UTC)
We already use/have always used a separate print version, simply because web content isn't optimized for printing. That's extra true of a dynamic map. (A few very basic examples: we hide urls behind names on web, when they're needed to be spelled out in print; templates often need to be converted or excluded; web-only content is excluded; print-only content is included; etc.) Heck, your browser itself will automatically make changes to your print selection to render it in a more print-friendly version, unless you are taking screenshots and printing them as images! Anyway, I'd recommend waiting to see what the print functionality of the dynamic maps will be before dishing out the all-caps ultimatums ;) --Peter Talk 06:53, 23 August 2013 (UTC)

I have added the new value "auto" for the parameter zoom. Zoom=auto shows all markers. This affects tl:mapframe and tl:geo. "auto" is not a default value. Many articles now have only one or two POI with coordinates. Other articles have POIs that are far outside. In these cases zoom=auto produced unusable results. -- Joachim Mey2008 (talk) 16:13, 22 August 2013 (UTC)

Well, when I print out the guide using the "convert to PDF" features here, or even create a book out of a few guides, I end up with what I see on the screen. I might overlook the fact that URLs are spelled out, as this is quite minor, and the text alignment changes a bit as well. But I would be pissed if one of the images would be missing or the map would print out differently. So far, this has not been the case, so fortunately all those "print only" and "don't print" things were not used so profusely in the guides I was interested in. PrinceGloria (talk) 08:02, 23 August 2013 (UTC)
One big example is the pagebanner. If we really are holding to WYSIWYG, then even many of the static maps don't actually work very well for online use, let alone offline. Ideally, I would prefer a full-page map and legend, whether static or dynamic. -- torty3 (talk) 11:12, 29 August 2013 (UTC)
Nice work, Joachim! I also think that is a good way to implement it since it gives editors both an easy option and an easy way to switch it off if it produces bizarre or unusable results. --W. Franke-mailtalk 16:36, 22 August 2013 (UTC)
This looks very good, danke sehr Joachim! PrinceGloria (talk) 17:55, 22 August 2013 (UTC)

Edit button[edit]

So I'm a big fan of using Geobatcher to edit listing icons' position. But could we work this in as a one-click deal? Add an "edit" button to the dynamic map itself (via {{mapframe}} and/or {{geo}})? I think it would be fabulous if users could spot an error in placement, and with one click + a click & drag they could fix it. The edit difference would just show the adjustment in coordinates, perhaps coupled with a note "Geobatcher edit" or something like that. --Peter Talk 03:35, 21 August 2013 (UTC)

Map locations update[edit]

How often are locations on maps updated. If you click on the map icon on an article then selection the function to display other locations in the area, not all pages are displayed. I assume there is a lag before the database is updated or is there a specific syntax for pages to be added?--Traveler100 (talk) 20:45, 24 August 2013 (UTC)

The destinations in the dynamic maps are updated monthly. At the beginning of the month, the data are obtained from the last dump files. -- Joachim Mey2008 (talk) 05:50, 27 August 2013 (UTC)

Using dynamic maps[edit]

I was playing around with dynamic map for the first time and created a map for Route 1-Ring Road including the ring road track in my sandbox. I have also noticed that {{Mapframe}} is marked as experimental. My question is if I can use this solution for the actual article already now? Also can I store the gpx data under Route 1-Ring Road/gpx page? And last thing: something went wrong with the numbering in my list of destinations in the sandbox map. The numbers in the map seem to be numbered continuously, while the Parks is the list are numbered from 1 again. Can anybody help? Thank you. I think dynamic maps have a great potential at WV for individual destinations. --Danapit (talk) 14:36, 26 August 2013 (UTC)

The numbering in the dynamic map shall be corrected and adjusted to the article numbering. It's still a short test required. -- Joachim Mey2008 (talk) 06:52, 27 August 2013 (UTC)
The numbering is now corrected. About saving GPX data is currently being discussed [52] . -- Joachim Mey2008 (talk) 06:52, 28 August 2013 (UTC)
Thank you for the update, Joachim! Danapit (talk) 07:05, 28 August 2013 (UTC)

Great map of Wikipedia articles[edit]

Swept in from the pub

Here we should see if we can get WV added to it. Travel Doc James (talk · contribs · email) 17:34, 27 August 2013 (UTC)

Some of the positions are quite badly out. How can they be fixed?• • • Peter (Southwood) (talk): 18:08, 27 August 2013 (UTC)
Fix the coordinates on the corresponding Wikipedia article, I presume. LtPowers (talk) 00:19, 28 August 2013 (UTC)
Equivalent for Wikivoyage: http://maps.wikivoyage-ev.org/w/artmap.php?lang=en As Peter said, fixing coordinates on English Wikipedia is a priority. Wikivoyage should reuse these coordinates (see for instance the property coordinate location at Los Angeles Wikidata). Nicolas1981 (talk) 02:01, 28 August 2013 (UTC)
How often are these updated? My changes do not seem to have any effect. • • • Peter (Southwood) (talk): 12:13, 29 August 2013 (UTC)
I believe it's currently once a month, at the beginning of the moonth, Peter. --W. Franke-mailtalk 16:23, 29 August 2013 (UTC)
Thanks, Frank. That is a rather low frequency. I assume it is a resource hungry process. Where do you get information on this feature? • • • Peter (Southwood) (talk): 17:38, 29 August 2013 (UTC)
Good question. It's a neat map, but I'm not sure how thorough it is. On the pt: version, I can see that articles I added geo to on August 1 are not there yet. Some I added at the beginning of July are now there, yet there are others which have had properly filled-in geo tags for a couple of years now that are not showing up on there. It would be great if we could get it working completely and frequently updated. Texugo (talk) 12:47, 29 August 2013 (UTC)
The WV article map [53] is updated monthly for all language versions at the beginning of the month. Using the latest available data base dump [54]. This can be up to two weeks old. @Texugo: Please list some specific examples of missing items in the map. The only way I can eliminate this errors. -- Joachim Mey2008 (talk) 17:40, 29 August 2013 (UTC)
The one that stood out to me at this time was pt:Osasco, which has had its geo coordinates filled in since sometime in 2011, but does not show up on the map. I may be able to hunt down others... Texugo (talk) 18:25, 29 August 2013 (UTC)
The marker for pt:Osasco is present but in the wrong position [55]. The coordinates in tl:Geo were wrong. - Joachim Mey2008 (talk) 04:15, 30 August 2013 (UTC)
Yes, I noticed that, thanks. I have fixed the coordinates. If I come across anything else, I'll let you know. Texugo (talk) 11:25, 30 August 2013 (UTC)
I like the map, but how is it intended to be used? • • • Peter (Southwood) (talk): 07:52, 31 August 2013 (UTC)
One more way to promote the project. A link to it inviting people to browse via map might be useful. Travel Doc James (talk · contribs · email) 10:52, 31 August 2013 (UTC)
I really, really really really want to embed ArtMap at Destinations. Can we do this? --Peter Talk 03:33, 4 September 2013 (UTC)
I am all for it! With prominent linkage goodness from the front page. That map is fun, and now that our geo coverage is up from around 55% to over 82% of our articles this month, it should be more and more worthwhile. I can't wait to see the 6500 or so new blips show up on the map when it next gets updated on Oct. 1. Texugo (talk) 11:20, 4 September 2013 (UTC)

Dynamic maps don't show up?[edit]

I have notice the dynamic maps don't show up: Wheaton, Singapore/Chinatown, Tokyo/Roppongi, ... Does this problem have any connection with Wikivoyage:Travellers'_pub#We_have_lost_listings_numbers_in_print_version? Danapit (talk) 06:00, 29 August 2013 (UTC)

Singapore/Chinatown worked for me using Google Chrome. The issue may be related to Wikimedia's switch to https for all logged-in users - if you logout and view the page using http (not https) do the maps work for you? I believe work is underway to procure an SSL certificate for the maps server. -- Ryan • (talk) • 06:06, 29 August 2013 (UTC)
Thank you, Ryan, as you say, after logging out and using http it works in my Firefox 23.0.1. Good news that the problem is being solved. --Danapit (talk) 06:30, 29 August 2013 (UTC)
A temporary fix is to go to Preferences, and untick 'Always use a secure connection when logged in'. Personally, that might be my permanent preference, since editing on a wiki has far more exposed my privacy compared to my random browsing, although I'm pretty amused that there wasn't even a secure login in the first place (some technical stuff to keep track of). I'll go ask about the security cert - it is specifically pressing for Firefox 23 logged-in users.
Re: the print version, if you click on 'print preview' (which is the actual version that will be printed), do you see the numbers? -- torty3 (talk) 06:55, 29 August 2013 (UTC)
No, actually I don't see the numbers in printing version neither with secure nor http connection. Danapit (talk) 07:14, 29 August 2013 (UTC)
Indeed, Firefox shows an small armor icon that if clicked says "Firefox has blocked content that isn't secure". We need to set up HTTPS on http://maps.wikivoyage-ev.org and change the PHP script to use the HTTPS version of each of these websites: mqcdn.com tile.openstreetmap.org tile.cloudmade.com tile2.opencyclemap.org tile.lonvia.de tile.waymarkedtrails.org toolserver.org m.wikivoyage.org upload.wikimedia.org (if they exist). Once all of this is done, normal users will be able to use dynamic maps again without having to perform complicated tricks. That's quite of a blocker issue for dynamic maps. Nicolas1981 (talk) 07:53, 2 September 2013 (UTC)
The switch to HTTPS will take some times. Until then, the following helps: log in, open Preferences, deselect "Always use a secure connection when logged in", save. Log off, log in , done. - Joachim Mey2008 (talk)

Hiking and Cycling trails on dynamic maps[edit]

How does the dynamic map know a trail is hiking trail or a cycling route -- are there specific tags that need to be set in OSM? Right now, the dynamic map labels some of the hiking trails in North Vancouver so I'd like to add more of the common ones so the map can better match what will eventually be in our travel guide. Cheers -Shaundd (talk) 16:13, 30 August 2013 (UTC)

Waymarkedtrails.org provides the layers "cycling" and "hiking". The routes must be entered in OSM as special relations. Instructions can be found here and here. - Joachim Mey2008 (talk) 05:04, 31 August 2013 (UTC)

Wikidata and article overview[edit]

Wikidata is available now and the location coordinates in the articles are obsolete now and should be removed. What are your plans concerning that? The map feature (article overview) should use the Wikidata API now instead of scanning the articles. I know, Mey2008 is working on it, but unfortunately this expedition runs here, so I am not sure where to ask. Have you talked with Mey2008 about it? Greetings from the rainy town of Cottbus. -- DerFussi 07:15, 9 September 2013 (UTC)

Well this is precisely why the expedition isn't the main operation and seems to run on Joachim's German user page (nothing against you Joachim! Just with territorial and logistical aspects. DerFussi, would you like to set up a central Wikidata overview as well, perhaps at wikidata:Wikidata:Wikivoyage_migration about the different usages of Wikidata?). My view is that it cannot rely on the Wikidata API entirely, as some people have now pointed out that Wikipedia and Wikivoyage articles do not always share the same coordinates. They could be unlinked nd set as different Wikidata items. Is there any way to extract the geo coords only from Wikivoyage even when Wikidata is used? Wikitext database dumps are being used, but could the mw:extension:GeoData be used instead? Wikidata should be making this easier, not harder, and on hindsight should have been planned for. It seems similar hoops have to be jumped if it's done for listings as well. -- torty3 (talk) 23:31, 10 September 2013 (UTC)
I think we should use Wikidata's location (including soon-to-be? dimension for zoom level), and have a "geo" only in articles where Wikidata's location is not good for us (rare). Nicolas1981 (talk) 06:58, 19 September 2013 (UTC)
I might remember this wrong, but I thought Texugo did some auto edits that added geo data taken from that source and I've had to correct latitude and longitude and zoom levels on almost every country and region level article I've encountered since. Settlement locations are far more accurate (if expressed to ridiculous levels of exactitude sometimes), and usually work well at our current default zoom level of 13. --W. Frankemailtalk 15:05, 19 September 2013 (UTC)
Nah, we're discussing different approaches here. One is manually/semi-automatically grabbing Wikidata coordinates and putting them into Wikivoyage. The other is using the Wikidata prop feature, which means the coordinates will not be seen in wikitext. Either are fine by me. My point is that we shouldn't be using the Wikidata *API* to get Wikivoyage information, and the Wikivoyage API/data dumps should be the primary and only source that data re-users (which includes the external maps) will need to use, if that makes sense. Plus the Wikidata API cannot be used if there are still local geo tags.
Currently the wikitext is being parsed, but this can't work with the second method. This would be easier with a dedicated coordinates parser like mw:Extension:Geodata, which would ideally also include the listings/vcards in its output. I think de.voy has used it in their vCard templates? Does that work well? One potential problem I see for listings then, is the automatic numbers on the wiki, but we'll just adjust to whichever method Joachim thinks is best. -- torty3 (talk) 14:13, 20 September 2013 (UTC)
Thanks for both the explanation and the correction, Torty3. I'm sure you guys will work something out that is both labour-saving and accurate. I do hope that the many manually corrected and optimised geo template latitudes, longitudes and zoom levels are not lost, though, since some of them did require quite a bit of experimentation to get right. --W. Frankemailtalk 14:55, 20 September 2013 (UTC)
Relevant discussion from French Wikivoyage, who went ahead with Wikidata implementation. Maybe stick with what we have now, especially after Texugo did all those auto edits, until we get a script to read Wikivoyage coordinates from the API (a little like this API query) We do need to clean the zoom parameters, but how goes the dimension property in Wikidata? -- torty3 (talk) 13:55, 27 September 2013 (UTC)

Secure site at tools.wmflabs.org[edit]

User:Mey2008, User:Nicolas1981 and User:DerFussi: I've set up a slightly outdated secure version at tools.wmflabs.org. I want to emphasise the fact that I do not intend this as a takeover, and it's more of a stopgap measure, if the Wikivoyage-EV association still wants to host it on their site and Joachim wants to keep updating there. I will maybe add different map tools if I do feel like adding some and you are all welcome to become a maintainer for the tools as well. I followed the instructions at the top of the page here and it took maybe a week for permissions. -- torty3 (talk) 14:58, 4 October 2013 (UTC)

PoiMap2 can be completely transferred to the tools server, in my opinion. I hope the HTTPS problem is solved in this way. Note that the tiles are not transferred in the HTTPS protocol. - But I have no idea how I can participate there, it's complicated for me. - Joachim Mey2008 (talk) 10:32, 5 October 2013 (UTC)

Yeah, it is a little complicated.

  1. Create an account at Wikitech
  2. Add email address to account in Preferences
  3. Get access to the Tools instance - need to wait for permissions, and let me know, so I can add you as maintainer
  4. Upload public SSH key - found in /.ssh/id_rsa.pub or use ssh-keygen to generate

Adding files

  1. Transfer files: scp -r PoiMap2 yourname@tools-login.wmflabs.org:
  2. Log in to Tools Lab: ssh yourname@tools-login.wmflabs.org
  3. Transfer files to Wikivoyage Tools: yourname@tools-login:~$ cp -r PoiMap2 /data/projects/wikivoyage/public_html
  4. Log in to Wikivoyage Tools: yourname@tools-login:~$ become wikivoyage
  5. Take ownership of files: local-wikivoyage@tools-login:~$ take PoiMap2

Sorry for the additional hassle with the iframe issues. Will need to bring this to Meta too. I could try and switch the PoiMap2 template to it to check whether HTTPS works. -- torty3 (talk) 07:49, 7 October 2013 (UTC)

Thanks a lot torty3! I guess you used https://github.com/nicolas-raoul/PoiMap2 ? I have FTP access to Joachim's server, so I can transfer the files to Git more often, if needed. From what I can tell, Wikivoyage does not yet use tools.wmflabs's PoiMap2 server? Nicolas1981 (talk) 11:55, 7 October 2013 (UTC)

A daily current zip.file of the entire working directory "w" is also available under http://voyage.voyage.bplaced.net/w.zip . -- Joachim Mey2008 (talk) 13:15, 7 October 2013 (UTC)

Thanks a lot for your continuing heroic efforts to crack the problem of the blank rectangular spaces where the dynamic map should appear under https, guys. It'll be a great leap forward when this is working again! --W. Frankemailtalk 13:53, 7 October 2013 (UTC)
The most current version is at [56]. Will update everything in a couple of hours, though it seems we will have to work around the access problems for now. -- torty3 (talk) 08:54, 8 October 2013 (UTC)
Do you have access to Joachim's code, or do you want me to copy the latest code from FTP to Git? Nicolas1981 (talk) 09:04, 8 October 2013 (UTC)
I grabbed it from his zip file. Latest code from FTP to Git always helps though, thanks for the additional repository. -- torty3 (talk) 09:07, 8 October 2013 (UTC)

http://tools.wmflabs.org is down now. Bad luck, or is tools.wmflabs.org known for being down often? I could not find any statistics. Where should we report this problem? I have sent a tip to http://webchat.freenode.net/?channels=#wikimedia now. Cheers! Nicolas1981 (talk) 01:18, 11 October 2013 (UTC)

[57]. Just can't catch a break can we? First the perfect storm, with initial deployment coinciding with Wikimedia moving to HTTPS and on top of that, Firefox deciding to go nuclear on mixed content. Now this! -- torty3 (talk) 01:24, 11 October 2013 (UTC)
Good thing to know it is not a crash, but planned maintenance. And seems like it will not happen much anymore :-) Nicolas1981 (talk) 01:43, 11 October 2013 (UTC)

What is the current status of this map server? Should we switch everything to tools.wmflabs.org, or does the site at wikivoyage-ev.org remain our main map source? --Alexander (talk) 06:49, 11 October 2013 (UTC)

I actually would prefer Joachim to have direct access to the site before switching, but the HTTPS problem was getting too noticeable. I don't mind if we stay at wikivoyage-ev to keep independent (except for the security certificate issue). The Tools website would remain as a stable mirror in any case, and will just not be the latest version under Joachim's control. -- torty3 (talk) 00:14, 12 October 2013 (UTC)

Maps of hiking trails[edit]

Swept in from the pub
The route of the Rheinsteig trail along the middle Rhine river in Germany

Do we have maps of hiking or mountain biking trails? Travel Doc James (talk · contribs · email) 01:30, 3 August 2013 (UTC)

I see moab is missing them. Think of getting a GPS to make some. Travel Doc James (talk · contribs · email) 01:32, 3 August 2013 (UTC)
[58] ;) --Peter Talk 01:50, 3 August 2013 (UTC)
An almost finished example in the article Rheinsteig. The GPX tracks can be recorded in OpenStreetMap. They will be displayed in the layer "Hiking" including the way signs. -- Joachim Mey2008 (talk) 10:21, 3 August 2013 (UTC)
Very nice Joachim! Nicolas1981 (talk) 08:11, 5 August 2013 (UTC)
The Rheinsteig looks like a great trail. The difficulty is that it is not clear which one of the blue trails is the Rheinsteig. It would be great to have only one trail showing on the map to reduce confusion. Travel Doc James (talk · contribs · email) 08:41, 5 August 2013 (UTC)
If you click on the map icon top right of the page, it will display just the route and points of interests. Or when on the map the layer icon top right switch off the hiking layer and switch on the GPX track layer.--Traveler100 (talk) 09:16, 5 August 2013 (UTC)
I would be interested in feedback on this page. Are people fine with single line Point of Interest entries or would more expanded text on the topics and the route section be welcome? Thinking about other POIs such as view points, shelters/huts and rescue points, would these be welcome? Are the default layers the right ones or should the top of page and in pages map references be changes? --Traveler100 (talk) 09:25, 5 August 2013 (UTC)
Since the latest MS "security update" GPX layer is no longer visible on the MS IE. I'm working on it. Firefox and Co. should work. -- Joachim Mey2008 (talk) 10:35, 5 August 2013 (UTC)
I find the map in this format to be most useful, thanks. It gives one a general overview of the trail route. Travel Doc James (talk · contribs · email) 13:21, 5 August 2013 (UTC)

Does Winnipeg/Gpx belong to article space?[edit]

Swept in from the pub

I just stumbled upon Winnipeg/Gpx, which contains just XML data. Is it an accepted convention? GPX data is great, but is there not a better place than article space to put them? Maybe Wikimedia Commons? That would keep article space clean, and allow the GPX data to be reused between languages. Nicolas1981 (talk) 09:03, 15 August 2013 (UTC)

There are many such files. I stumbled on one that was over a megabyte, don't recall where.
My guesses would be that this data belongs on Wikidata and that, since it is used for mapping the place to discuss it here is Wikivoyage talk:Dynamic maps Expedition. Pashley (talk) 10:30, 15 August 2013 (UTC)
Apparently there are 7 such files: Category:Gpx_data. They are the only articles that are not human-readable, so if they stay I will have to modify the algorithm of OxygenGuide, the offline Wikivoyage. Nicolas1981 (talk) 12:34, 15 August 2013 (UTC)
I think it would be good if they had their own naming such as GPX:pagename. --Traveler100 (talk) 16:01, 15 August 2013 (UTC)
Sorry, could someone explain what GPX is and what it does? Texugo (talk) 16:24, 15 August 2013 (UTC)
They are for drawing a path or route on a map. For example on the page Rheinsteig click the map icon top right; the blue line marking the hike trail is defined by the gpx file. On Winnipeg I believe it is marking the neighbourhoods on the map. --Traveler100 (talk) 16:34, 15 August 2013 (UTC)
I think they should get a separate namespace, or be moved to a shared repository like Wikidata or Commons. I can envision loads of these existing in the future (unless we come up with a better way to pull up article boundaries for dynamic maps), and they don't belong in the mainspace. --Peter Talk 00:53, 16 August 2013 (UTC)
I wanted to try moving Winnipeg/Gpx to GPX:Winnipeg, but even before moving it seems that the track is not displaying correctly, there is probably a bug right now. Let's try again when things are working properly, so that we can make sure we did not break the feature. Nicolas1981 (talk) 07:52, 16 August 2013 (UTC)
It displays fine for me. What problem are you seeing? --Peter Talk 08:36, 16 August 2013 (UTC)
Oh yes, it is working :-) Nicolas1981 (talk) 09:09, 16 August 2013 (UTC)

First, are we OK that for now GPX files should be moved from Sometown/Gpx to GPX:Sometown? If we agree on this, I guess it can be done quickly. The path is configured in the PHP script at this line: https://github.com/nicolas-raoul/PoiMap2/blob/master/poimap2.php#L121 , so this would need to be modified at the same time as the pages are moved, by Joachim I guess because only him can modify the PHP script. Nicolas1981 (talk) 09:14, 16 August 2013 (UTC)

Don't we need to get GPX configured as a namespace first? LtPowers (talk) 13:05, 16 August 2013 (UTC)
'GPX:Sometown', I think is a good solution. If the files are moved, I will adjust the path immediately. Please note [59]. -- Joachim Mey2008 (talk) 16:45, 16 August 2013 (UTC)
You are right, LtPowers! Does anyone here have the ability to create the GPX namespace? Or do we have to create a Bugzilla ticket? Rather than pesting the already-busy WMF staff, how about using the "Module" namespace until we have a solid base of GPX tracks? I also asked at Commons. I just realized that visitors click "Random page" they might land on a GPX file, which is not a great thing. Nicolas1981 (talk) 07:21, 19 August 2013 (UTC)
Another option is to save the GPX files in the File:namespace. Here is an example.[60] -- Joachim Mey2008 (talk) 17:39, 19 August 2013 (UTC)
What do people think of this? I'd really like to hear more opinions. The advantage of using the filespace is that we already have it, and that would be simple. Using a new gpx: namespace would be cleaner, and possibly help us keep better track of uploads (which we mostly don't want at present). Putting the GPX files on Commons might solve both problems, but that means we'd have to deal with their cumbersome upload process each time we want to edit one... Actually, that's probably the best reason to create a GPX namespace, which would allow us to keep guides and map paths information separate, while still allowing easy editing. --Peter Talk 20:12, 19 August 2013 (UTC)
I haven't followed the specifics of "GPX" development, but if there is any chance of sharing these files across language versions let's just use "File" and upload them to Commons. If they are always language specific then a new namespace would make sense if there are going to be thousands of these files and they aren't going to be replaced by a different technical solution in 1-2 years. If we're only talking about a few hundred files, or if there is a chance something new will replace them in 1-2 years, let's re-use an existing namespace. -- Ryan • (talk) • 20:34, 19 August 2013 (UTC)
Text files aren't usually considered to be in scope at Commons. This may be a special case, but it'd have to be approved by the community first, I think. LtPowers (talk) 21:42, 19 August 2013 (UTC)
People at Commons seem to agree with the idea, and created this Mediawiki enhancement request. It will probably take time, though. I don't know how I managed to miss the "File:" namespace, that's obviously where GPX files belong until Commons can receive them :-) Nicolas1981 (talk) 01:44, 20 August 2013 (UTC)
I tried to upload Winnipeg.gpx here, but I receive an error: "Permitted file types: png, gif, jpg, jpeg, tiff, tif, xcf, pdf, mid, ogg, ogv, svg, djvu, ogg, ogv, oga, flac, wav, webm.". Moving to the "Module" namespace does not work either: "The desired destination uses a different content model. Can not convert from wikitext to Scribunto.". Moving to "Template" worked: Template:Winnipeg/Gpx. It is clearly a dirty hack as GPX are not templates, but I think it is better than displaying non-readable XML as articles. Any opposition to moving all GPX files to "Template"? Nicolas1981 (talk) 05:44, 22 August 2013 (UTC)
I uploaded a GPX file in the files name space [61]. This is somewhat cumbersome. It needs to be uploaded first a PNG. Later, the GPX data can be inserted into the section "GPX". - The template name space seems easier to handle with. -- Joachim
No problems with me either way. It'll be at Template:Gpx/Winnipeg though. There's a lot of KML files (possibly Google traced though) at Wikipedia too, no idea whether depositing them at Commons or a filespace was ever brought up. -- torty3 (talk) 13:26, 28 August 2013 (UTC)
If they are going to be in the Template namespace, can we set up a category and get in the habit of using so that a complete list of these files can more be easily found? Texugo (talk) 13:43, 28 August 2013 (UTC)

ShareMap - Wikimedia grant endorsement needed[edit]

Hello, WikiVoyagers ShareMap is a collaborative map creation tool (already mentioned at this page). It is currently applying for Wikimedia grant to continue project development. One of ShareMap principles is preparing map authoring usable for WikiVoyage authors and readers (even if it is not very project in Wikimedia scale, we really believe in its success).

ShareMap already implemented some experimental features that is dedicated for WikiVoyage authors:

But there is still lot to do.

One of grant results will be creation free mobile off line map viewer application for maps created by Wikimedia community.

I will be very happy for endorsement, opinions or even criticism from all WikiVoyage community member on Wikimedia grant project.

meta:Grants:IEG/ShareMap#Part_3:_Community_Discussion

If you would like to learn more about ShareMap project please visit:

--Jkan997 (talk) 10:35, 15 October 2013 (UTC)

English in OSM maps[edit]

Swept in from the pub

My article about Mitzpe Ramon has an embedded map as well as a link to an external one, but the street names in these maps are shown in Hebrew. They use the Mapnik (OSM) layer; now, Open Street Map does have both a Hebrew and an English entry for all of these streets, only the default display name is the Hebrew one. I've tried changing the default name over at the OSM website (which is a sort of a wiki), and it did solve the problem, but it turned out that I acted against their policy and my edits are about to be reverted (so right now, the streets in the northern half of the town do appear in English, but that will be changed back to Hebrew pretty soon). Can anyone who's familiar with the implementation of these dynamic maps provide some help about this? I did notice that the dynamic maps' URL does have a lang=en in the address, but that doesn't seem to work as I've expected. If it's of any help, one helpful user at OSM did point out that the address " http://toolserver.org/~osm/locale/en.html?zoom=16&lat=30.61189&lon=34.80542&layers=BT " does show the names in English. Tamuz (talk) 12:27, 13 September 2013 (UTC)

"lang=en" simply means that your POIs are read from English Wikivoyage, it has nothing to do with the map itself. The link to the map should be changed by the map developer. --Alexander (talk) 12:41, 13 September 2013 (UTC)
There is no function for it now. The link to the map should not be changed because the toolserver is not stable enough and is very slow. WMF are setting up a production server themselves, but no promises on the timeline. Once they get it set up, we will be able to get English names on English Wikivoyage, and Hebrew names on Hebrew Wikivoyage. See the Dynamic maps expedition and Wikivoyage/Wishlist. I suppose it should be made clearer on the "how to" guide? -- torty3 (talk) 13:34, 13 September 2013 (UTC)
Related discussion: Wikivoyage_talk:Dynamic_maps_Expedition#Shanghai_map. Pashley (talk) 13:54, 13 September 2013 (UTC)

Old WV logo on map page[edit]

Swept in from the pub

Not sure who can take care of this, but when you click from the map icon on any destination page to bring up the full page dynamic map, they have changed the WV logo in the bottom right corner to the new logo, but the logo which appears in the browser tab is still the old one. It doesn't seem to be just my cache, as far as I can tell. Texugo (talk) 23:36, 21 September 2013 (UTC)

Confirmed. Should be a simple fix by the maintainer. LtPowers (talk) 00:59, 22 September 2013 (UTC)
I changed the favicon. Maybe it is necessary to clear the cache or the reload the page. --RolandUnger (talk) 06:17, 23 September 2013 (UTC)

Decision on Maps?[edit]

A complaint about map illegibility was made on the Okayama talk page in regards to the static map, to which I replied. About an hour later, a Dynamic map was added with no additional comments about the other map.

I remembered talk about the dynamic maps but I didn't remember if a decision had been made regarding whether or not they were meant as quick-fixes for maps without static maps or whether the static maps were being phased out so I tried to find out and ended up here however, there doesn't seem to be an answer. This expedition claims they "coexist" with nothing more said about the topic as far as I can find. Here on the talk page the general opinion seems to be mostly against static maps (with the exception of LtPowers) and for dynamic maps, but the issue was left unresolved and the dynamic maps were plunged forward.

Now the Okayama page has two maps that, once the dynamic map is more filled out, will essentially show the same thing, although the dynamic map will end up less magnified once the full range of listings are added. Is this the "coexistence" referenced on the expedition? Do we want two maps on every page? ChubbyWimbus (talk) 07:37, 25 November 2013 (UTC)

Hi ChubbyWimbus. I provided feedback about the map, and I need some time to carefully consider your response (That is what I believe the discussion page is for). Presently I am open to your response.
I did not change the map to a dynamic one. The conversation should continue on the talk page before such action is taken. In your position I would reverse the dynamic map edit right away. Andrewssi2 (talk) 07:47, 25 November 2013 (UTC)
I did not mean to imply blame in the addition of the map. I only mentioned the talk page comments because I assumed that is what inspired the map addition in the first place. I would have reverted the addition of the map, but after reading the discussions above, I could not myself determine whether the addition of the map is actually unwanted. Both this expedition and the map creation expedition exist, and that expedition has not been updated to acknowledge this one. As I said, the only thing the expedition (this one) states about it is that the two maps "coexist". That's why I came here for clarification. ChubbyWimbus (talk) 11:46, 25 November 2013 (UTC)
I think it's fair to say that policy on this front is unsettled. You and everyone else are charting new territory. Personally speaking, I would never remove a good hand-crafted static map in favor of a dynamic, auto-gen map, but I might do the opposite, depending on the quality of the maps involved. Sometimes keeping both might be warranted. LtPowers (talk) 22:04, 25 November 2013 (UTC)
I don't think anybody is "against static maps". I am a big maps lover, for both static or dynamic ones. A good static map provides a great overview, a skilled Wikivoyager is able to highlight the touristic places and label in preference the touristically-interesting streets. Dynamic maps are aiming at reaching the same level, but there is still a lot of work to do. Nicolas1981 (talk) 01:28, 29 November 2013 (UTC)

Mixed-SSL-content problem again?[edit]

I am getting the SSL mixed content block problem again, with Firefox 25.0.1. Have our embedded maps changed? Or has Firefox become even stricter than before? Nicolas1981 (talk) 10:43, 9 December 2013 (UTC)

I also use FF 25.0.1. I have no problems with mixed content. Neither in HTTP still in HTTPS mode. -- Joachim Mey2008 (talk) 06:05, 10 December 2013 (UTC)

Are we ready to start deploying dynamic maps across the site?[edit]

Currently Special:WhatLinksHere/Template:Mapframe shows only 449 uses of dynamic in the main namespace. From what I can gather, even individuals who dislike dynamic maps have stated that an article with a dynamic map is better than an article with no map at all (correct me if I've misunderstood), so are we ready to deploy these more widely across the site? Texugo proposed the following suggestions for deploying dynamic maps above (paraphrased):

  1. For now, deploy dynamic maps only for destination articles at the bottom of the hierarchy (city or district articles) since region, huge city, and country articles use maps to show geographic divisions, something dynamic maps do not currently handle well.
  2. Put the map at the top of the "Get around" section (note: a lot of maps appear at the top of "Get in", so it would be good to come to an agreement).
  3. Use the default map size.
  4. Use only one map (for now). If an article already has a static map then don't add a dynamic map - that is a much more contentious discussion that can be saved for later.

A map is an instant way to dramatically improve many of our articles, so unless there are objections or reasons not to do so, I think it is time to deploy them more widely across the site. -- Ryan • (talk) • 17:01, 4 January 2014 (UTC)

Step one, which I think is largely done, is to get geo tags into articles so we automatically get a dynamic map link up at the top. I often check those on various articles I'm editing; I occasionally find bad co-ordinates and quite often incorrect zoom. I'd say the first priority is to make sure the geo tags are all present and correct. We might also discuss ways to make the link more obvious; I doubt that readers unfamiliar with the site are likely to notice the current icons.
As for adding other dynamic maps, it sounds like a good idea though I am very much of the opinion that the above comes first.
The only other concerns I'd have are the language problem (#Shanghai map and #English in OSM maps above) and whether metro or other public transit routes can be shown. Pashley (talk) 18:12, 4 January 2014 (UTC)
Making a considered decision to add a carefully oriented dynamic map to a specific article is one thing, but adding them systematically across the board is a more difficult question. I remain concerned that large-scale systematic addition of dynamic maps will depress interest in proper mapmaking, as articles will cease to appear "incomplete" in the absence of a good Wikivoyage-style travel map. I fear that would detriment the site in the long-term. Powers (talk) 18:45, 4 January 2014 (UTC)
@Pashley: The layer N = Traffic line network already displayed all subways, commuter trains, bus lines etc (all public transport). Including line numbers and names of the stops. The data must only be contained in OSM. -- Joachim Mey2008 (talk) 14:23, 5 January 2014 (UTC)
@all: Static maps can be updated only by a few "specialists". This has a negative effect to the article text. I have previously drawn many static maps. After five years, 50% of the hotels, restaurants and bars were changed. No one dared the complicated updating of static maps. The articles were therefore not updated and remained at the level as five years ago. That was the main reason why I programmed the dynamic map. Those automatically correspond with the current article text. This aspect should also be noted. - Joachim Mey2008 (talk) 14:57, 5 January 2014 (UTC)
Given the concerns of Powers and Pashley, would it be acceptable to add a "Stage 3" to update Wikivoyage:Dynamic maps Expedition#Test to reflect that a broader manual deployment of dynamic maps (and not an automated large-scale deployment) is now acceptable, leaving in place the existing guidance about adding missing {{geo}} coordinates where needed? I am envisioning two bullet points, and the same "known issues" as stage two:
  • Manually add maps to articles where an editor feels that a dynamic map would be beneficial and would not be adversely affected by known issues using {{mapframe}}. Guidelines for adding a dynamic map:
    1. Only add dynamic maps to articles at the lowest level of the article hierarchy (city or district).
    2. Add the dynamic map to the top of the "Get around" section.
    3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
    4. Use the default map size (width/height). Zoom should be modified as appropriate.
    5. Do not add more than one dynamic map without discussion on the article talk page.
  • Update {{listing}} tags with appropriate lat/long coordinates as outlined in Wikivoyage:Dynamic maps Expedition#Sub-expedition: Fill all the latitudes!.
I believe that would provide some implementation guidelines that would let us formally move ahead with these maps while addressing the concerns above. -- Ryan • (talk) • 17:53, 5 January 2014 (UTC)
That seems like a reasonable compromise. Powers (talk) 19:25, 5 January 2014 (UTC)
Adding dynamic maps only where there's no static map, only once co-ordinates exist in most individual listings would be reasonable. Certainly there's no use in a map with only one POI, or none at all. Requiring the map be in "get around" may be awkward if the article already has photos in or near that section which would need to be moved to make space. It might be worth looking at fr:modèle:Info Ville (a quickbar-like template for cities which has the map, a photo of the town and info such as region, population/area, telephone prefix and postal code); fr:Lac-Mégantic has an example of this. The default map scale might not work well for huge rural regions (like Anticosti), not sure if this was what you meant by "map size". Leaving regions to be dealt with separately is reasonable as the points of interest in a region are cities, not individual listing venues. K7L (talk) 19:22, 5 January 2014 (UTC)
I've clarified the "map size" comment (width/height should use the default, zoom can be whatever works best). As to articles with only one POI, I still think the map is useful as it shows roads and nearby cities, but if others feel that maps should not be used unless there are multiple POIs then we should discuss. Regarding "Get around", I actually prefer putting the map at the top of "Get in", but think we should standardize if possible and "Get around" had been suggested previously. As to quickbars, general consensus has been against them in the past, so it may be better to save that discussion for another time and just focus on a basic map rollout for now. -- Ryan • (talk) • 19:33, 5 January 2014 (UTC)
The appropriate location for the map depends on the specifics of each article. Some destinations have more complex Get In information than Get Around information; others are the other way around. In addition to the obvious layout issues resulting from these differing section lengths, it also points out that sometimes the map is more needed for one purpose than for another. Powers (talk) 02:08, 6 January 2014 (UTC)
@LtPowers: is right in suggesting that map positioning is best left to independent editor judgement in each individual article. Default width (ie, unspecified - like thumbnail width) is best in many cases, but there are quite a few conurbations (and even countries like Chile) that are long and narrow and benefit greatly from having a larger height. Equally, "wide" areas may benefit from having a reduced height.
What's the reasoning behind suggesting "Do not add a dynamic map when a Wikivoyage-style static map is already present", please? --118.93.235.201 04:38, 6 January 2014 (UTC)
I believe that idea comes from Powers's assertion that "A good cartographer can beat a computer every day of the week and twice on Sundays". He is correct. However the amount a 'good cartographers' we have available is limited, and not all static maps are created to such a high standard, or current.
If I want to add a restaurant listing to an established article then there is no way I can gain ready access to the source of the original static map, and unrealistic that most contributors would know how to even if they had. With a dynamic map I just need to add the latitude and longitude to the listing and I'm done. Andrewssi2 (talk) 05:16, 6 January 2014 (UTC)
Likewise, the number of good writers we have available is also limited; does that mean we should begin relying on computers to generate prose for us as well? Powers (talk) 19:38, 6 January 2014 (UTC)
This is a case of User:LtPowers vs. the world. It is quite obvious he stands steadfast by his POV, and that everybody else does not share it. Let's move on, there really aren't many editors here, so wasting time on beating a dead horse is the last thing we should do. I keep deploying Dynamic Maps in articles and see no reason why we should refrain from doing so. Happy deploying, editing and finding latlongs! PrinceGloria (talk) 07:19, 7 January 2014 (UTC)
PS. There are always many considerations as to where to put the map in a specific article, but I believe it helps avoid unnecessary hangups and discussions to agree to have them at "Get around". Specific cases can always warrant an exception, this is not law, just a useful guideline.
PS2. Width and height should absolutely be left out to individual decisions though. They should serve the particular map best, every area has a characteristics and POI distribution. Even advising of "ideal" height/width would be unnecessairly confusing matters. The map should be legible and encompass the entire area of the article with all POIs, if possible, and this determines the height/width and zoom level.
I don't feel the counterpoint for having 'good editors' is fair. The technical bar to come on WV and start writing content is very low, regardless of one's ability with prose. Designing maps is a different kettle of fish altogether requiring good knowledge of A) Mapping software and B) Drawing software.
Even if you can use the software then you still can't easily obtain the original drawing files, meaning a new map would have be drawn each and every time (although SVG format may get around this). Andrewssi2 (talk) 08:41, 7 January 2014 (UTC)
Although I very much agree the esthetics of hand-drawn maps is much superior when done by an experienced mapmaker, I don't see how we could keep the destination article maps up-to-date. For that we should fully use the potential of dynamic maps. On region & country level the hand-drawn maps still have no competitor in dynamic maps and I believe this is where we should concentrate the mapmaking effort. Danapit (talk) 08:57, 7 January 2014 (UTC)
Agreed. This isn't an argument about the whether dynamic maps are inherently better than static or vice-versa. The dynamic maps are providing a good deal of value already to articles that have no forseeable prospect of getting a hand crafted static map, and some articles experiencing high amounts of listing updates also benefit from this new approach. Andrewssi2 (talk) 09:15, 7 January 2014 (UTC)
Yet again, my opinion on this site appears worthless. Lovely. Powers (talk) 18:50, 7 January 2014 (UTC)
Powers, the statements above were not against you, and I do not read anyone here inferring that your opinion as worthless. I certainly value your opinions. Andrewssi2 (talk) 04:24, 9 January 2014 (UTC)
I don't know how else to interpret "This is a case of User:LtPowers vs. the world. ... Let's move on,..." Powers (talk) 20:02, 9 January 2014 (UTC)
OK, I'd agree that it rather dismissive. Please bear in mind that PrinceGloria does use her distinctive style quite widely and I choose not to take it personally myself. Andrewssi2 (talk) 00:58, 10 January 2014 (UTC)
I certainly got my fair share now that I got to be referred to as "her". Thank you so much, gentlemen (presumably). PrinceGloria (talk) 15:42, 10 January 2014 (UTC)
Sorry PrinceGloria. I had assumed (incorrectly?) your gender purely based on the second part of your name. Andrewssi2 (talk) 15:18, 12 January 2014 (UTC)

I for one, certainly don't feel your valuable and insightful opinions are worthless.

However, consensus does not mean veto and I do feel that your concerns have been adequately addressed in this discussion, Lieutenant.

Few would doubt that loving care and attention can produce beautiful and useful static maps and these will usually be better for printing out and using when off-line. I assume that GPX traces can be used to show the irregular boundaries of regions and the highlights of countries and most of our users find the ability to pan and zoom our dynamic maps a great feature when on-line.

We should not let "the best" ever become the enemy of the "very good and useful" and, for an ever-changing wiki like ours, any static map is very quickly going to become incomplete, if not outdated.

My original question was What's the reasoning behind suggesting "Do not add a dynamic map when a Wikivoyage-style static map is already present", please? and this has not been answered by you or Ryan, so I will assume that this is not good advice, since I can not guess why the presence of a static map interferes with or makes redundant a dynamic map (or vice versa). --118.93.244.91 22:11, 7 January 2014 (UTC)

I've added Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment to reflect the proposal and discussion above, making clear that the top of "Get around" is the preferred location, and that the default size is preferred, but that if there are specific reasons for using a different size or location then that is acceptable, provided the reasoning is explained. -- Ryan • (talk) • 03:39, 9 January 2014 (UTC)
I removed the part you added that read "Do not add a dynamic map when a Wikivoyage-style static map is already present." since the consensus immediately above seems clearly against that and no rationale for this has yet been advanced despite continued requests. --118.93.244.91 04:04, 9 January 2014 (UTC)
@Wrh2: why are you edit warring about this?
Nobody that I have read above is suggesting removing Static maps when a Dynamic map is added, but I fail utterly to see where anybody (other than you in a faux "summary") has ever proposed that Dynamic maps should be removed when added to an article that already contains a Static map. Each, as many have pointed out, have their own specific advantages and one type should neither mandate nor prohibit the dployment of the other. Even Powers wrote above "Personally speaking, I would never remove a good hand-crafted static map in favor of a dynamic, auto-gen map, but I might do the opposite, depending on the quality of the maps involved. Sometimes keeping both might be warranted" at 22:04, 25 November 2013 (UTC).
--118.93nzp (talk) 05:52, 9 January 2014 (UTC)
I think that we need to be clear that the instruction only refers to those static maps that were created for WV. There are also static maps that were originally created for WP that might be good candidates for replacement. For example Eriskay has a static map that I added last year before dynamic maps were available, and I think that this would be best replaced with a dynamic one. On the other hand, Harris has a static map which although not good, does make an important point clear; in this case I would like to add a dynamic map to supplement this. Both of these maps were originally originally created for WP, but were added on the basis that an inferior map was better than no map. AlasdairW (talk) 23:22, 9 January 2014 (UTC)
The current guidance states "Do not add a dynamic map when a Wikivoyage-style static map is already present" since we are far from any agreement or plan for replacing existing Wikivoyage-style maps. However, for static maps that weren't specifically created for Wikivoyage in accordance with the guidance on Wikivoyage:How to draw a map I think it is up to the individual making the replacement whether the existing static map should be replaced (or supplemented) by a dynamic map. -- Ryan • (talk) • 00:08, 10 January 2014 (UTC)
I created a 'Wikivoyage stlye' map for the Haeundae article, however I came to the conclusion that owing to the density of many POI's it should be supplemented by a dynamic map. I think this works well, although it doesn't fit with the guidance "Do not add a dynamic map when a Wikivoyage-style static map is already present." Andrewssi2 (talk) 00:58, 10 January 2014 (UTC)
I'll leave it to others to have that battle as the initial "stage 3" proposal was meant to provide a path forward for deploying dynamic maps in more articles without upsetting individuals who have expressed their preference for static maps, and it survived a week's worth of discussion without too much dissent. Eventually we'll have to deal with that issue, but for now my hope was that we could just come to some agreement on what the next step should be. -- Ryan • (talk) • 02:27, 10 January 2014 (UTC)

OK, now I'm really miffed.

I've asked several times for the diffs to show where the discussion was that sanctioned the fourth commandment: "Do not add a dynamic map when a Wikivoyage-style static map is already present." since the consensus immediately above seems clearly against that. No rationale for this has yet been advanced despite continued requests to Wrh2/Ryan. Instead, his only response has been to leave a banning template notice on the talk page I use. He speaks about "the guidance" like his faux summation is written on tablets of stone, but I thought this is where we actually generate such policies - not discuss something on a plate that has been served up pre-digested by Ryan. This is supposed to be a wiki and I'd like to be told RIGHT NOW precisely why I can't add dynamic maps to articles that already have an out-dated and largely useless Wikivoyage style static map! --118.93nzp (talk) 01:56, 11 January 2014 (UTC)

Map of all destinations in a country, with labels[edit]

Swept in from the pub

I am going on a trip without much preparation, and what I really feel the need for is a map that shows all destinations of the country, so that I can see where the interesting stuff is.

The nearest thing I have is this: http://www.cheriot.com

Because most of the time I won't be connected to the Internet, I took screenshots of the map, but the fact that you have to click on a icon to make its name appear makes the images less useful. Is there a website/mashup where destination names are visible as labels? The rendition algorithm for optimal label display (or non-display in crowded areas) is tricky to develop, but it would be very useful, and may be used as a switch on POI maps too.

Cheers! Nicolas1981 (talk) 12:15, 31 October 2013 (UTC)

That site does not load for me. Texugo (talk) 13:04, 31 October 2013 (UTC)
Quite slow but works for me here... maybe because I am logged in already? Nicolas1981 (talk) 06:44, 1 November 2013 (UTC)

Calculating map zoom level from Wikidata[edit]

Swept in from the pub

If all goes well, place items will soon include a "diameter" value that describes "rough diameter of the object in meter, used for selecting the scale of the map and for uncertainty of an area".

Converting this diameter to a Google Maps-type zoom level will probably be implementable in Lua using one of the algorithms suggested as solutions to this question: http://stackoverflow.com/questions/6048975/google-maps-v3-how-to-calculate-the-zoom-level-for-a-given-bounds

Cheers! Nicolas1981 (talk) 06:09, 9 September 2013 (UTC)

Dynamic Maps no longer shown with FireFox browser (SOLVED: Windows 8.1 issue)[edit]

I'm using Windows 8.1 (64 bit) and Firefox (version 26) and am now seeing the following error message where the dynamic map should be:

"This Connection is Untrusted You have asked Firefox to connect securely to tools.wmflabs.org, but we can't confirm that your connection is secure." "tools.wmflabs.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)"

Using Internet Explorer 11 does not have the same issue (yay MS security!)

Do we know how to fix this? Andrewssi2 (talk) 09:56, 20 January 2014 (UTC)

I guess we need to bother Joachim for the billionth time... FYI to the fixer; on Mac the dynamic maps do show up with Firefox version 26.0. ϒpsilon (talk) 10:18, 20 January 2014 (UTC)
It works on Internet Explorer for Windows Phone 8 and on Google Chrome for the Samsung Galaxy Tab 2 tablet.
It also works fine under Windows 8.0 with Google Chrome 32.0.1700.76
The issue seems restricted to Firefox. Has anyone else tried the dynamic maps with Firefox for Windows? Andrewssi2 (talk) 10:32, 20 January 2014 (UTC)
I am using Firefox 26.0 under Windows right now and have no problems with displaying Dynamic Maps. Neither do I with Firefox on MacOS. PrinceGloria (talk) 10:37, 20 January 2014 (UTC)
Win7 + Firefox 26.0 = no problem. Danapit (talk) 10:39, 20 January 2014 (UTC)
Hmm... Andrew is AFAIK currently based in China, where the connections can be insecure now and then; you can probably guess what I mean. ϒpsilon (talk) 10:53, 20 January 2014 (UTC)


@Andrewssi2: You may have enabled SSL scanning in your security software such as ESET or BitDefender. Try to disable this option. (compare mozilla support). Please read the section "The certificate is not trusted because no issuer chain was provided". I hope this helps. - I have also successfully tested many browsers / operating system combinations. -- Joachim Mey2008 (talk) 11:11, 20 January 2014 (UTC)
I just restarted and exact same issue. I will have a look into the trouble shooting later. Interesting since this configuration worked yesterday. And yes, I 'may' have a 'great firewall' issue in China :) Andrewssi2 (talk) 11:14, 20 January 2014 (UTC)
OK, slowly getting to the bottom of this. I just tried my work laptop (Windows 8.0, FireFox 26) and it works fine!
I actually installed Windows 8.1 on my personal laptop on Sunday, and it 'might' just be the combination of Windows 8.1 and FireFox 26. (I guess a lot of MS security fixes that affect FireFox in some way) I'll keep digging. Andrewssi2 (talk) 11:42, 20 January 2014 (UTC)
It does seem to be a Windows 8.1 issue. https://support.mozilla.org/en-US/questions/983227
The suggested fix is to import the certificate directly. Does anyone know where I can get the wmflabs certificate in Base64 text?
Otherwise I just use Internet Explorer in the meantime :) Andrewssi2 (talk) 12:01, 20 January 2014 (UTC)
I'm using Chrome on Windows 8.1 and I'm seeing this same issue. Powers (talk) 18:38, 20 January 2014 (UTC)
Hi Joachim, is there anyway we can get someone to look at the certificate on wmflabs in order to ensure there are no issues on that side?
I believe Windows 8.1 will become more prevalent during 2014, and many contributors (both experienced and new) may come to the conclusion that Dynamic Maps are broken. I don't think they are going to search this site to find this discussion or want to implement workarounds. Andrewssi2 (talk) 00:29, 21 January 2014 (UTC)

Sorry to bother the Dynamic map team again...[edit]

For maps that are embedded in articles (e.g. in Milan and Cologne and on this very page) this is what I see:

"Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, mpelletier@wikimedia.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.2.22 Server at tools.wmflabs.org Port 80"

Both when using Safari and Firefox. But the maps that open when clicking on the icon in the upper right corner work normally. Strange. ϒpsilon (talk) 16:57, 20 January 2014 (UTC)

Unfortunately, the same problem occurs more frequently. It was discussed right here. We use two servers. But for the mapframe-server we'll have to find more reliable replacement. - Joachim Mey2008 (talk) 17:49, 20 January 2014 (UTC)
I see. It's really a shame that the map system you've put a lot of effort in isn't available just because of some server malfunctioning :P. ϒpsilon (talk) 17:59, 20 January 2014 (UTC)
Did you send a mail again? Because now it shows up normally at least in User:Ypsilon/Milan. Yippie! ϒpsilon (talk) 18:04, 20 January 2014 (UTC)
I just wanted to send an email. But with my knowledge of English that always takes some times with google translate Icon redface.gif. -- Joachim Mey2008 (talk) 18:16, 20 January 2014 (UTC)
And now the error is back :(. And in the thread above LtPowers reports similar problems that Andrewssi2 had earlier today. Something is wrong – big time.
Schade dass torty3 jetzt nicht hier ist. Ich könnte vielleicht es versuchen den Mail zu übersetzen. ϒpsilon (talk) 19:06, 20 January 2014 (UTC)
And now it works normally again... ϒpsilon (talk) 20:19, 20 January 2014 (UTC)
To be fair, I think the certificate issue I have is an existing problem that simply hasn't been apparent because the operating system in question (Windows 8.1) has been available only recently. Andrewssi2 (talk) 00:54, 21 January 2014 (UTC)

Problems with mapframe[edit]

For the application "mapframe" I had to pull the emergency brake. The problems with tools server and certificates must first be solved. Only User:Torty3 can help at this time. Unfortunately I do not have access to the tools server. - Joachim Mey2008 (talk) 05:36, 21 January 2014 (UTC)

Many thanks for taking ownership of the problem Joachim
Just to ask the question.. have we considered just going directly to http://www.openstreetmap.org rather than go through http://maps.wikivoyage-ev.org/ ?
I realize such a change would not be trivial, although it seems our reliance on the wikivoyage-ev.org server is presenting a real risk to the dynamic maps initiative. Andrewssi2 (talk) 05:44, 21 January 2014 (UTC)
My understanding is that it is the server at tools.wmflabs.org that is problematical not maps.wikivoyage-ev.org, Andrew - or have you had problems with both Mapframe and the full screen dynamic map? --118.93nzp (talk) 06:10, 21 January 2014 (UTC)
Wikivoyage eV is a registered non-profit association in support of Wikivoyage. I do not see any risk for the project. - The application PoiMap2.php for map display is a short script that runs on that server. The WV.eV server (for full screen map) is highly reliable. Map tiles are not stored there. Tiles are already sourced directly from OSM or Mapquest. - Joachim Mey2008 (talk) 06:28, 21 January 2014 (UTC)
Actually, I am not familiar with the architecture of Dynamic Maps. I posed this question with the intent of discussing the architecture and how we can reach a reliable solution. Full screen maps do appear to work fine.
If the WV.eV server is reliable then how can we get better control of the component running on tools.wmflabs.org? It seems to me that we are dependent on one person volunteering to fix this script whenever they have time Andrewssi2 (talk) 06:33, 21 January 2014 (UTC)
The problem is not the script but the Tools-Server. They are running many applications at [62]. If one of these applications is faulty, the entire server fails - and often. We need for mapframe (HTTPS) a more reliable server. - For cost reasons, no HTTPS is possible on the WV.eV server. -- Joachim Mey2008 (talk) 06:43, 21 January 2014 (UTC)
And is there any discussion around moving 'to a more reliable server'? Andrewssi2 (talk) 06:56, 21 January 2014 (UTC)
Hi Joachim , is there a forum for this? I'm happy to discuss in German if it is hosted on a German community site. Andrewssi2 (talk) 00:36, 23 January 2014 (UTC)
I have found a way to greatly reduce the server load. This applies to dynamic maps with many markers. I think then the Tools-Server could be sufficient. I need to change something in the script. This will take about two weeks (due weekly update of the tools server). - I believe that User:Torty3 already discussed the need for a server change. A forum on this issue do not exist. I'm waiting for the return of User:Torty3 to this discussion. - Joachim Mey2008 (talk) 05:44, 23 January 2014 (UTC)
Thanks Joachim . I think WV can easily survive a couple of weeks without dynamic maps.
I assume however the Firefox/Windows 8.1 issue will not be resolved by this?
This is because the problem is down to the absence of a certificate on the map server? Andrewssi2 (talk) 10:48, 23 January 2014 (UTC)
About the topics of SSL/certificates/HTTPS I have no specialist knowledge and can not help. -- Joachim Mey2008 (talk) 05:20, 25 January 2014 (UTC)
So how can we progress? The issue currently only affects a minority of users (Chrome/Firefox under Windows 8.1 specifically) however what can we do when new updates are issued and more people are affected? Andrewssi2 (talk) 07:44, 25 January 2014 (UTC)

Dynamic map issue solved - can we turn back on?[edit]

I just took a look at this French WikiVoyage article:

https://fr.wikivoyage.org/wiki/Gongju

And the dynamic map is not just working fine, but it is working fine with Firefox in Windows 8.1 !

Does this mean everything is fixed and we can have our beloved dynamic maps back? :) Andrewssi2 (talk) 05:25, 29 January 2014 (UTC)

We should wait for the latest script update. I hope Torty3 (the only admin) will do that in the next few days. He is unfortunately inactive for last six weeks. - The new version has reduced read and write accesses, and less load on the server. - Joachim Mey2008 (talk) 08:08, 29 January 2014 (UTC)
OK, but can you at least confirm that the Windows 8.1/Firefox/Chrome certificate issue is now resolved? Andrewssi2 (talk) 08:20, 29 January 2014 (UTC)

The Mapframe/embedded Dynamic maps are having a bad day once again?[edit]

Instead of seeing a map this is what I get: "Bad request Your browser sent a request that this server could not understand."

However the maps that are opened by clicking on the icon do work normally. ϒpsilon (talk) 10:16, 16 February 2014 (UTC)

Yup, I am also seeing "Your browser sent a request that this server could not understand." in Firefox. (Windows 8.1) Andrewssi2 (talk) 12:26, 16 February 2014 (UTC)
The only admin for the mapframe server (https://tools.wmflabs.org/) is User:Torty3. But he is no longer active since December 2013. This seems to be a bigger problem. I can not help, I have no access to that server. - To the server for full-screen maps (http://maps.wikivoyage-ev.org/) users RolandUnger, DerFussi and Mey2008 have access. -- Joachim Mey2008 (talk) 07:09, 17 February 2014 (UTC)
There is only one admin who handles the mapframe server? That's astonishing. There should never be a program that depends on only one person. Ikan Kekek (talk) 07:37, 17 February 2014 (UTC)
Joachim, what happens if you start another server at tools.wmflabs.org and share access with several other people? --Alexander (talk) 08:14, 17 February 2014 (UTC)
The maps seems to be working again now, although this episode has shown us that we have a serious issue. If there is only one admin then we need to remove this weak point as soon as possible.
Although Wikivoyage is a community effort, we need a more professional SLA (Service Level Agreement) in place. Otherwise I would have to come to the awful conclusion that we should retire Dynamic Maps for now. I think the majority of the WV would hate for that to happen.
Can the problem be fixed by recreating the service as Alexander suggests, or is there something more fundamental in wmflabs.org causing this? Andrewssi2 (talk) 08:19, 17 February 2014 (UTC)
I think that this discussion goes in circles. There is a fundamental problem that tools.wmflabs.org is not very stable. One has to make it more stable (that we likely can not do), or create another map server with the proper SSL certificate. I think that we need a comment from a person who knows how to do it, and we need a comment only from this person, because someone has to make this effort. It is bloody clear that Wikivoyage needs stable dynamic maps, but repeating this statement again and again will not solve the problem.
Another account at tools.wmflabs.org could be an interim solution, if Joachim thinks that full access to the server may help. --Alexander (talk) 08:31, 17 February 2014 (UTC)
It is hardly circular. It is a simple question (that has yet to be answered) which is whether the wmflabs.org server should not be used any longer for Dynamic Maps. If the answer is yes then we can move on to discussing alternative mapping solutions.
I do have a technical mapping background actually (a commercial product called ESRI) and I do know that a new solution will take a lot of work. Therefore I do want the first question answered in the first instance. Andrewssi2 (talk) 08:46, 17 February 2014 (UTC)
Is it seriously just Torty3 who has access to the server? I think it would be obvious to give access to a couple of other persons who have knowledge and time to do something about this recurring problem (the same Bad request error showed up a couple of weeks back) - maybe Joachim and a couple of WP users? ϒpsilon (talk) 15:31, 17 February 2014 (UTC)
Sigh, what a bummer thread to remake my debut after some lovely travels away from constant support requests (I don't know how Joachim deals with it :) and general site squabbles. For what it's worth, I left instructions on how to become an additional maintainer at #Secure_site_at_tools.wmflabs.org and as soon as someone has a Wikitech account they can get control. Imagine my dismay when I left my talk page message after realising the Tools Labs account was a weak link. I think I could add User:Zhuyifei1999 who has a current account there if they want.
However, the Tools Labs have definitely not lived up to expectations, and it really is more of a development and not production server. They have constantly suffered from XFS issues on their distributed network and it's only something the actual sysadmin (and not a common maintainer or account holder) can fix. One possible solution is to try and set up a proxy server like User:Nicolas1981 tried to do before the current situation, since they may have fixed the security issues by now. Or if someone helps the maps.wikivoyage-ev.org server get a security certificate. By the way, not that it matters and any incompetence is solely my own, but *cough* I'm a she. -- torty3 (talk) 16:08, 17 February 2014 (UTC)
Hi torty3! Great to see you back! What should one do to get the security certificate? --Alexander (talk) 17:04, 17 February 2014 (UTC)
Do you mean hosting on Wikimedia Labs instead of Tools Labs? In any case my Wikitech account is https://wikitech.wikimedia.org/wiki/User:Nicolas_Raoul and the instance I did my tests on is https://wikitech.wikimedia.org/wiki/Nova_Resource:I-000005b0.pmtpa.wmflabs . Of course I can invite you to my small project if you want to modify the instance or create new instances. Nicolas1981 (talk) 10:58, 18 February 2014 (UTC)
Yep I mean the separate instance, which should be hosted on separate network clusters from Tools Labs, though their security certs may still not be functional. A WMF engineer did say they would assist in getting a security certificate, but I'm unsure as to the setup on the maps.wikivoyage-ev.org and there are quite a few online guides to help out. I agree with the Germans that it's a lot of hassle to set it up just because the entire WMF decided to move towards HTTPS, but what can you do. -- torty3 (talk) 06:25, 20 February 2014 (UTC)

"Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, mpelletier@wikimedia.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.2.22 Server at tools.wmflabs.org Port 80" :P ϒpsilon (talk) 21:16, 22 February 2014 (UTC)

The service seems OK to me right now.
I do have some questions on the longer term support issues (and I'm actually willing to raise my hand to contribute to helping this problem) and I'll write more as soon as I get time. Andrewssi2 (talk) 13:07, 23 February 2014 (UTC)

@torty3: Would you mind using lighthttpd (on tools-webgrid-1) instead of apache (on tools-webserver-01, which have much more load)? ---Zhuyifei1999 (talk) 16:40, 24 February 2014 (UTC)

Done, we'll see whether there's any difference. For reference, I've made Zhuyifei, a zh.voy admin, a maintainer for the Wikivoyage Tools Labs. -- torty3 (talk) 13:34, 25 February 2014 (UTC)
Thanks for that ;) Difference: avoids ddos attacks --Zhuyifei1999 (talk) 15:31, 25 February 2014 (UTC)

Map marker images linking to mobile site[edit]

As of right now, whenever I click a map marker where the image parameter is in use, I get a little thumbnail that links to the full size version of the photo on the mobile site instead of the regular site. Does anyone know why this is happening? I'm guessing it wasn't intentional.
Thatotherpersontalkcontribs 11:45, 25 February 2014 (UTC)

It was my laziness. - This works in both mobile and desktop version, but only in full screen mode. An adjustment is on my long to-do list. -- Joachim Mey2008 (talk) 13:18, 25 February 2014 (UTC)
Alright. As long as it's a known issue. –Thatotherpersontalkcontribs 07:53, 26 February 2014 (UTC)

Default map layer[edit]

Would anyone mind if I changed the default layer to Mapnik (OSM)? It looks smoother and more refined than the Mapquest Open layer, which always seems blurry in the text areas.
Thatotherpersontalkcontribs 06:21, 17 March 2014 (UTC)

I'm fine with that, but seeing as it affects a lot of articles you might want to add a note to the Pub that points people to this discussion. -- Ryan • (talk) • 06:34, 17 March 2014 (UTC)
For each page view the dynamic map is automatically loaded in the frame. In each case, some map tiles are loaded. Only MapquestOpen allowed unlimited access to the tiles. Therefore, the Layer "O" must be the default. -- Joachim Mey2008 (talk) 06:49, 17 March 2014 (UTC)
I wasn't aware of any limits to the number of tiles you could load. What happens if you change the layer? I've already done so manually on a handful of articles and the only missing tiles I've noticed were in the aerial footage.
Thatotherpersontalkcontribs 07:00, 17 March 2014 (UTC)
Other providers limited the number of requested tiles per day and then block access. So my concern, but only if we use an other layer (eg Mapnik) for all the articles. -- Joachim Mey2008 (talk) 07:10, 17 March 2014 (UTC)
Actually, if we were to change the default layer I'd suggest Wikivoyage. It has some flaws, but it harmonizes best with our existing maps. Powers (talk) 18:05, 17 March 2014 (UTC)
I also prefer the look and feel and detail of Mapnik (OSM); however, it has a major drawback in that for many countries that do not use a Roman alphabet, many of the labels are problematic. Joachim's answer is the clincher against changing the default, though... --118.93nzp (talk) 09:19, 18 March 2014 (UTC)
Hi Joachim, I've been using Mapnik pretty much exclusively. Would you advise against doing this? Andrewssi2 (talk) 11:27, 18 March 2014 (UTC)
For city articles only the default layer ("O" = MapquestOpen) should be used. This layer has specially few signatures, then the markers are better visible. If a visitor wants more information, he/she may select a different layer. The quantity limitation of different tiles providers (except MapquestOpen) should also be considered. -- Joachim Mey2008 (talk) 12:22, 18 March 2014 (UTC)
Each map type has its advantages; Mapnik is good for finding POIs we haven't listed yet, the relief map is probably the best one for mountainous areas and national parks in general and the default maps is the best looking (IMO). Maps that can be loaded a only limited number of times are obviously not a good idea to have as default, unless that limit is high enough. Let's stick with the default map. ϒpsilon (talk) 12:46, 18 March 2014 (UTC)

Scripts update[edit]

@torty3, Zhuyifei1999: There are new script versions on maps.wikivoyage-ev.org. An update on tools.wmflabs.org is not done for some time. Please keep in mind that the WV-ev-server is only http. -- Joachim Mey2008 (talk) 08:58, 23 March 2014 (UTC)

Current settings is to update on 11:20 (UTC) every Monday and Thursday. Just wait another 24 minutes ;) --Zhuyifei1999 (talk) 10:56, 24 March 2014 (UTC)
We're not talking about minutes. A new version is available for three weeks now on maps.wikivoyage-ev.org/archive/. -- Joachim Mey2008 (talk) 13:17, 24 March 2014 (UTC)
@Mey2008: I have no idea of what is wrong with that auto-update script, but anyway I have manually updated it. Please check if it is up to date as I don't know what the change is. --Zhuyifei1999 (talk) 13:24, 25 March 2014 (UTC)
Thank you, everything's okay now. - The scripts are constantly being revised, some bug fixes and enhancements are relevant only in other language versions​​. -- Joachim Mey2008 (talk) 14:06, 25 March 2014 (UTC)

Proposal to separate map design from coordinate specification[edit]

I propose that we modify Template:Listing to include two new parameters. We could call them "lat_map" and "long_map". Their values would default to the existing "lat" and "long" parameters respectively, but could be specified if different values are needed. We would then modify the dynamic map code to use "lat_map" and "long_map" instead of "lat" and "long" for the display of icons on the maps.

This proposal has the following advantages:

  1. It resolves the tension between wanting to provide accurate coordinates for a listing using an appropriate level of precision, and wanting to precisely place icons on a map.
  2. It is fully backward compatible; no existing uses of the template (or of See, Do, Eat, Drink, and Buy) would need to be replaced immediately.

Thoughts?

-- Powers (talk) 17:08, 26 March 2014 (UTC)

There is significant background at Wikivoyage talk:Listings#Overprecise geotagging that is useful for anyone joining this discussion.
I'm still unclear as to why overprecision in listings is a problem. I understand why saying "Los Angeles is 381.114535 miles from San Francisco" is absurd in text, but if that same information was purely metadata used internally by tools on our site I don't see how it would cause any harm, and that's the only way we're using lat/long coordinates at the present time. I'm happy to support this proposal if there is a demonstrated need for it, but at the current time it seems like it could create a lot of clutter in listings without any obvious benefit. -- Ryan • (talk) • 17:54, 26 March 2014 (UTC)
One of our explicit goals involves our data being used in external applications, such as other travel guides. As such, it is contrary to our goals to consider only what benefits Wikivoyage, and to only consider Wikivoyage's needs, when designing our features. The fact that, at the moment, the only one of our our features that uses the geo-coordinate data is our dynamic map feature means neither that a) we will never have a feature in the future that needs accurate coordinates (e.g., an expansion of the "Near this page" feature that is currently in beta, or an extension of Special:Nearby to work with listings rather than articles), nor that b) noone else out there in Internet land is making nor will make use of our data with or without our knowledge. Even if there isn't anyone looking at our listing coordinates currently, consider this a bit of future-proofing. Consider, in fact, that at one point we even did display these coordinates to readers (on hover over an icon), so this is not some far-fetched, pie-in-the-sky possibility; it's reality. Powers (talk) 23:37, 26 March 2014 (UTC)
I disagree that overprecise coordinates is a problem for re-users - it is up to individual re-users to decide how much precision is needed for their particular use, just as we trim or expand coordinates for our use here. It seems like this proposal is an effort to solve a problem that doesn't currently exist ("consider this a bit of future-proofing") and thus offers little or no current benefit while forcing us to maintain duplicate sets of coordinates for a large number of our listings. Others may feel differently, but I don't think it's something to pursue until there is a demonstrated need for it. -- Ryan • (talk) • 23:50, 26 March 2014 (UTC)
On a related note, perhaps adding something to Wikivoyage:Listings (or another relevant page) that suggests how much precision to use would be useful - along the lines of w:Wikipedia:WikiProject Geographical coordinates#Precision. That way we could make it clear that anything more than 5-6 digits is pointless, and provide guidance on when (and why) less precision might be prudent. Providing such guidance might allow us to standardize to some extent, which would address your concern in many cases while still allow map makers the needed flexibility. -- Ryan • (talk) • 00:35, 27 March 2014 (UTC)
First of all, precision is part of the data we are putting out there. Re-users may not know how precise the coordinates are if we don't provide the proper number of decimal places to start with. But aside from that, this isn't just about overprecision; as I understand it, some editors have taken to slightly mis-placing coordinates to avoid collisions on the map (either with other icons or with elements in the underlying tiles).
But beyond all that, I'm very disappointed to see you dismissing this good faith effort to find common ground on an issue that has caused tension. You have said several times over the last year or so that it is important for editors who oppose a new proposal to acknowledge the concerns of those who find a deficiency in current practice and find a way to meet them halfway, rather than just saying "no". Not only am I trying to do that here, but you are reacting to my proposal by essentially just saying "no". Just because you don't see the need doesn't mean that other editors don't, and it would help this discussion greatly if you could at least acknowledge the validity of that viewpoint, even if you disagree with it.
-- Powers (talk) 02:18, 27 March 2014 (UTC)
Geomap [63] shows decimal places according to the object size. Examples: United States [64], a building [65]. Please click on the map. Decimal digits vary from 0 to 5. Over-precision is avoided in this way, further arguments are not very important, in my opinion. -- Joachim Mey2008 (talk) 07:41, 27 March 2014 (UTC)
First of all, that's not true; it shows decimal places according to the map's zoom level. The interface doesn't appear to take the size of the object into account at all. Secondly, I'm afraid I don't understand what Geomap's functionality has to do with this proposal. Powers (talk) 14:11, 27 March 2014 (UTC)
Well, back to the topic (separate map coordinates). I oppose the proposal. The effort is much higher than the benefits. -- Joachim Mey2008 (talk) 15:40, 27 March 2014 (UTC)
LtPowers, first, I apologize for not being more constructive in my initial response, but I believe that my proposal timestamped 00:35, 27 March 2014 is an attempt to address your concerns without requiring us to maintain duplicate coordinates. -- Ryan • (talk) • 16:06, 27 March 2014 (UTC)
Apologies, I did gloss over that post a bit; it seemed more like an additional suggestion than a replacement suggestion. However, "duplicate coordinates" is a bit of a red herring; the only case in which we'd have to maintain duplicate coordinates is when someone decides that the position of the map icon for a particular listing needs to be tweaked slightly. In all other cases (likely 99.9%), the map will default to using the lat and long values, as it does now. This adds very little additional maintenance, by design. If I'm reading your suggestion right, the idea is to reduce overprecision in cases where it's done out of carelessness, but to allow it in those 0.1% of cases where someone wants to move the map icon; is this right? Powers (talk) 23:11, 27 March 2014 (UTC)
I think if we can provide some guidance on how much precision to use then it would educate editors and allow them to choose levels of precision that would address your concerns. Further, if I understand correctly, five decimals is accurate to within a meter, so we can probably come to an agreement that anything more precise can be trimmed (it would be easy to add such a rule to WV:AWB). Would that at least start to address your concerns? -- Ryan • (talk) • 05:28, 28 March 2014 (UTC)
These two markers [66] were 6 m shifted each so that they do not overlap. Do we really need more precise coordinates? - Joachim Mey2008 (talk) 06:29, 28 March 2014 (UTC)
Certainly not; I'm in complete agreement that six decimal places is far too many for any reasonable application. Five is, in my opinion, useful only for map positioning tweaks, except perhaps for small statues. Three is sufficient for most listings, two for small cities, and one for large cities. If it is felt that such guidance is useful, then by all means it should be added. But it doesn't address the basic disparity between using the coordinates for maps and providing them as information. If the maps are going to shift listing coordinates in order to achieve more aesthetic results, then the precision guidelines you're proposing don't apply anyway. Powers (talk) 17:42, 28 March 2014 (UTC)

I would also oppose any addition of such parameters to the listing templates, as it makes them more complex for relatively little benefit and also increases duplication. Bear in mind that the maps application as well as the listing editor will need to be changed. As far as I understand, most geocoding databases and applications do not bother to control the number of decimal places, and doing so in such a manner would be a very futile and stupid effort. Instead, they use a separate parameter called dimension which would denote the size of the object being geocoded. Note that I'm not exactly proposing that Wikivoyage does the same, as travellers don't really focus on precision, and I have read too many travel blogs using/publishing six or more decimal places to pin PoIs that would probably drive LtPowers mad. People still copy down whatever is given and then use their GPS devices or smartphones to find them. -- torty3 (talk) 04:47, 30 March 2014 (UTC)

All the more reason for our data to be correct, isn't it? I don't buy the complexity complaint; this complexity is only there in those cases where it's needed. Powers (talk) 01:17, 31 March 2014 (UTC)

Okay, so if my proposal is unacceptable, what alternative do you all propose for resolving the conflict I identified? If someone comes in and wants to specify ridiculously overprecise coordinates (or even wrong coordinates) for the sake of map appearances, how do we resolve that? Powers (talk) 18:18, 4 April 2014 (UTC)

Spiderfy[edit]

As a slight spinoff on the display issues, I know Joachim has already done some work on clustering and spiderfying. I think clustering was found to condense too much information, but I don't think Spiderfy got a proper evaluation. If Joachim could set up an example of how it would look like, especially on maps with a lot of geocoded information, we could get a better idea of how to move forward. -- torty3 (talk) 04:47, 30 March 2014 (UTC)

Spiderfy is a proven technology [67]. But it does not perfectly solve the problem. Hidden markers are visible only after a click.
My suggestion: selecting a high zoom level (eg, 16 in cities). Centering on an interesting part of the city in the map frame [68].
Scrolling is quite normal in the text area of each article. No one demands that the whole text is scale down to a screen size. The text part is dynamic. Why is not normal even pan and zoom in a dynamic map? There are two aids. The light blue edges markers indicate where additional markers are present and a quick overview with the button "Show me all the markers."
Perhaps such a solution is acceptable? - Joachim -- Mey2008 (talk) 06:43, 30 March 2014 (UTC)
I don't like the idea of zooming in on one specific part of a destination for the initial map load. Scrolling through the text portion of the page is easy and intuitive because down is always the correct direction to keep reading, whereas a pre-zoomed map doesn't present an obvious order to explore the destination in (other than zooming back out to get your bearings, a step that can be skipped if we just keep using the current zoomed-out maps). The "show me all markers" button is helpful, but not very intuitive—I didn't even know it existed until just now.
Thatotherpersontalkcontribs 01:14, 31 March 2014 (UTC)
Is that better [69]? I think not. A city map with 100 markers in a frame of 10 x 10 cm is confusing. - Are there better examples on the WWW? I have found no solution (except clustering). - Joachim Mey2008 (talk) 06:29, 31 March 2014 (UTC)
That was definitely an excessive amount of POI overlap, but the problem on that page went deeper than the zoom level. First of all, I have to wonder why a city of 2 million people would be districtified in such a way that five out of six districts represent a third of the city, while the other two thirds of the city share one article and one map. There was never going to be a good way to display that district in a single map. The problem was then made worse by using absolutely tiny dimensions for the map frame, which I have now fixed. The map still has both overlapping POIs and out-of-frame POIs, but the only way to truly fix it would be to redo the districts of Budapest. Short of that, I think a larger map with a medium zoom level is a better solution than zooming in on a specific neighborhood when the map is supposed to represent two thirds of a major city.
Thatotherpersontalkcontribs 22:59, 31 March 2014 (UTC)
Budapest Districts are currently under discussion, following a lot of content having been added in the last three months. Currently there are 3 districts, with 6 proposed. I think that the article was about a third of the present size when the map was added, so Pest is probably not a good example. AlasdairW (talk) 22:39, 1 April 2014 (UTC)

Layers[edit]

The layer "Wikivoyage" is no longer available. Provider CloudMade has stopped its free services. I have replaced with "Mapnik b​​&w"[70]. In addition, there is now the layer "Boundaries". Maybe useful for regional maps of the lowest levels [71].

When choosing the layers I have always been careful to select reputable providers. But changes not excluded in the future. -- Joachim Mey2008 (talk) 05:32, 2 April 2014 (UTC)

Awesome. I love the new Boundaries layer. It does bring up an issue though: the current guidelines for adding a dynamic map say to "only add dynamic maps to articles at the lowest level of the article hierarchy (city or district)". The origin of that rule seems to be Texugo's comment above: "the function of maps in metropolis, region, and country articles is to show how we have broken down the coverage. The dynamic maps do not serve that function at this time." Obviously we still can't draw custom borders on a dynamic map, but I believe a low-level region article with a dynamic map can be significantly better than one with no map, especially in light of the Boundaries and Destinations layers now existing. (On a related note, is there any way to remove the blue circles from the Destinations layer? I find them more distracting than helpful.) Is it time to do away with guideline #1? I also dislike rule #4 about needing a specific reason to customize the height and width, if anyone would like to comment on that while we're at it.
Thatotherpersontalkcontribs 23:57, 2 April 2014 (UTC)
We split large provinces & states into many colour-coded regions
Cities/towns and districts have individual {{listing}}s; 'container' articles such as regions should not. A region needs the custom borders, but at the same time likely does not need the city-style POI's. K7L (talk) 01:19, 3 April 2014 (UTC)
Custom borders of a region can be represented by {{mapmask}} (example). Your reference to POI I do not understand. In the dynamic region maps no POI's are shown (example). -- Joachim Mey2008 (talk) 04:32, 3 April 2014 (UTC)
Is there any way to colour-code and label these regions, or their neighbours, on the map? K7L (talk) 14:31, 3 April 2014 (UTC)
A lowest-level region article does not need custom borders, though, since it isn't split into further regions. A dynamic map with the Destinations layer activated could improve quite a few of these articles. As for POIs, I understand not wanting to put business listings in region articles, but that doesn't mean there will never be a good reason to use a map marker on a region article. For example, the bulk of the content at Western Utah is about art installations in the middle of the desert; none of them is anywhere near a city they could be listed with, but why not still show people where they are on a map? If someone added a dynamic map that really wasn't an improvement to the article, we could fix that without needing a broad guideline against adding dynamic maps to region articles.
Thatotherpersontalkcontribs 08:12, 5 April 2014 (UTC)

The boundaries layer looks good until you look closely. The labels are fixed to the center of the regions being labeled and often cover up essential items like cities. (See Eastern Finger Lakes and try to find Ithaca.) Powers (talk) 14:44, 3 April 2014 (UTC)

The boundaries of the counties in the examples are not boundaries of regions! The Eastern Finger Lakes region is bounded by the gray mask (see example). The political borders can be hidden if required (layers button in the upper right). Useful is also the layer "Destinations". There all existing articles are displayed. With [shift-click] you can directly open the desired travel destination article. - My suggestion should apply only to the lowest level of a region that has no further subdivisions. -- Joachim Mey2008 (talk) 16:00, 3 April 2014 (UTC)
Yes, I was using the word "regions" generically, not in the Wikivoyage sense (which I usually try to capitalize, as "Regions"). Regardless, though, I think "Yes, but if the reader clicks the right button the problem disappears" is getting kind of tiresome as a response when problems with the dynamic maps are pointed out. Powers (talk) 23:37, 3 April 2014 (UTC)
You can of course preselect the desired layers. {{mapframe|...|...|...|layer=O}} [72] or {{mapframe|...|...|...|layer=OD}} [73] or {{mapframe|...|...|...|layer=WBS}} [74]. Many other combinations are possible. -- Joachim Mey2008 (talk) 04:44, 4 April 2014 (UTC)
Anything on removing the blue circles from the Destinations layer? People aren't going to understand what the circles mean if the layer is preselected.
Thatotherpersontalkcontribs 08:12, 5 April 2014 (UTC)
If no other opinions, I will remove the blue circles in the next version. - Joachim Mey2008 (talk) 11:39, 5 April 2014 (UTC)

Dynamic region maps[edit]

I like the existing static region maps pretty well. Here is an example of a dynamic region map [75]. Colors, labels, legends are variable and could be easily adapted to the above example. - But the effort for the coordinate determination for the borders of regions is considerable. I mean in this case static maps should be maintained. - Joachim Mey2008 (talk) 16:22, 3 April 2014 (UTC)

New marker clustering[edit]

There are now more than 800 embedded dynamic maps in the English Wikivoyage. Many have dozens of markers. Not infrequently, this markers overlap. A proven technique is to combine markers in clusters. I tried to optimize this technique for Wikivoyage.

  • Only markers that overlap more than half, are combined (cluster radius: 13 pixels).
  • Clicking on a cluster-icon triggers a zoom so that the individual markers are visible.
  • You can also turn the mouse wheel to watch the clustering.
  • Here are some examples for testing: [76], [77] and [78].

I ask for suggestions: for example, better cluster icon or other cluster radius. -- Joachim Mey2008 (talk) 06:27, 24 April 2014 (UTC)

That's very cool! The only downside is that you can't link the numbers in the article to the map without clicking - would there be any possibility of showing the numbers when hovering over the zoom icon, or in some other way showing what listing is being represented? Even without that functionality, this appears to be a nice usability improvement. -- Ryan • (talk) • 07:05, 24 April 2014 (UTC)
I still can't get a server response from any wikivoyage-ev links. I tried four browsers. –Thatotherpersontalkcontribs 01:48, 25 April 2014 (UTC)
Please note that the WV-ev server provides only http. -- Joachim Mey2008 (talk) 04:46, 25 April 2014 (UTC)
Ryan's idea is good, but too complicated for my programming skills. - Do other users have also problems with the server access? - If no other opinion, I will activate the clustering in the next version. -- Joachim Mey2008 (talk) 05:30, 1 May 2014 (UTC)

Destinations layer glitch[edit]

I see the blue circles have been removed from the Destinations layer (thanks Joachim) but when I tried to activate it on Western Utah, I got a glitch in the preview screen where the Points of interest layer was deactivated by default as soon as the Destinations layer was added. Trying to manually activate the P layer in the mapframe template didn't help, although it is possible to see both the Points of interest and Destinations layers at the same time if you select them from the drop down menu. Any idea what's causing this?
Thatotherpersontalkcontribs 01:48, 25 April 2014 (UTC)

An old error. Was quite forgotten. Is now on my todo list. - Thanks for the note, Joachim Mey2008 (talk) 05:06, 25 April 2014 (UTC)
Update is done. Please reload the page twice if necessary. -- Joachim Mey2008 (talk) 11:56, 1 May 2014 (UTC)

Dynamic -v- static maps[edit]

Swept in from the pub

I am disgusted by the drive to remove less-than-perfect but well-constructed and painstakingly handcrafted maps in favor of dynamic maps, which are technically impressive but not as flexible or as usable as a good handcrafted map. It's one thing to allow them to co-exist on the same article, but we have now stepped off the precipice and removed a map because the dynamic map is "better". This I cannot stand for. These dynamic maps are not objectively better even than an imperfect static map. Icons overlap. Orientation is fixed to north-only. Important labels are omitted at various zoom levels in favor of less-important ones (since the algorithm can't tell the difference). We have no control over what streets and buildings and bodies of water and transit points are shown; that's all handled by the algorithm. But for some reason, which no one has explained, these drawbacks don't matter.

But when it comes to a handcrafted map, every little drawback matters. The letters are too small? Delete it! One icon is out of date? Delete it!

The most fundamental precept of the wiki ethos is that if something is imperfect, you fix it. Our maps are designed to allow that to the extent possible. If you can learn wiki syntax, you can learn how to modify an existing SVG map in Inkscape. But it seems there are too many people here who are content to toss a slap-dash auto-generated map onto an article rather than simply fix the problems they find with a handcrafted map.

This is not the wiki way.

-- Powers (talk) 18:24, 12 March 2014 (UTC)

Do you know how to edit maps? If you do, then recommending that others who lack the time or/and inclination learn how to edit maps instead of editing them yourself is also not the "wiki way." The wiki way is to plunge forward, not to complain that others are not doing so when you can. Ikan Kekek (talk) 18:48, 12 March 2014 (UTC)
(edit conflict) Many of us are of the opinion that the "fix" to the drawbacks of static maps was to implement dynamic maps. We have had hundreds of maps added to articles in the past few months, as opposed to the much smaller trickle that was added when static maps were the only option, and every editor can now edit those maps when they edit an article. Clearly your opinion is different, but saying that implementation of dynamic maps, as opposed to maintenance of existing static maps, is not the "wiki way" is an argument that is definitely in dispute. To look for a constructive path forward, let's figure out how, when and if the two should co-exist, ideally acknowledging that both can have a place on this site and that supporters of each have valid arguments. Example: Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site? -- Ryan • (talk) • 18:55, 12 March 2014 (UTC)
Lt, I think you and I are part of a dying breed. ;) I'm not overly fond of the quality of the dynamic maps myself, although I don't find them to be so offensive as to be utterly inferior. And they are pretty dang functional, I gotta give them that.
More than that though, I've just lost any kind of enthusiasm in working with the static maps because I feel like the Wikivoyage community, for the most part, has no interest in caring for them. I made a lot of static maps, and I made them in the belief that after I uploaded them here, the community would take ownership of them and keep them up-to-date, even improve them if need be. That rarely happened. Usually, the map would just sit there collecting dust (by which I mean slowly go out-of-date) and eventually I would have to come back and update it myself. And proud as I am of the work I've put into this community, I have a busy life outside of this website; I don't want people relying on me to keep this stuff in order. And I get it; Inkscape looks like a really scary complicated program and there's a reluctance among users to touch the static maps. Fine, I accept that.
In the end, if the choice is between a well-made static map that no one is going to care for, and a sloppy dynamic map that people will at least bother to update, then I'd choose the dynamic map. I don't want to see a bunch of relics on Wikivoyage, even if I'm the guy who built them. PerryPlanet (talk) 19:31, 12 March 2014 (UTC)
I do think static maps are the only way to go in region/state/country/continental section/continent articles, since they are the only way we can have maps that are color coded, labeled with our own peculiar region names, etc,. and I don't see that changing anytime soon. For cities though, I tend to agree with Ryan. Your critique about overlapping icons/names fails to take into account the ease with which the map can be manipulated around most of those problems. If they were algorithmically-created static maps, your point would be 100% valid, but they are dynamic, so the user can circumvent most of those problems, when they pop up, with a tiny movement of the mouse scroll. Texugo (talk) 19:41, 12 March 2014 (UTC)
I am with Texugo on that. I would love to see the day when dynamic maps would sort the overlapping icons issues themselves, and we could even highlight objects on the map itself that should not be obscured by the icons, but I believe dynamic maps is the way to go for city/district-level articles. This is a wiki, which anybody should be able to edit with the result being a better article, not an outdated map. PrinceGloria (talk) 20:07, 12 March 2014 (UTC)
Sometime back, when I was not a fan of dynamic maps and I really disliked them, so I created a city level map for Karachi but the map was lacking only FEW point of interests which are located in suburbs of the city so I realised a dynamic map is actually appropriate to use in such a large city POI are scattered far and wide and where new businesses such as restaurants, accommodations etceteras pop up frequently and the dynamic map can be modified easily simply by anyone accordingly. There were only minor issues with that static map I created but due to non-availbity of time, I decided to replace that static map with a dynamic map. I think I very much agree with comments of those who says a dynamic map is very useful for cities and district level articles but when it comes to a region article, a dynamic map can't beat even a incomplete and poor crafted static map. --Saqib (talk) 20:58, 12 March 2014 (UTC)
My major issue with dynamic maps is that the server is balky. If dynamic maps become unusable, we will regret that we don't have static maps for every article. Ikan Kekek (talk) 22:30, 12 March 2014 (UTC)
I actually share much of PerryPlanet's opinion, and no shared updates to static maps is what I mean by not enough critical mass. If say there were many people actively editing an article, I wouldn't mind perhaps chipping in my bit and making a static map. But I do not want to be the only one in charge of the map graphic. It's symptomatic of the problems of static maps in the past ten years. When I mean outdated, I mean five years outdated and it's not just one outdated listing, but tens. I'll even point out that one needs Maperitive and Inkscape, two different programs, to create static maps unless you painstakingly trace each and every road, since OSM no longer natively supports SVG export.
In fact I'm going to go further and say that there is a severe lack of collaboration around the entire site in the first place, where we are lucky enough to have one contributor for a city, let alone two or more to bounce ideas and keep up maintenance of maps or otherwise. I'm more interested in solutions for that, because I think it is the root problem, rather than retreading old arguments or nitpicking formatting. -- torty3 (talk) 00:01, 13 March 2014 (UTC)
The static maps have one trump card which is that they are always available. The Infrastructure behind dynamic maps is running on is not reliable and support is basically 'best efforts'. (And those efforts are very much appreciated, but we need to be honest about this functionality in order to improve it)
For that reason I would support Powers in not moving away wholesale from static maps today.
For the record, I did myself get started in creating some static maps however the effort involved meant that I simply can't justify spending the time to create or even update existing maps. Laziness? Yes, probably, but in all honesty the Dynamic Maps have a low bar for all people to get involved (a good thing) and the static maps have a rather high bar. Andrewssi2 (talk) 00:52, 13 March 2014 (UTC)
All of the objections raised are addressable with a little bit of effort. And isn't it better to take that effort on ourselves rather than ask the reader to scroll and zoom a map until everything is visible? When did we become a community that valued ease of construction over value to the traveler? Powers (talk) 16:13, 13 March 2014 (UTC)
"When did we become a community that valued ease of construction over value to the traveler?". Please re-read what you've just written. Nearly everyone who has argued in support of dynamic maps has stated that they provide added "value to the traveler". Everyone recognizes that there are pros and cons of each approach, but continually describing dynamic maps as if it is a fact that they are an inferior tool is not helpful; that is your opinion, and it is an opinion that is not universally shared. We need to come to an agreement on how to move forward, and while it would be great to find a compromise solution, if the choice is repeatedly painted as being between the "good" solution and the "bad" solution then I vote for dynamic maps as being far superior to static maps for everything below the region level. I hope it doesn't come to that - let's stop focusing on one instead of the other and find some middle ground that makes both sides happy. -- Ryan • (talk) • 16:42, 13 March 2014 (UTC)
I just noticed a case in point. Hong Kong Central has some lovingly hand crafted static maps. I would like to update the article listings, but I'm not willing to spend the considerable time to edit the static maps. Effectively an impasse.
As pointed out before we really need more contributors. Being a master cartographer should not be a requirement to get involved and creating awesome articles.
Perhaps the Hong Kong central article can provide a good starting point for discussing the compromise? Andrewssi2 (talk) 00:47, 14 March 2014 (UTC)
"I vote for dynamic maps as being far superior to static maps for everything below the region level"
Not to nitpick, but I'd say static maps are also the superior option for parent articles of districtified Huge Cities (q.v. Buffalo#Regions).
-- AndreCarrotflower (talk) 00:56, 14 March 2014 (UTC)
Another case in point: Do you think a dynamic map is likely to be better than the static map in the San Francisco/Mission article? There are cases to leave well enough alone. Ikan Kekek (talk) 01:16, 14 March 2014 (UTC)
No, I think the San Francisco/Mission static map is better than what can be achieved with a dynamic map. (i.e. if I want to print the map and walk around the district the static map would make it much easier)
The question is WHO is going to add new listing to this static map? If no one, then is it acceptable that the article becomes more out of synch over time? At what point does remedial action need to be taken?
And no, I have no answers to the above :) Andrewssi2 (talk) 01:41, 14 March 2014 (UTC)

Finally an HTTPS server for dynamic maps[edit]

Swept in from the pub

Dear travellers,

I got us an HTTPS LAMP server that looks more stable than the last one:

I hope that will solve the mixed-content problems that plagued dynamic maps until now :-)

I guess my PoiMap2 Github repo at https://github.com/nicolas-raoul/PoiMap2 is not up-to-date anymore. Could you please fork and send me a pull request? Or point me to a more up-to-date Git repo? Thanks!

Nicolas1981 (talk) 15:49, 25 March 2014 (UTC)

I'm seeing an error with the generic Listing icon. See here on the old server there's three green hexaflowers on the west side of town, then switch to the new server and the icons no longer load.
Thatotherpersontalkcontribs 01:34, 26 March 2014 (UTC)
Yes, the PHP source code is not up-to-date.
So, if I understand correctly, the last thing to do to get rid of the mixed-content problem is to install an OSM tiles server on voyage.wmflabs.org? Am I right? Does anyone have experience with this? Nicolas1981 (talk) 03:06, 26 March 2014 (UTC)
An own tile server for OSM Mapnik tiles is not a solution. We need tiles for all 10+ different layers. But not all providers offer data dumps as OSM (Planet.osm). Mixed content is inevitable. -- Joachim Mey2008 (talk) 06:11, 26 March 2014 (UTC)
I don't think we absolutely need to serve ALL layers as HTTPS, but at least the default layer, so that external visitors can enjoy the map instead of staring at a white rectangle. Nicolas1981 (talk) 04:55, 27 March 2014 (UTC)
I tested extensively on real hardware and could find no errors. Example: Debian 6.0/FF 28/https/not logged in [79]. Sometimes the cause is also due to specific settings (browser, proxy, virus scanners). Do other users have similar problems? Nevertheless, I will revise the scripts in terms of map tiles under https. -- Joachim Mey2008 (talk) 09:12, 27 March 2014 (UTC)
It should also be checked, whether in the personal common.js is still a trial version of mapframe.js. This needs to be deleted because it is no longer compatible. The old version caused a white map window. -- Joachim Mey2008 (talk) 13:43, 27 March 2014 (UTC)
As you pointed out, it was a problem with my common.js indeed! So an HTTPS tiles server is not absolutely needed right now :-) Thanks a lot! Nicolas1981 (talk) 15:38, 28 March 2014 (UTC)
All Mapquest and Mapnik layers now use tiles that are offered under https. -- Joachim Mey2008 (talk) 16:21, 24 April 2014 (UTC)

Destinations layer again[edit]

There are a couple more improvements I would like to see in the Destinations layer.

1. Can we add target="_blank" or target="_main" to the links generated by the Destinations layer? Currently, clicking one of these links opens the article inside the mapframe.

2. We need a way to take more control over which markers show up when the Destinations layer is activated. The simple radius system is causing all sorts of problems. For example, the dynamic map at Northern Nevada doesn't show destination markers for Wells, Jackpot, or Wendover thanks to the region being 300 miles wide, and I had to use a non-ideal center for the map at Western Utah to make Brigham City fall within the Destinations radius. The Western Utah map also shows another problem: the map is visually overpowered by a large cluster of cities that fall outside the region's borders, but can't be excluded from the map. Ideally, I would like to see some sort of whitelist/blacklist system to determine which articles get Destination markers on any given page's map. If that isn't possible, could we have the Destinations appear based on whether or not they fall within the mapmask boundaries instead of a simple radius from the map's center? Also, I would like to see the marker for the article you're already reading be suppressed (i.e. the map at Northern Nevada wouldn't show a marker for Northern Nevada).
Thatotherpersontalkcontribs 01:21, 9 June 2014 (UTC)

Good ideas!

  1. target="_blank" - I have coded it now. Update next Thursday.
  2. article markers control - This takes a little longer. My solution: markers of all the articles (worldwide) are displayed. Markers outside the map mask will darken gray. The article marker of the current article, I can not hide. But maybe display in a different color.
  3. hide POI markers - You may already hide the POI layer. Example: layer=OD-P. - Joachim Mey2008 (talk) 19:22, 9 June 2014 (UTC)
I'm attempting to write an itinerary; is there any way to display destination markers for just the villages which have [[wiki]]links in my article? Radiator Springs#Prepare, if the 'D' layer is enabled (it currently is not), shows a large cluster of destination markers west of OKC based solely on radius from map centre. These appear without regard to whether any of them are listed in the article, or are on Route 66 at all. Effectively, a typical Route 66 itinerary should include tiny Adrian TX (pop 140) but ignore larger centres like Denver which are on some other route.
I suppose the same is true for standard regions, eastern Ontario includes Ottawa but not Gatineau, but those usually use static maps in order to show the region boundaries as colour.
Distance from a GPX trace might work, or show 'D' markers for just the destinations linked from the article? K7L (talk) 18:09, 10 June 2014 (UTC)
A specific limitation of the "D" layer is not possible. Other languages ​​versions used the type "vicinity" for nearby destinations (Example). Destinations can be selected individually on this way. -- Joachim Mey2008 (talk) 05:00, 17 June 2014 (UTC)
That's pretty cool. I've implemented the city and vicinity markers as a replacement for the Destinations layer at Central Nevada and I like the results. The only drawback is that there isn't an article link on the map itself this way, but I guess that's only a problem in fullscreen mode since an embedded map would be right next to a list of city links.
Thatotherpersontalkcontribs 00:35, 18 June 2014 (UTC)
Will it ever be possible to generate these dynamically?
These look interesting, although it's unfortunate the markers appear as POIs instead of destinations. On articles which list cities/villages but not individual POIs (such as Rideau Canal or Trans-Canada Highway) it might be usable - on something like Route 66 which has both a list of towns and a list of attractions I'm not sure how to avoid having POI markers for the venues overlap the marker for the town everywhere. Will this just become a sea of yellow '+' signs? K7L (talk) 14:05, 18 June 2014 (UTC)
The article "Route 66" is no problem at all. A static overview map is already available. For individual sections may be links (not mapframes) set to detailed maps. See the example Rheinburgenweg. So there are no clusters of markers. To clarify: There are only shown the markers of the current article (eg Route 66), not even the markers of neighboring articles. - Joachim Mey2008 (talk) 15:12, 18 June 2014 (UTC)
@User:K7L: Region maps can be static/dynamic [80] or fully dynamic [81]. -- Joachim Mey2008 (talk) 05:47, 19 June 2014 (UTC)
It looks like the Rheinburgenweg maps do contain 'D' markers for destinations not on the route; they're less visible because the individual maps are zoomed to 13-level (almost city-scale) instead of showing the entire itinerary (which appears to be about 200km, much like Rideau Canal#Go). If Route 66 is 2448 miles (4000km) and Trans-Canada Highway double that, it would take many individual maps to fit them all onto zoom-13 level. I'd added a map to Rideau Canal, but left the 'D' layer turned off and used marker|type=city as otherwise it seems to pull in everything from Canton to Calabogie - which are not on the route. K7L (talk) 14:35, 19 June 2014 (UTC)
Such long routes can be made ​​without detailed maps. Or just a few detailed maps for particularly interesting parts. Often also helps to click on the colored markers in the article text and zoom a little. -- Joachim Mey2008 (talk) 15:19, 19 June 2014 (UTC)

Dynamic maps icons[edit]

I can't recall where but there was a discussion which it was suggested to remove or hide listings icons when using dynamic map from showing on the articles. Anyone who can point me to that direction please? --Saqib (talk) 21:06, 14 June 2014 (UTC)

Dynamic Map - small improvements[edit]

Version 2014/18[edit]

  1. The destination layer was enlarged to about 500 x 500 km.
  2. The destination link is now clickable in mapframe and opens in a seperate tab.
  3. Markers with preview images are marked in the tooltip.
  4. Preview images are now clickable in mapframe and be enlarged in a seperate tab.
  5. The buttons "Destinations" and "All markers" now have a handy toggle function.
-- Joachim Mey2008 (talk) 12:47, 16 June 2014 (UTC)
Thanks Joachim! --Andrewssi2 (talk) 12:58, 16 June 2014 (UTC)
Are you still planning to expand the Destinations layer to show all markers worldwide eventually?
Thatotherpersontalkcontribs 00:26, 17 June 2014 (UTC)
The display of all the 20,000 markers is too slow on some computers (eg mobile phones). I need some time to optimize the script. -- Joachim Mey2008 (talk) 04:31, 17 June 2014 (UTC)
Just out of interest, why is this feature desirable? (the ability to show global markers) Andrewssi2 (talk) 08:32, 17 June 2014 (UTC)
The idea was to make it so that a region or itinerary map could be any size without exceeding the boundaries of the Destinations layer, but that won't be necessary if we use the marker template instead as described above.
Thatotherpersontalkcontribs 00:35, 18 June 2014 (UTC)
I see, thanks! Andrewssi2 (talk) 01:36, 18 June 2014 (UTC)

Version 2014/19[edit]

  1. Fast zooming by holding [shift] + click button [+] or [-] (improved)
  2. Fast zoom in by holding [shift] + drag rectangle (improved)
  3. Markers with link to WV-article possible, both in map and article. Example: 1 Hildesheim {{marker|type=city |name=[[Hildesheim]] |lat=52.149 | long=9.952 |zoom=12}} (new)
  4. Minimal zoom level = 0 (new)
-- Joachim Mey2008 (talk) 14:20, 26 June 2014 (UTC)
Love it, especially point #3, but you seem to have broken the mapmask functionality. Even trying to manually activate it with layer=OG doesn't work.
Thatotherpersontalkcontribs 01:10, 27 June 2014 (UTC)
Thanks for the error message. This error affects both GPX files and Mapmask. I would test more and to watch less football. Hopefully fixed for next version. -- Joachim Mey2008 (talk) 04:49, 27 June 2014 (UTC)

Version 2014/20[edit]

  1. Mapmask function has been corrected
  2. Mouse scroll zoom is turned off by default
  3. Right-click turns on the mouse scroll zoom

-- Joachim Mey2008 (talk) 12:15, 30 June 2014 (UTC)

Version 2014/21[edit]

  1. New: Double-click zooms and centers.
  2. Modified: Left-click enables scroll zoom.
  3. Modified: Right-click shows coordinates.

-- Joachim Mey2008 (talk) 11:48, 7 July 2014 (UTC)

Detailed maps[edit]

Have added templates to aid with sections of itinerary routes.

  • {{Map key}} provide color code key for POIs
  • {{PoiMap2detail}} formats the poimap2 with right aligned text block.

Examples of use at Rheinburgenweg, Rheinsteig and Wales Coast Path. --Traveler100 (talk) 21:05, 19 June 2014 (UTC)

Can we rename that second template to something a little simpler? Maybe {{detailmap}} or something of the sort.
Thatotherpersontalkcontribs 01:25, 20 June 2014 (UTC)

Dynamic map placement[edit]

Swept in from the pub

Many travellers who don't travel first class or with a team of sherpas (what you you might characterise as the backpacker variety) don't travel with an expensive smart phone or tablet and certainly not with a full size monitor. No, they're often using notebook size screens.

Equally many denizens of third world countries who can only dream of travel with a legitimately obtained visa, only have the first world hand me downs of small screens with obsolete resolutions.

In most of the globe, connections are slow or very expensive or both.

If the initial map "keyhole" is reduced too much in size, things become unworkable, since to load a full screen version of the dynamic map simply takes too long or is too expensive. Speaking from bitter personal experience of third world travel, I've found it impossible to edit many destination articles because a large page takes too long to load.

The optimum size in these circumstances is probably about 560px since that size, if centered doesn't mess things up with a thin worm of text squeezed to the left of a right aligned map.

Please note that this is entirely different from thumbnails since their default is only 220px wide and there is, therefore room for text to flow on their left hand margin.

Please could I make a plea to NOT right align dynamic maps - or at least wait a few days until I've finished updating and adding the locations on the ground?

Many of our African articles are out-of-date and/or rather sparse so surely those people sitting comfortably behind their modern, state of the art, humungous great screens could put up with a little white space so that folks actually out there in the countries concerned have an adequate experience? -- Alice 15:30, 29 May 2014 (UTC)

Disagree quite fully. The maps should never be changed from their default size and right-alignment unless it is otherwise impossible to properly frame the area in question. Putting a giant centered map not only duplicates the purpose of the full screen map, it creates a chasm in the flow of the article, creates a lot of unnecessary white space, and increases the amount of scrolling between the map and the corresponding listings in the article. Texugo (talk) 16:16, 29 May 2014 (UTC)
To Texugo's point, there was previously a discussion on this point at Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site? and the consensus seemed to be to always use the default map size unless an alternate size was need for a specific reason, such as when an area was shaped in such a way that the map needed extra vertical or horizontal space. That guidance was then captured in Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment (item #4). -- Ryan • (talk) • 16:28, 29 May 2014 (UTC)
I'm sorry that I've failed to communicate my reasoning clearly.
If everyone on earth (and, more pertinently, all travellers and potential travellers) had affordable, fast connections and viewed WV on largeish screens (or mobiles, when the layout is custom adapted) I would thoroughly agree with a default alignment (as for thumbnails) of right.
Unfortunately for a substantial (but highly handicapped minority) that's not the case. Surely you don't want to handicap those users further for a minor aesthetic niggle?
An analogy would be the construction of ramps for public buildings to allow easier access for those who are not too spry. It costs money and a bit of uglification but surely you don't begrudge that to enable easier participation in the community for those not as fortunate as yourself?
It will literally be impossible for me to geo-code many African destination articles if you keep changing the map size, zoom levels, and layers a few days after I've added them... -- Alice 16:36, 29 May 2014 (UTC)
I have set the map window to the default values​​. So the article Entebbe appears faster than before. Please press the [Control] key and click on the link "View full-screen map for Entebbe". A full screen map is loaded on a separate tab then. Now you can use them for coordinates, without having to open the article with a big mapframe again and again. Alternatively, you can use this map [82] in a separate tab. I have tested everything with a simulated very slow phone connection. -- Grüße, Joachim Mey2008 (talk) 17:58, 29 May 2014 (UTC)
There isn't unfortunately a 'one size fits all' approach to faciliate the rendering of maps for low bandwidth/small screens and high bandwidth/large screens.
There is however no problem in using a different (lower bandwidth) service to determine your longitude/latitude and input them into individual listings direcly. Andrewssi2 (talk) 04:19, 30 May 2014 (UTC)

Thanks Joachim and Andrew: although I continually get the error message "504 Gateway Time-out nginx/1.5.0" with the full screen map at https://tools.wmflabs.org/wikivoyage/w/poimap2.php?lat=0.314&lon=32.578&zoom=15&layer=M&lang=en&name=Kampala, your suggestion of http://maps.wikivoyage-ev.org/w/geomap.php is indeed loading (albeit very slowly for me). It's really nice to get away from the diesel stinky air of Kampala. The roads are like Bavaria around here, smooth tarmac with new & precisely painted centre lines and beautifully executed verge marking lines; there are even central reflectors and armourguard on the bends... -- Alice 18:56, 30 May 2014 (UTC)

Dynamic map server is on the fritz again[edit]

Swept in from the pub

503 Service Temporarily Unavailable nginx/1.7.0

How can the dynamic map server be made more stable? How many people are currently working as sysops for the server? Ikan Kekek (talk) 11:29, 11 May 2014 (UTC)

There is no separate server for dynamic maps. The application "poimap2.php" runs as project "Wikivoyage" on the servers system "Tool Labs" by the Wikimedia Foundation [83]. The project "Wikivoyage" is managed by User:torty3 and User:Zhuyifei1999. For the project itself so far there were no program crashes.
The inaccessibility always concerned the entire server system and all the other projects that are stored there. Our project managers have no influence in this matter. The server system is maintained by administrators of the Wikimedia Foundation [84].
The projects of the former tool server at the German Wikimedia Foundation are being integrated to end-June [85]. This unfortunately occurred partly overloads or crashes. I hope the tools labs servers are stable thereafter. -- Joachim Mey2008 (talk) 05:35, 12 May 2014 (UTC)
You guys do a great job, but there are only two of you. Is any effort being made to try to recruit more sysops? Ikan Kekek (talk) 05:38, 12 May 2014 (UTC)
As I'm busy myself and torty3 is inactive since March, if anyone here wants to be one of the maintainers, has the technical ability to maintain the project (eg. login is complicated), and seems to be trusted (eg. admin?), I'd be happy to add him to the assess list.
As for the "503 Service Temporarily Unavailable nginx/1.7.0", there's no way to fix that problem by tool maintainers. Every tool with web interface uses (by default) lighttpd attached to different ports on the grid engines. However, the actual tools.wmflabs.org is a nginx-based proxy server which only the roots of the tools project have access to. Therefore, in case anything like "503 Service Temporarily Unavailable nginx/1.7.0" (no fancy decorations or explanation texts), please report the issue to the labs-l mailing list or the #wikimedia-labs channel on freenode IRC. --Zhuyifei1999 (talk) 05:35, 24 May 2014 (UTC)
Well, I believe I should volunteer. However, I have no access to wikitech and tools, so I will request it now and let you know when it's ready. In the meantime, everyone is welcome to object if you think that I am not trustful-) --Alexander (talk) 05:48, 24 May 2014 (UTC)
For reference, I have given Alexander the access to the tool. --Zhuyifei1999 (talk) 02:34, 25 May 2014 (UTC)

Missing magnification & layer selection[edit]

I don't know whether this is an aberration peculiar to very slow and intermittent internet connections (I'm moving around between Uganda, South Sudan and Rwanda right now) but I'm completely missing the zoom and layer selection buttons right now.

This makes it very difficult to update listings, never mind being a great leap backwards for most travellers, so if this was a conscious decision (similar to the recent "improvements" to make Firefox look more like Chrome), please could it be reversed? -- Alice 09:31, 22 May 2014 (UTC)

Layer selection and zoom buttons are missing only when low memory, for example, in a mobile phone. The script needs to be optimized. -- Joachim Mey2008 (talk) 14:34, 22 May 2014 (UTC)
Thanks for the hint, Joachim. While it's true that Firefox has been "leaking" memory for years and this latest version certainly seems no better in this respect, I have actually now had the bizarre experience of opening more tabs (I went from 10 to 17 on my trusty notebook) and the buttons re-appeared! Go figure. -- Alice 19:36, 22 May 2014 (UTC)
Same problem on a very powerful Linux computer. Only the zoom level is shown. All of the other controls are missing: http://i.stack.imgur.com/hR9bn.png Reproduced on Firefox and Chrome. Nicolas1981 (talk) 04:29, 23 May 2014 (UTC)
Oh dear.
I was hoping that this was just a rare problem related to the recent downgrades of Firefox (27.0 - 29.1 under Windows7). Your post and screenshot indicates that there is/was a wider problem since your American map (presumably displayed under Unix) shows the exact same aberration I was having problems with. However, there are an awful lot of markers on that American map, so this could still be a memory artefact, yes?
@Mey2008: have you made some code changes in the last 24h? I can't reproduce the problem today.
Incidentally, I see there is a neat new feature which now groups overlapping markers together on a dynamic map so that just one round orange disc with a white plus sign in the centre is displayed (example here). -- Alice 05:42, 23 May 2014 (UTC)
The error is due to the last automatic synchronization, yesterday at 9:30 11:20 UTC. Some data for the English version were transferred only partially. On the WV-ev-Server (original scripts) everything works properly [86]. Please wait for next synchronization. -- Joachim Mey2008 (talk) 09:07, 23 May 2014 (UTC)
OK. May I ask how often those automatic synchronizations take place? Once a week? ϒpsilon (talk) 09:11, 23 May 2014 (UTC)
Current settings is to update on 11:20 (UTC) every Monday and Thursday. But I'll ask an administrator to an additional manual synchronization, as soon as possible. -- Joachim Mey2008 (talk) 09:31, 23 May 2014 (UTC)
The update has been corrected by User:Zhuyifei1999. Thanks! -- Joachim Mey2008 (talk) 15:37, 23 May 2014 (UTC) (if applicable [87])
Thanks for the update, User:Zhuyifei1999 and for keeping us informed, Joachim. I encountered the same problem on 6 different machines at 5 different hotels here in Entebbe this afternoon from 12:00-17:20 UTC. -- Alice 17:44, 23 May 2014 (UTC)
I'm not sure what happened, but as far as I know nobody did anything manually since April, except for the automatic updates. I saw an email just now and did a manual update without knowing this has already been fixed. --Zhuyifei1999 (talk) 04:57, 24 May 2014 (UTC)
Fixed (at least for me) thanks a lot :-) Nicolas1981 (talk) 06:07, 26 May 2014 (UTC)

Update this page?[edit]

Is it not time to update this page to reflect the fact that we've pretty well settled on {{mapframe}}, and then use the page to address other issues and challenges moving forward? Texugo (talk) 17:28, 9 August 2014 (UTC)

No, {{mapframe}} is just one method. We also use static maps and {{geo}} tags. K7L (talk) 19:07, 9 August 2014 (UTC)
Um, well, yeah. I don't disagree with that at all, K7L. The point was that we could archive all those things that we don't use and haven't even experimented with in ages, of which there are many, and use this page to organize around current challenges instead. Don't you agree with that? Texugo (talk) 02:55, 15 August 2014 (UTC)

Print versions[edit]

Swept in from the pub

The argument that Wikivoyage guides "also have to work offline / in print" is often raised, and I do agree, but I believe our print versions lag behind our online version at this moment. For example, dynamic maps are rendered when clicking "Printable version", but when you make a PDF or book out of your selected guide(s), they disappear. What is worse, the POI numbering disappears as well, so even if you print the dynamic map from the "printable version" level, you have no key.

There are other issues with print I noticed, but the ones above are most pressing IMHO. Can we do something to rectify that? PrinceGloria (talk) 05:25, 12 June 2014 (UTC)

Print and PDF functions are not perfect in Mediawiki. Background colors (POI numbers) and embedded windows (dynamic maps) are not printed. - I use the browser's print function instead (Firefox, IE, Chrome). Page setup: background colors on, landscape. PDFs (see example) I create with a PDF printer driver (e.g. Foxit Reader's PDF Printer). -- Joachim Mey2008 (talk) 05:57, 12 June 2014 (UTC)
Thanks for the tips, I figured out so of my own as well. That said, if we have explicit links to "print version" and "make a PDF", we should make them work or disable them and agree that for the time being we do not explicitly support printing. Oh, and the banners don't print either. Can we rectify this ourselves or do we need to raise that higher up with at the Meta? PrinceGloria (talk) 06:14, 12 June 2014 (UTC)
No, we have no control over PDF rendering. Of course, you can raise this issue at Meta, but you will have to be very persistent about it, because nobody touched the PDF module in the last few years. --Alexander (talk) 07:54, 12 June 2014 (UTC)
I don't think your edit summary is appropriate - we actually CAN, and you said what we can. I would hate for it to be "me" rather than "us" though, I sure hope I am not the only seeing this situation as bad, but one that can be changed. If nothing was done about the PDF module for years, then the potential that something CAN be done is actually quite big. PrinceGloria (talk) 08:04, 12 June 2014 (UTC)
Well, I am sure that your request will gain some support. The problem is that PDF's can't be tuned by standard editing tools that are accessible to admins. It is something about the PDF extension, so you need programming skills and eventually you have to add the modified PDF extension to the new MediaWiki release. We don't have people with the necessary experience and personal connections to code developers, except for, perhaps, Roland on de:
I think that the best strategy is to raise this question on some bigger Wikipedias and see whether people with strong technical expertise want to work on it. For example, one crucial technical issue is to make PDF converter recognize CSS styles. This will solve our problem with the POI numbers that are currently missing in PDF. --Alexander (talk) 08:15, 12 June 2014 (UTC)
Maybe a simpler approach:
# Take a screenshot of the Dynamic Map and save it as a static file
# Use this file instead of Dynamic Map in the Print View
# Profit?
Obviously you restrict yourself to one zoom level, but it is more acheivable. --Andrewssi2 (talk) 08:21, 12 June 2014 (UTC)
This is just admitting defeat - I print my dynamic maps as screenshots for my own purposes, but we shouldn't have to update screenshots everytime an article gets edited to have an up-to-date print version. I will raise that at Meta in due course, I am sure there are many people with appropriate programming skills in the Wiki community. PrinceGloria (talk) 08:25, 12 June 2014 (UTC)
Updating a screenshot isn't too difficult. The real problem with printing dynamic maps is that there's no way to expand the marker clusters once you've printed the map, leaving some POIs hidden beyond usability. I wonder if it would be possible for a full page to be added at the end of the print version showing an auto-generated screenshot of the dynamic map at the automatic zoom level? It wouldn't completely guarantee a lack of marker clusters, but it would reduce them as much as we can hope for.

Regarding your question above about including banners in the print version, I'm pretty sure it would be as simple as deleting <div class="noprint"> and the corresponding </div> tag from the {{pagebanner}} template (or, alternatively, we could move those tags so the banner prints but the table of contents doesn't) if there is consensus that the banners should be included in the print version. I would support the idea, since the banner is often an important image with no equivalent anywhere else on the page.
Thatotherpersontalkcontribs 02:30, 13 June 2014 (UTC)
This is a double-edged sword - there usually is one or more outlying POIs for every city/district article (except for small, well-formed districts that lend themselves well for mapping), which would lead the automatic function to zoom out and leave most of the POI-dense area and unlegible sea of yellow pluses somewhere near the middle of the map. That would not serve the traveller well either, or even less. I would trust the collective users' intelligence in formatting the map for online display and print by selecting which POIs to show, what zoom level to adopt and where to cut off the map, better than an automated solution.
Further on automation - do note that we deliberately made adding and editing a POI very easy in hope of having as many editors as possible jump in. This means that POIs are often added actually wrongly and with incorrect coordinates. We even discussed recently with User:Ikan Kekek how our own geolocation tools end up locating POIs in wrong cities (even if with correct street addresses, but this isn't much help) as we could two Berlin restaurants auto-located in Zurich and Leipzig (one each). Given that every new edit may change that, the numbering of POIs etc. and that direct edits to POIs are on the rise, I find generating a screenshot version of the map something impossible and quite pointless (we would be almost always guaranteed to have an outdated version of the static map that doesn't match the article).
If anything, we may want to ask Joachim to add a feature that not only indicates the existence of POIs outside of the map range, but also marks the POIs on the map's edge with icons, colours and numbers and maybe even distances. But until then, I believe the map does a fine job of letting people know there is something outside the map's scope, and the POI description also should make a mention that something is farther away. PrinceGloria (talk) 03:26, 13 June 2014 (UTC)
Supposedly, a POI that's slightly off the map is indicated as a semi-transparent blue semicircle at that edge of the map. For instance, Oswego#Get around shows this in the lower portion of the right-hand edge as an Oswego Speedway (Do:1) at the edge of town is off-map. A pair of restaurants (Eat:1,8) which are barely in the visible map area appear to also trigger this. There is no one position in which the on-page inline map shows every POI clearly without either clustering (+) or pushing a few off-page, and Oswego (pop 18000) is one of the easier, more palatable choices as a reasonably compact city. A large city (if not broken into districts) would be more difficult, but that's not the only issue. For sprawling Lac-Mégantic (pop 6000) all I can say is "bonne chance" as the tourist area wraps around the lake into the rural countryside and includes a pair of provincial parks 20-30 miles (30-50km) distant. Radiator Springs is worse, as that's an itinerary; even if it only covers half the main Route 66 beaten path, that's still 1200 miles from Baxter Springs to Peach Springs. (There's no map on our main US66 itinerary yet.) There's no map on our Underground Railroad article, but with multiple routes (anything from Ohio to Pennsylvania) and multiple POIs on each, they'd never all fit at once. Trans-Canada Highway would be the extreme case, no dynamic map, no POIs as the article scope is ridiculously the entire country so little or no detail can be provided at the local or regional level in such an overview.
A static map for a city with a static inset for downtown would be typical for a large city description in a standard printed guide. There is no one dynamic map view which fits everything without some scrolling, zooming and manipulation that isn't available in print. It's not just Wikivoyage, good luck taking something like http://ridewithgps.com/routes/3705636 and finding one view that fits a 170km cycle trip on back roads but still has enough detail to even see which roads are being taken? Couldn't see one, and bringing a laptop PC on the road isn't an option if that map was intended for cyclists. K7L (talk) 17:29, 13 June 2014 (UTC)

Articles can have an overview map and any number of detailed maps [88]. With a PDF printer driver, the complete article (incl. all maps) can be printed [89]. -- Joachim Mey2008 (talk) 19:08, 13 June 2014 (UTC)

Bug report for print version?[edit]

Would it be worth opening a bugzilla: item? Issues with the MediaWiki code (or an extension) are more likely to be seen by developers there than in meta:. K7L (talk) 13:58, 12 June 2014 (UTC)
What you are asking is technically challenging, and as an IT person I would really categorize this as 'High cost, low benefit' when evaluating the value of developing this feature.
By all means raise a request in MediaWiki. I would just suggest that you may want to consider other options in the meantime that are lower cost. Andrewssi2 (talk) 15:12, 12 June 2014 (UTC)
MediaWiki software does need a good PDF converter. It will be useful even for Wikipedia, let alone other (non-WMF) sites that are using this software. The problem is that technical efforts are often spent for useless things such as new fonts or MediaViewer, so indeed, we can hardly expect any technical improvements unless we know people who are both interested in the PDF feature and can implement it.
Anyway, a bug request will not hurt, so anyone willing to submit could should mention the following crucial features of the PDF converter:
  • Render CSS styles
  • Control the inclusion of images (ideally, one should be able to decide whether images are included at all, and if they are, which of them should be included)
  • Render iframe environment
--Alexander (talk) 16:43, 12 June 2014 (UTC)
Guys, would any of you familiar with Bugzilla be willing to file the above bug? I would like to concentrate on addressing the Meta this weekend. Let's push for it on all fronts, loudly and repeatedly, and we will be heard. PrinceGloria (talk) 20:39, 12 June 2014 (UTC)

At a point in time when Internet access is available even in the most off-the-beaten-path Third World backwaters, I really question our continued emphasis on maintaining a print version. We're Wikivoyage, the free online travel guide that anyone can edit. I, for one, see hard-copy travel guides as a separate niche, and a dying one at that. I wouldn't mind so much if our dogged insistence on accommodating a dwindling number of readers who prefer a Stone Age approach to travel literature weren't hamstringing our efforts to incorporate technological advances on our site, case in point the skepticism some of us still have about dynamic maps. -- AndreCarrotflower (talk) 17:19, 12 June 2014 (UTC)

Andre, you may be surprised, but on a train between Moscow and Saint Petersburg, which are two biggest Russian cities, you will find only sporadic internet connection. And if you try to read a travel guide from your smartphone or tablet in a smaller Mexican city, you will simply lose your favorite gadgets (at best). So printed travel guides remain a must for those people who really travel and not just visit popular tourist destinations. It is also important that the printing option does not hamper any "technological advances". However, both on-line and off-line versions must be developed in parallel. --Alexander (talk) 18:56, 12 June 2014 (UTC)
Further on this - while I find the "gotta mind the print version users" as abused as "gotta mind the people with low bandwidth" argument to throw stones into the cogs of progress, I believe the print version continues to be very relevant even in the digital age. Not only is it useful in places with scarce Internet connection - I tend to have a phone online all of the time with me, and generally travel with at least one laptop, but running around a new city with an open laptop is not an option, and mapping out my route using a mobile version of Wikivoyage would be a folly. I always carry a printed version of the guide I need, with my handwritten comments, directions etc. on it, which I can fold into my pocket and consult wherever I find myself. The print version is an important aspect of Wikivoyage and we should pay it appropriate heed. PrinceGloria (talk) 20:39, 12 June 2014 (UTC)
Yeah, I don't think the printed version should be paramount, but there sure are areas with no cell phone or Wi-Fi signal at all, including a very long stretch of central California coast. Ikan Kekek (talk) 21:11, 12 June 2014 (UTC)
One of my long-term goals is to improve the handling of printable versions of our guides. WTP had a pretty decent engine; it had its flaws but it was much more flexible and customizable than the current. I will say, however, that printing dynamic maps may always be problematic simply due to their dynamic nature. I would certainly not support ignoring print versions simply because dynamic maps -- which are still an in-development, somewhat experimental feature -- were added without thinking of the print impact first. Powers (talk) 21:27, 12 June 2014 (UTC)
Did WTP use a custom MediaWiki extension? Who developed it, who may have the code, and how does the code look like? --Alexander (talk) 22:08, 12 June 2014 (UTC)
Alexander, I believe Jani is the only one still here who knows about the printed guides. ϒpsilon (talk) 12:39, 13 June 2014 (UTC)
I don't own a smartphone or tablet. On some recent trips I have taken no computing device and used no internet. In Addis Ababa I visited two internet cafes but neither had any connection at the time. I only had what I printed before I left home. Just saying. Nurg (talk) 11:23, 13 June 2014 (UTC)
In many parts of the world there you can indeed not get online anywhere you wish. Also, it's not always a smart idea to flaunt a laptop/tablet/smartphone maybe worth four months' local salary. I now and then print out travel guides (4 pages on an A4 + cut & staple makes a good palm-sized travel guide that doesn't mark you out as a tourist on the street) and for me they work well as they are now. ϒpsilon (talk) 12:39, 13 June 2014 (UTC)
WTP used a standalone engine unrelated to Mediawiki; it took the supplied articles as plain wikitext and parsed them to produce LaTeX output, including automated ToC, page headers, and indices. Manual index entries could be produced via Template:Index. Internal links automatically became page references within the book; external links were automatically expanded in-line. Images could be set to print as two pages, as a full page, grouped with two per page, floating within the text, or as the lead image... just by changing a keyword in the File tag. The LaTeX was then used to generate a printable PDF. The output format (about 5"x8", two columns) was ideal for travel. Powers (talk) 13:41, 13 June 2014 (UTC)
LaTeX sounds great. A stand-alone thing could also work for us if WMF is not interested in improving their own PDF extension. But the question is: who was involved in WTP, and who may have the code? Is it only Jani? I believe we had quite a few old admins on the old (pre-migration) mailing list. Some of them might be accessible by e-mail even if they no longer contribute to the project. --Alexander (talk) 15:01, 13 June 2014 (UTC)

(undent) Wikitravel Press is dead and buried. The code we wrote is far inferior to the Pediapress version, which is currently used for printing to PDF across all WMF wikis. It's mostly open source, if you want to improve handling of dynamic maps etc, that's the place to contribute. Jpatokal (talk) 05:14, 23 June 2014 (UTC)

Thanks! Good to know! --Alexander (talk) 11:12, 23 June 2014 (UTC)
Before I go pester Pediapress to provide support for printing out our maps and listings, I just wanted to make sure whether we don't actually "noprint" those features? PrinceGloria (talk) 08:45, 24 June 2014 (UTC)

Bugzilla[edit]

I can file bug reports. Can we work out here exactly what we want it to say, and perhaps a link to an ideal example? WhatamIdoing (talk) 15:56, 13 June 2014 (UTC)

We don't have an ideal example. Three main features that I can envisage are as follows:
  • Render CSS styles
  • Control the inclusion of images (ideally, one should be able to decide whether images are included at all, and if they are, which of them should be included)
  • Render iframe environment
--Alexander (talk) 16:03, 13 June 2014 (UTC)
Ah, I meant an ideal example of the problem, so that any interested dev could easily look at it and see that it's broken. WhatamIdoing (talk) 16:18, 13 June 2014 (UTC)
That's easy. Go to any page with POI markers (say, Berlin/Mitte) and click Download PDF to see that the PDF file is missing the map, all POI markers, and the page layout is anything but ergonomic. --Alexander (talk) 16:55, 13 June 2014 (UTC)

Quick update: There are now plans to replace the existing pdf tool. The schedule has not been set, but it will probably be at least six months from now. It sounded like PediaPress is discontinuing support.

If there are other things that you'd like to have added to bugzilla:68008, please let me know. WhatamIdoing (talk) 22:18, 14 July 2014 (UTC)

Do you have any links to more information on this PDF tool replacement, WAID? I'd like to get involved in its development. Powers (talk) 22:50, 14 July 2014 (UTC)
All I've seen is this: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077516.html WhatamIdoing (talk) 21:00, 15 July 2014 (UTC)
Alexander,
There's a question at bugzilla:68008 about why someone might want to exclude images. Do you have something in mind beyond the obvious "people might not want to bother downloading/printing them"? Whatamidoing (WMF) (talk) 17:20, 17 July 2014 (UTC)
Thanks for posting our request on bugzilla. I added a comment there, although it is pretty obvious indeed. --Alexander (talk) 18:22, 17 July 2014 (UTC)

Dynamic map templates[edit]

Swept in from the pub

According to Nemo_bis comment on meta there's a privacy violation with the use of current dynamic maps (and all the equivalent templates on each voy language version).

Please take part to the discussion to understand how to proceed in a coherent way within the whole wiki-project. Thanks, --Andyrom75 (talk) 05:31, 9 August 2014 (UTC)

As I suggested over there, there is a replacement called WikiMiniAtlas that can possibly be used. However, this is a serious issue that should be addressed ASAP. --Rschen7754 01:15, 14 August 2014 (UTC)

Position of dive sites not shown on dynamic maps[edit]

The Geo template which displays the map icon at the top of the article does not display the position of the dive site when the map is opened. By their nature, most dive sites are in the sea, which is a vast featureless expanse on the dynamic maps, so the lack of any indication of the position of a dive site on the map makes it far less useful than it could be.

Is there any simple way of getting the map to display:

  • an icon at the position of the dive site that the article is about (vital importance)
  • an icon at the position of each nearby dive site (nice if possible)

Cheers, • • • Peter (Southwood) (talk): 09:37, 19 August 2014 (UTC)

Can you provide an example? When I open a map full screen (by clicking on the icon) then it shows the position of each geo-encoded listing in the article.
Also although dive sites are at sea, are they not often relative to a coastline? Andrewssi2 (talk) 09:54, 19 August 2014 (UTC)
The dive site itself is not in a listing when the whole article is about the dive site, However Joachim Mey has shown [90] me how to add a zoom and layer to the template, which does the job. • • • Peter (Southwood) (talk): 12:40, 19 August 2014 (UTC)

Marker types in dynamic maps[edit]

Swept in from the pub

I recently filled out the "Cities" and "Other Destinations" subsections of the bottom-level region Cattaraugus County, adding inline marker templates for each. However, when I tried to use the City marker type for Allegany State Park (in "Other Destinations"), it displayed as #1 on the map - the same as the first entry in the list of Cities. To eliminate the ambiguity, I changed the "type=" parameter to Listing, but it just doesn't look right to me.

My question is this: Do we have an "Other Destinations" marker type that can be used instead? As a matter of fact, can someone give me a definitive list of all the different types of markers that we have for dynamic maps? Besides "city" and the standard See, Do, Buy, Eat, Drink, Sleep, and generic Listing), I know that we also have Go, which we use for bus depots, train stations, subway stations, etc. Are there any others?

-- AndreCarrotflower (talk) 02:51, 10 September 2014 (UTC)

To be honest, I think we are overdue for a discussion about how dynamic maps should be used in region articles in the first place, and in particular, the marker icons of {{marker}} which go beyond those used for the listing-based markers. The "city marker type" is something that was put in there by User:Torty3 when he created the template, and I believe it escaped the attention of most of us and was never in fact discussed how or when or if it should be used. (The same for the go, view, and vicinity types, which I didn't even know existed until I looked at {{TypeToColor}} just now.) There are some concerns I think we should discuss regarding use of markers in region article dynamic maps, including the question of whether we want the typical one-liner lists in the Cities/Other destinations/Go next sections to become numbered lists (which may give the impression of a ranking), the fact that the map is often already showing the cities and the icons actually obscure them (I've definitely seen some region maps somewhere where practically all the cities were already represented but icons were superimposed anyway), and the fact that some region articles also contain listing types, so the map ends up with a mix of icons of different magnitudes, i.e., for single attractions and for whole cities. There is also the question of whether it would be better to use the OD layer which automatically shows pointers for places we have an article for, instead of manually placed POIs. I've seen this in use in some articles too.
We currently have 82 region articles with a dynamic map. I think we should call a moratorium on new ones for the time being, look carefully through the existing ones and see what has been tried, what can be done, what problems and issues there may be, what improvements can be made, etc., and then talk about how we should be implementing these for region articles, so that we can do it in a consistent manner we all agree on. Texugo (talk) 03:08, 10 September 2014 (UTC)
I think that superimposing (the current way it is done) is the correct thing to do for now. OSM often does not show city names, sometimes showing the name of smaller things instead, so we are on the safe side with showing it. And since it is cited in the article, it should be clearly visible as a marker on the map. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)
I suggest we all analyze Western Finger Lakes in depth, take note of all problems, find ways to fix them, make it optimal, and use it as a base to decide what we want for the other articles. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)
I looked at Western Finger Lakes for 5 minutes and have not found any problem. The area is highlighted, there is minimal superimposition, points are sufficiently far apart from each other, it gives a good sense of how one could tour the area. Nicolas1981 (talk) 03:42, 10 September 2014 (UTC)

I favour Nicolas' approach so that discussion does not become too abstract and divorced from the current practical reality. --W. Frankemailtalk 11:04, 10 September 2014 (UTC)

I think we should look at more than Western Finger Lakes. It's a fairly rural area without a lot of destinations on the underlying map, so it's less likely to cause problems. Texugo, can you point us to some examples where the map already shows most of the destinations? The maps I've seen to date are more like Western Finger Lakes so the markers were necessary to make the map useable. -Shaundd (talk) 14:55, 10 September 2014 (UTC)
"minimal superimposition" is still a problem. There should be none. Powers (talk) 20:06, 10 September 2014 (UTC)
Slightly off topic -- marker template has an image argument -- would it be worthwhile to incorporate an image argument in the listings (see do etc.) template as well? -- Matroc (talk) 02:49, 11 September 2014 (UTC)
Do you mean that in the Sleep section, instead of small numbered squares you would have small numbered houses? I would say why not, it makes it very visual. Printed guides actually often have this house logo repeated for each hotel, even though the reader could understand that it is a hotel just by looking at the section header. 58.156.2.18 06:02, 11 September 2014 (UTC)
I was thinking more on the line of when you click on a numbered location on a map for a museum or cathedral etc. - a pop up image of that museum would appear... one can put an image in using the marker template but I don't see that option in the listing template... (numbered house icons sounds interesting though...) Matroc (talk) 06:23, 11 September 2014 (UTC)
Simply add the image= field and provide the filename. The picture will be shown in the pop-up window. We have been using this option in other language versions since ages... --Alexander (talk) 09:52, 11 September 2014 (UTC)
The image discussion should probably be separated off from this one, but it probably does need to be discussed be too before we start running with it, not least because having a listing image field in the buy/eat/drink/sleep sections would seem to encourage photos of businesses and we don't have any clear consensus to allow a blanket exception to our image policy against photos of businesses.
Back on topic, to answer your question, Shaundd, some examples of what I consider very problematic are
  • Wasatch Range - fills the map with icons that largely obscure the city dots, labels, and routes of the map
  • Sonora - most cities on the map are labelled, but obscured by the blue icons
  • Western Nevada - obscures the city dots and labels that would otherwise be visible, groups some cities with a plus so one has to zoom in to see them anyway (and if one is zooming in anyway, why not just consider the more accurate and well-labeled info that's already on the map?)
  • Nine-County Region - of the 20 cities with icons on the map, 13 of them would have a visible label if there weren't an icon blocking it
  • Southeast Arizona - uses the automatically displayed destination pointers, some of which block their own labels, and in combination with regular listing icons, some of which are grouped under little pluses meaning that the user has to zoom in 4 steps anyway, just to resolve them
  • Kathmandu Valley - also mixes regular listings with destination points, the two types overlapping each other as they try to point out everything from bus stops to individual attractions inside the cities, while also trying to show markers for the cities themselves
Like LtPowers, I don't really think we should be overlapping and blocking the stuff that's already on the map, and to be honest, I'm not very convinced of the need for city markers at all. The info is already on the map, even if you do have to zoom in a bit, and as the articles above show, putting city markers doesn't necessarily save you the need to zoom in to see what's going on anyway. Plus, many of our bottom-level region articles have 15-25 cities linked, and putting all those on the map really obscures a lot. I rather consider city markers to be pretty much redundant, given the high chances of the user having to mess around with the map anyway just to determine exactly what points on the map the comparatively large icons correspond to. One more feeling I have is that while I like the way we use icons in our city maps to supplement the information that's on the map with attractions, etc., using the same approach to superimpose icons on top of the cities that are already on the map at some level tends to disproportionately emphasize the cities aspect of the region, de-emphasizing the contours of the transportation systems, the landscape, the shaded park borders, and the other aspects that should make region maps less point-oriented. I'm also not a fan of the way it turns our one-liner city lists into numbered lists; I think it may give the impression of being a ranking. Texugo (talk) 22:52, 11 September 2014 (UTC)

I haven't read through everything new with dynamic maps, but to clarify a point, I did not add any sort of city markers, which was actually added on the 17th of June 2014 by User:Thatotherperson -- see [91]. And I haven't actually even touched the {{TypeToColor}}, so it just goes to show how opaque templates can be when used within other templates. I don't agree with the city markers either, though I probably won't comment any further than this for now. -- torty3 (talk) 03:01, 12 September 2014 (UTC)

Thanks for the clarification. Sorry I didn't get it right the first time! So wow, those got slipped in more recently than I thought. It appears that User:Thatotherperson is also responsible for a good chunk of the instances of it use, especially region articles across the southwest US. This should have been a more limited experiment brought up for discussion. Texugo (talk) 03:12, 12 September 2014 (UTC)
In the interest of full disclosure, I use "Go" markers in the Buffalo district articles for subway stations, the Greyhound station, the Amtrak station, rental car facilities, and one or two other transportation-related listings, and I also use the "City" argument in inline markers (using Template:Marker) for neighborhoods within each district as described in the "Understand" section. If we decide to disallow these types of markers, I would prefer to have a method of pinpointing these items on a dynamic map other than the undifferentiated "Listing" marker. -- AndreCarrotflower (talk) 03:03, 13 September 2014 (UTC)

These type of maps weren't added with no discussion at all; they were brought up on both of our dynamic map talk pages back in June. See here for the exact moment city markers were first implemented, and then here where I proposed updating the dynamic map guidelines to allow region maps. (Not many users commented on that specific proposal, but I figured plenty must have seen it due to the contentious debate going on in the same section, and no one expressed any objections to the region maps.) To those who would rather do without city markers, are you saying it would be fine to have thousands of destinations that don't appear on a map anywhere on the site? A lot of the city labels on the map tiles are only visible at high zoom levels, meaning you would have to already know where the city is to find the label. Powers Texugo claims the built-in labels are sufficient and cites Sonora (Mexico) as an example; I count only 3 out of 13 destinations that would have labels without my added markers, and even Hermosillo, the largest city in the region by far, is invisible at the necessary default zoom level. Imagine you're reading through a list of small towns in a travel guide for a desertous region when you discover the existence of "a bustling city of nearly a million people" — only to look over at the map they gave you and discover that you've been left to locate it yourself. I'm aware that it looks awkward to have overlapping icons and labels, but a map is a terrible place to choose looks over the presence of more information.
Someone mentioned the possibility of replacing markers with the Destinations layer. I would like to point out that the city markers were brought about specifically as a solution to a major problem with the Destinations layer: specifically, that it chooses which destinations get markers strictly based on distance from the map center, without any chance for author customization. In short, the city markers are currently the only way for a user to choose which cities get labels on a map, which I consider to be a functionality more important than appearance.
Thatotherpersontalkcontribs 09:20, 13 September 2014 (UTC)

Well said! --W. Frankemailtalk 09:44, 13 September 2014 (UTC)
I was completely unaware of the first conversation there and think such a change should have had wider exposure and an experimentation period.. The second 'proposak' you linked to was tangential to the discussion and not really addressed or even carried forward to the end of the discussion. We've never had a policy that "every town must be on a map somewhere", and every town is both already on the map at some zoom level and already linked from its own town page.,. I'll stand by every one of my points above... City markers are a very problematic solution to something that is not necessarily a big problem. Texugo (talk) 12:35, 13 September 2014 (UTC)
Where did I say that the built-in labels were sufficient? Also: "a map is a terrible place to choose looks over the presence of more information" could not possibly be more wrong. A bad-looking map is worse than no map at all. Powers (talk) 19:00, 13 September 2014 (UTC)
I think that, perhaps unwittingly, you may have crystallised a fundamental difference between different world outlooks. Some of us feel that the perfect should not necessarily be the enemy of the possible and the practical. This camp vehemently disagrees that a "bad-looking map is worse than no map at all". Now don't get me wrong, a well drawn map is a thing of beauty - but it also should be of practical use. Let's strive to make dynamic maps less ugly - but not at the expense of utility or having them at all. --W. Frankemailtalk 19:12, 13 September 2014 (UTC)
I agree with you that a bad-looking map is better than none, but only as long as it's clearer than no map. A map which is unreadable or more confusing than just reading directions might be worse than none. Ikan Kekek (talk) 19:26, 13 September 2014 (UTC)
I think a map would have to be *very* unclear before it’s worse than no map at all, and IMO, none of the examples cited above are worse than no map. I agree the city markers are problematic — they obscure information in the base map, the yellow pluses mean you have to zoom in, they’re not pretty and I don’t like the number lists — but to not have some kind of marker means our readers have to find destinations on their own. Is Little Town in the upper left, maybe the middle, or perhaps the bottom right? Nope, let’s zoom in another level and repeat. Still nothing, let’s zoom in again. Oh wait, now I’m so zoomed in I’m not sure I’ve covered the whole region. Sigh. Like many of these map discussions there’s an element of personal preference, but having no city markers seems to have a high potential for a poor user experience.
The background details on the OSM maps are nice, but at the end of the day, we write guides to destinations and people come to our site (I hope!) primarily to read those guides. If there is one thing I think our bottom level region maps should do, they should make it easy to locate those destinations we write about. Hopefully the dynamic maps can continue to evolve and improve (or, even better, people develop a sudden infatuation for Inkscape and produce bucket loads of beautiful static maps :-) ), but in the meantime I think superimposing city markers is a lesser evil than obscuring some of the background OSM detail.
I noticed some of the maps had listing markers and city markers on the same map. I thought we weren't supposed to have listings on regions pages? I fully support moving those markers off the region maps. -Shaundd (talk) 23:04, 13 September 2014 (UTC)
LtPowers, I may have confused your comments with Texugo's. I thought it was you who said the map at Sonora already had labels for most cities.
Thatotherpersontalkcontribs 02:53, 17 September 2014 (UTC)
No, my only comment prior to yours was to indicate that a good map should never have overlapping labels. Powers (talk) 17:10, 17 September 2014 (UTC)

We should not use "dynamic" maps for region articles. There is nothing dynamic about them. Cities don't close or change location as listings do, and listings are supposed to be moved to articles lower on the hierarchy, so why have a dynamic one? Besides, most of these maps look really bad and confusing. Static maps show regions, cities and other things relevant to travellers as curated by the maker of the map. Globe-trotter (talk) 09:01, 14 September 2014 (UTC)

Good points.
But an "inferior" dynamic map is still usually better than no map at all.
It's a sad fact that we have a limited number of editors able to draw good static maps. --W. Frankemailtalk 20:27, 14 September 2014 (UTC)
I disagree regarding there not being any use for dynamic maps on region articles – some regions are very sparsely populated, with attractions often many miles from the closest 'city', which may have absolutely nothing of interest and no facilities for travelers, thus not warranting an article. One such example is Dhofar, another is Southeast Arizona. Also after having traveled to some places where no maps are available anywhere, I do think a 'bad' map is better than no map at all. –StellarD (talk) 18:58, 15 September 2014 (UTC)

First of all, as others have pointed out, Globe-trotter's comment misses the point: the static map vs. dynamic map choice is a red herring; realistically speaking, for the vast majority of region articles the choice is between a dynamic map and no map at all. Secondly, in a larger sense, it also serves as a shining example of the hostility toward dynamic maps espoused by some in the static-map camp (here's another example), which in my view needs to end.

Wikivoyage is a website run by volunteers who give of their free time to contribute. Knowledge of Inkscape or other static map programs, or even willingness to learn them, are not prerequisites to membership in good standing among our community of editors. In fact, the primary reason why Wikivoyage added the dynamic map functionality was to democratize the creation of maps on our site, and thanks to that new feature over a thousand articles have maps now that didn't before. And dynamic maps have advantages over static ones - they're customizable, the zoom function allows for the inclusion of more content, and most important of all, for bottom-level destinations, the more user-friendly creation process also allows for easy updates when new businesses open or old ones shut down. I'd be willing to bet, without checking to confirm, that the majority of static maps on this site on bottom-level articles are at least somewhat outdated, and their usefulness to travellers has therefore degraded over time. We simply don't have enough hands on deck to continually update every static map on this site, and frankly, from the static-map diehards I see a whole lot more complaining about dynamic maps than upkeep on static ones.

It frankly boggles my mind that dynamic maps have been featured on this site for so long, and yet the bias against them is still so pervasive that someone has to stand up and defend them from being considered inferior or having the parameters within which it's "acceptable" to use them so tightly circumscribed. If we're worried about things like superimposition and aesthetic matters, perhaps the thing to do is to improve the dynamic map interface (or advocate at MediaWiki for its improvement) rather than writing off the whole feature. We decided to include dynamic maps in Wikivoyage based on community consensus, and whether some of us like it or not, they're here to stay. And people like myself who work very hard - again, on a volunteer basis, for no compensation of any kind - to add dynamic maps to articles should not have their efforts hamstrung by static-map elitists who would prefer that articles contain no content rather than content that isn't of their preferred type.

-- AndreCarrotflower (talk) 19:44, 15 September 2014 (UTC)

That is certainly not what I thought this conversation was about. I am perfectly happy to have dynamic maps in regions articles, especially when they have a mapmask to outline the region in question. But I think treating region maps they way we treat city maps is extraordinarily clumsy at best. Putting up to 40 point-based icons on the map for things that are not actually the same size, type or importance, covering up the more sensibly-scaled and labeled way that a dynamic map handles the same information - it's just a waste and a serious detraction from what a region map is supposed to be: an overview. The dynamic map uses different sized points and fonts to represent cities of different sizes and importances and doesn't try to squeeze every single destination on there with big identical shapes. A region article is supposed to give an overview of the region, leave the gritty details like addresses and phone numbers to the city articles; we don't insist that the city list should give the pronunciation or website or tourist center for every city listed — when a reader needs that info, they click through to the city. Similarly, a region map map should also give an overview — showing a handful of the cities, showing the major transportation routes, etc., not trying to include the geo detail of everything we have an article for. The solution for someone not seeing the destination they are looking for on the map is very simple - go to the article and look at the map there. There is absolutely no reason to crowd our region maps with blocky icons that obscure stuff when the gritty details should be left to the city articles. Texugo (talk) 21:53, 15 September 2014 (UTC)
My intention was not to hijack the discussion and send it into a different direction. Some of the points that have been made touch on a larger issue that has been festering in my mind for some time. As for your concerns regarding dynamic maps in region articles, Texugo, I agree with you, but I see that as more a matter of listings policy than of map policy. Any items other than City markers that clutter up a dynamic map in a region article are reflective of listings in the body of the article that shouldn't be there. That would be a policy violation whether or not the article had a dynamic map. -- AndreCarrotflower (talk) 22:09, 15 September 2014 (UTC)
Three of the regions with dynamic maps are Scottish islands that have no cities (Tiree and Islay) or only one city (North Uist). I don't see any of these having more city listings soon. Islands naturally form a region that can be much smaller than we would normally use, and we have not been consistent about whether to call these cities or regions. AlasdairW (talk) 23:15, 15 September 2014 (UTC)
AndreCarrotflower, but the city markers are themselves clutter, and if we were to start "ensuring that every destination article appears on a region map somewhere" as has been suggested, there will be quite a lot of maps with 25-40 city/other destination icons blocking much of the most important parts of their respective maps.
AlasdairW, all three of those island articles should be using a city template and not a region one, since that is the prevailing manner of dealing with standalone island articles. I have changed to the first two to cities, and marked the third one for merging with its one city — an island 20 miles across with 2000 people and a smattering of attractions can easily be covered in one single island-as-city article. Texugo (talk) 23:36, 15 September 2014 (UTC)
Texugo, I fail to understand how city markers are "clutter" on dynamic maps while dots with place names next to them are fine on static maps. As for bottom-level regions, if they contain 25 to 40 cities that's a pretty good indicator that they need to be subdivided. Also, parenthetically, I think we need to rethink the policy that says all destinations within a bottom level region need to be included on their "cities" subsection. It strikes me as pointless and inherently in conflict with our "Wikivoyage is not the Yellow Pages" non-goal. -- AndreCarrotflower (talk) 00:41, 16 September 2014 (UTC)
They are clutter because they exist in addition to the dots and labels that are already on the map. They are clutter because they jostle with each other unpredictably over the top of roads and contours and labels that would be better shown. They are clutter because they show the tiniest village the same size as the largest city when the underlying dynamic map underneath handles that information in a much more sophisticated manner. On a static map, or even on the dynamic map without icons, the dots and labels are arranged so that they don't interfere with one another, and not so many are shown at a given zoom level that it becomes unnecessarily distracting.
And it's not the right thread to discuss it, but not listing destinations in the bottom level region is not a good idea at all - that would just make it where a person investigating a given region cannot be sure they've found all our coverage unless they scour every article looking for sideways links to articles that have been left out of the hierarchy. Texugo (talk) 02:33, 16 September 2014 (UTC)
Would it be possible to develop a different kind of feature for each city listing which would, without reloading the whole page, re-center/re-zoom the mapframe to the given city? I think it would pretty easy in html, but I don't know about making it work here. Texugo (talk) 02:38, 16 September 2014 (UTC)
Texugo, six months ago you argued against the use of locator maps on this site by saying the following: "...city articles get a map for getting around within the city, region articles show maps for getting around within the region; any maps showing wider placement within the surrounding region belong in the next level up in the hierarchy...". That exact philosophy is the reason it's important to have comprehensive maps with every destination on them in lowest-level region articles. Otherwise we're pushing regional information, like the placement of cities within a region, into the city articles. I don't see how we can say that the lowest-level region articles are overviews when the articles below them intentionally leave large coverage gaps between the populated places with hotel accommodations. If we write the lowest-level region articles as overviews and push all detail into the city articles, then we're essentially trying to divide up the whole globe as a set of cities and their vicinities...at which point the cities become the new lowest-level regions. What is so terrible about the lowest-level region articles resembling city articles and the overviews being written as higher regions?
Thatotherpersontalkcontribs 02:53, 17 September 2014 (UTC)
That is taking me far out of context there. I was talking about static locator maps in that conversation, and I will still argue that we do not need those in every region article or every city article, etc. And dynamic maps even further eliminate any need for that kind of thing, allowing that information to be checked at the roll of a scroll bar. And in any case, I did not and would not insist that we should attempt to try to cram all the destinations for each bottom-level region onto a single map. But seriously, I do not see how anyone could think sticking 25+ icons on a map produces an advantageously usable result. You still can't glean information from that map without interacting with it anyway, and to even get an idea of how the cities are laid out, you have to either click on every icon or or cross-reference every one of them with the city list to tell what's next to what. That does not remotely constitute any advantage worthy of blocking the otherwise clearly legible information that is already on the map. As for the rest of what you've just posted, it sounds like you are proposing a fundamental change to the existing policy of discouraging listings from region articles or something, which would require a whole other discussion for us to address. Texugo (talk) 03:13, 17 September 2014 (UTC)
I don't see how I took your comments out of context. I know you were talking about static locator maps, but that discussion and this one both invoke the same basic question: if a reader wants to use Wikivoyage to learn the location of a destination, where should they look? If it's the region articles, then we need city markers. If it's the destination articles, then we either need a scrollable dynamic map on every one or we need a way to make the geo tag function noticeable to the average reader.
Thatotherpersontalkcontribs 04:40, 19 September 2014 (UTC)
But files on Wiki Commons can indeed be protected from unauthorized edits. This is the case for e.g. many featured pictures. -- Horst-schlaemma (talk) 11:51, 17 September 2014 (UTC)

Numbered icons on article page not matching numbered icons on a map![edit]

Swept in from the pub
Insure that listings of each type have both a latitude and longitude or both arguments are blank.
Everything will appear to be numbered correctly on an an article page (naturally the entry missing the long= argument
will not be numbered). However, here is the kicker: numbered icons after that entry missing the long= will
be increased by 1 on the map... For example: entry 5 on article page will be 6 on a map etc.
Example: - click on the icon numbered 5 for Gokoku-ji.. Hope that helps! Cheers! Matroc (talk) 02:57, 13 September 2014 (UTC)
To verify the coordinates of new listings please click the button 'map center <==> all markers' after saving. POI with incomplete coordinate pairs will be visible and may be corrected. - For further testing, you can use this script [92] . -- Joachim Mey2008 (talk) 07:17, 14 September 2014 (UTC)
Thank you! - hopefully this will assist anyone having this issue and send them in the direction of correcting a listings latitude and longitude information... Matroc (talk) 07:55, 14 September 2014 (UTC)
I think we should remove coordinates of POIs missing either latitude or longitude. Anyone disagree?
To start doing this, just open the latest CSV at http://datahub.io/dataset/listings/resource/15f9e529-22e3-4862-9a0a-ff77692c789d open it in LibreOffice or Excel, sort by latitude with sub-sort on longitude, and you will find them. I actually just did this sorting and saved the erroneous coordinates (and their article/POI name) here: http://datahub.io/dataset/fixes/resource/b8294c35-4829-45b0-aea5-39f2dde958a9 There are 103 to fix. Cheers :-) Nicolas1981 (talk) 07:06, 18 September 2014 (UTC)
Have downloaded the list and will update coordinates if possible, otherwise clean them up at my leisure. Matroc (talk) 23:22, 18 September 2014 (UTC)
Done - These have beeen taken care of! - Matroc (talk) 00:38, 20 September 2014 (UTC)
Does that mean that the lot of the stuff at User:Nicolas1981/Syntax checks can be deleted from the list? Nurg (talk) 04:11, 20 September 2014 (UTC)
I do not believe so as this is a slightly different issue, so No - Best to get Nicolas1981 to answer that question... - Cheers! Matroc (talk) 03:09, 21 September 2014 (UTC)

Legend on left hand side of maps no longer visible?[edit]

Swept in from the pub

The bar and legend on left hand side of maps appear to no longer show up. Only the zoom level appears on that side. Anyone else notice this or is it just me? - Matroc (talk) 21:43, 16 September 2014 (UTC)

Apparently this was corrected - Thanks! - Matroc (talk) 04:28, 17 September 2014 (UTC)

Map Coordinates[edit]

Swept in from the pub

For some reason, if longitude and latitude are entered as anything above a simple decimal - you wind up with a pile of extra characters at the beginning of the listing. Is there some way around this? It will parse if you decimalize the entire thing, but the map it links to will not parse it at all. What do I do? L. Challenger (talk) 03:32, 5 October 2014 (UTC)

Coordinates are entered as strict decimal values not minutes and seconds. The number after the decimal point is not minutes and seconds but the decimal fraction of a whole degree. You will need to convert the number or use a tool that give the value just in degrees. --Traveler100 (talk) 05:56, 5 October 2014 (UTC)
You can use this conversion tool: http://www.fcc.gov/mb/audio/bickel/DDDMMSS-decimal.html --Andrewssi2 (talk) 08:34, 6 October 2014 (UTC)
Or go to the Wikipedia article for the place (usually our article will have link in the sidebar) and click on the co-ordinates shown on the upper right. That gets you to a page where second line is, e.g. for Xiamen, "24.479836, 118.089419". Copy that into your geo tag, changing the comma to "|". Pashley (talk) 13:12, 6 October 2014 (UTC)
Not a great example, unfortunately, since those coordinates (even the DMS coords on the Wikipedia article) are far too precise. Powers (talk) 20:33, 6 October 2014 (UTC)
I use this tool: www.geoplaner.com. Try it, maybe you like it. --Bernello (talk) 20:47, 8 October 2014 (UTC)
But what if an average user wants to modify the "price=" in a sleep listing and sees the empty "lat=" and "long=". In "Google Earth" he had already stored a marker to his hotel, so he copies the lat and long data in degrees, minutes, seconds format from Google Earth to wikivoyage, and sees the unexpected result. How does he know what he did do wrong? I think it is not correct how this is handled by the template. --FredTC (talk) 10:56, 9 October 2014 (UTC)
It'd be nice if the template would recognize the format automatically. This may mean some tricky coding, but it is already done at Wikipedia (format deduced from number of parameters). The conversion is quite easy, even by hand (or by pasting into a calculator), but still unnecessarily cumbersome – especially while on the road. Any thing non-numeric should give a clear warning. --LPfi (talk) 13:40, 9 October 2014 (UTC)

Coordinates all messed up[edit]

Swept in from the pub

uuu, i need some help. In the article Esino Lario all the coordinates appear messed up. I must have done something wrong but if i review the history i can not identify when, since it all appears already with the mistake. --Iopensa (talk) 11:52, 31 October 2014 (UTC)

You have not done anything wrong, known problem with the geo data, bug has been logged. BTW, impressive amount of data added in short time to the article, nice job. --Traveler100 (talk) 12:05, 31 October 2014 (UTC)
The simplest way to solve this problem is to remove the #iferror statement. If there is really an error you will find the page in a maintenance category defined in MediaWiki:Geodata-broken-tags-category and you can check it. --RolandUnger (talk) 12:40, 31 October 2014 (UTC)
Thank you all! --Iopensa (talk) 13:05, 31 October 2014 (UTC)
For the records, messed up coordinates when search has problems should not happen anymore: according to bugzilla:72559 GeoData will not be disabled completely anymore if CirrusSearch is having problems. --AKlapper (WMF) (talk) 09:22, 3 November 2014 (UTC)

Map thumbnails not showing properly[edit]

Swept in from the pub

When I click the link that says "View full-screen map for X," I do see a full-screen map of X. However, I see only numbers and plus signs on the thumbnail in the article, nothing more. Are other people having the same problem? Ikan Kekek (talk) 05:23, 1 December 2014 (UTC)

yes since yesterday. --Traveler100 (talk) 05:42, 1 December 2014 (UTC)
Oh, that's too bad. Ikan Kekek (talk) 05:51, 1 December 2014 (UTC)
I can't see the map embedded on the article page, just the numbers and plus signs as you described. Is this the same issue? --Andrewssi2 (talk) 07:36, 1 December 2014 (UTC)
I don't know what "tiles.wmflabs.org" is, but that's hanging on my browser when the map loads and apparently preventing the map background from displaying. -- Ryan • (talk) • 07:50, 1 December 2014 (UTC)
OSM-Mapnik tiles are loaded from the WMF-Labs-Server. This server is faulty at the time. Wikipedia also has no access. The PoiMap2 scripts were not changed. -- Mey2008 (talk) 19:28, 1 December 2014 (UTC)
I would add that we are obliged to use the unsteady tiles.wmflabs.org server because of privacy issues. There is no solution on our side. --Alexander (talk) 21:20, 1 December 2014 (UTC)

Consulates on maps?[edit]

Swept in from the pub

Do we want to put markers for consulates on maps?

While it might be informative in some cases, it could also be seen as too much not-so-useful markers. For instance, Karachi has 110 consulates.

My personal opinion is that we should have a special type of listing called "consulate", and not display it on dynamic/static maps.

A separate map just for consulates might also be an option.

What do you think? Nicolas1981 (talk) 05:09, 3 December 2014 (UTC)

One or two would be fine on the main map but 110 would be very annoying. A separate map would be a good idea, maybe in the case of locations with more than 100 a sub-page which would then have its own map. --Traveler100 (talk) 05:21, 3 December 2014 (UTC)
I think travellers looking for a consulate are looking just for one of them and only when wanting to go there. A map with all consulates is not necessary if you can get one with just the one you are interested in. I think this works with editing previews (just click the number, even if it does not yet show on the general map). Can it be made to work also generally? Otherwise a subpage is probably a good solution. For printed guides this is a bit clumsy. I would prefer to have my consulate on the general map. --LPfi (talk) 12:43, 3 December 2014 (UTC)
You don't need a special listing type, just the standard 'List' template. Top level articles for large cities won't generally have dynamic maps however.
I think a dedicated static map for consulates/embassies sections may be feasible. It would take more work than I'd be prepared to do though. --Andrewssi2 (talk) 10:36, 4 December 2014 (UTC)
Many capitals of minor countries, or secondary cities of major countries, have consulates and don't have sub-articles.
LPfi's idea is interesting, showing "my consulate" would require to enter my nationality(ies) into Wikivoyage, though. And actually when I travel I sometimes visit the consulate of the neighbouring country, to get a visa.
I think the ideal would be to not show them on maps, but still have the latitude/longitude in the listing, so that when clicked they show the clicked consulate. That would require some development though. That would not be visible on paper. Nicolas1981 (talk) 12:57, 5 December 2014 (UTC)
It's unlikely that a capital of a minor country would receive a consulate. Usually, a capital of a Commonwealth dominion rates a High Commission from fellow members of the great Britannic Empire, while any other foreign capital gets an embassy. A country normally establishes both embassy and consulate in the same foreign capital only if their diplomatic presence doesn't quite fit into one building, causing visa issuance, trade promotion or other consular activities to be split from the main embassy. K7L (talk) 19:35, 5 December 2014 (UTC)
I'm not sure what is being proposed. Is it just for articles that have no sub-articles? That would be a messy approach.
Also anyone needing a consulate/embassy is possibly in an emergency of some sort and should refer to the web site of their country's foreign department rather than WV. Embassies and consulates move and close all the time and the lists that we have in WV are probably not accurate. We should still list them, but not tightly integrate them into the WV experience.--Andrewssi2 (talk) 09:44, 6 December 2014 (UTC)
I think WV will be used more and more offline. A traveler in an emergency might have nothing but WV on paper, Kiwix, or saved webpages, although I would use an OpenStreetMap client. But I think a more general filtering option would be great. For example to produce maps and paper copies without hotels (if I already booked my hotels), only midrange restaurant (if that is what I can afford), only embassies and consulates for certain countries (between my wife and I we have a few options), etc. Elgaard (talk) 00:03, 8 December 2014 (UTC)
K7L: I said "consulates" but I meant "consulates+embassies", sorry for being unclear. So, yes, many city articles have no sub-pages and have a list of consulates/embassies. Karachi and Quito are a good examples. Nicolas1981 (talk) 05:23, 8 December 2014 (UTC)
Andrewssi2: I beg to differ: We should provide travellers with an up-to-date and convenient way to find their embassy/consulate or the embassy/consulate of the next countries in their trip. It is a common use case of a travel guide. Printed guides are not ashamed of listing them, even though they become out-of-date faster than us. Nicolas1981 (talk) 05:23, 8 December 2014 (UTC)
I have found the official databases for all embassies in Washington, D.C., and all US/Canada/Australia embassies around the world, so expect to have at least those up-to-date as soon as I write a script :-) Now if we could find such data for all countries other that would be great... Nicolas1981 (talk) 09:16, 8 December 2014 (UTC)
I did not say we shouldn't list embassies. I said "We should still list them, but not tightly integrate them into the WV experience". I still hold that position.
Even if you can find quality data for all embassies of all countries around the world (which I doubt), you still need to explain how it would be presented? London has something in the order of 150 listings for embassies, which is impractical for one map. Andrewssi2 (talk) 11:11, 8 December 2014 (UTC)
It's not only impractical, it's guaranteed to be 99% clutter: for any given traveller there is pretty much a predetermined absolute maximum of exactly two useful listings of this type, with only one in the vast majority of cases. This would automatically mean, in the above case, that 149 map icons would be no more than utterly useless clutter making the map hard to read. I don't know if it would be practical, but Nicolas1981 had the right idea above, about making it so you can see it on a map only if you click on it, etc. But showing them all on the maps is out of the question; in many cases they'd practically outnumber and obfuscate the Eat/Drink/Sleep listings, placing very disproportionate emphasis on a whole class of listings all but one or two of which could serve no possible purpose for a given individual traveler. Texugo (talk) 21:20, 8 December 2014 (UTC)
We could work on the layer system of the map control in order that the user has to specifically request to display the embassies, although 150 embassy dots on the map won't be that much help.
I also still need to understand how these listings would work on cities with sub articles. Would it require an additional dynamic map at the top level? What if an accepted static map already exists? Andrewssi2 (talk) 22:53, 8 December 2014 (UTC)
Andrewssi2's idea is ideal, a layers control would mean that only people who want to see consulates see them. Roma probably has nearly as many consulates as London, and a map of them is very readable: http://overpass-turbo.eu/?template=key-value&key=amenity&value=embassy (unzoom a bit and press "Run") That example map would be very usable if it had numbers. Consulates tend to be rather large buildings in the city center, which means that overlap is rather rare. Anyway, for now, how about we 1) Create a new listing type called "consulate", or any better word that encompasses embassies too 2) Filter out them so that they DON'T appear on dynamic maps. Cheers!Nicolas1981 (talk) 08:43, 9 December 2014 (UTC)
Interesting challenge... a name meaning both consulate and embassy. I wonder if consular_section would work? Typically when a traveller visits an embassy, they are not going to the office of the ambassador for diplomatic business (unless they are Julien Assange) but rather visit the Consular Section which is contained within the embassy and deals with things such as visas. Probably confusing to most people though. --Andrewssi2 (talk) 10:57, 9 December 2014 (UTC)
The experts have spoken: legation is a word that apparently encompasses embassies, consulates and similar. I suggest implementing this new listing type if there is no opposition? It will make dynamic maps lighter, as many have them shown as unclassified listings. The appropriate template will need to be created. I guess the listing editor would need to be updated, even though it is not urgent. Nicolas1981 (talk) 12:49, 10 December 2014 (UTC)
I've seen "delegation" used for a fair amount of w:paradiplomacy (such as Ontario's former 'embassy' to Québec, which used to sit just outside the walled city) so I suppose that makes sense. K7L (talk) 17:34, 10 December 2014 (UTC)
Sorry to disagree with the experts at StackExchange :) In earlier times 'Legation' referred to any diplomatic office other than a country's embassy, however in any case it is no longer used. I'm not sure about the term Delegation as well, just because it is not widely used in this context. --Andrewssi2 (talk) 20:20, 10 December 2014 (UTC)
How about "representation"? I will only appear in the listing's wikicode and as an icon in the listing editor I guess. Nicolas1981 (talk) 15:58, 12 December 2014 (UTC)
'Representation' could work.
I was also thinking that a specialized template could also optionally include other nations that an embassy may represent. For Example the Swedish Embassy in North Korea represents the United States, or the Embassy of an EU country should also offer consular services to any other EU country as well. --Andrewssi2 (talk) 18:45, 12 December 2014 (UTC)

Restaurant name showing wrongly in hover message[edit]

Swept in from the pub

I recently added the restaurant 2h+k (yes, the name includes a plus sign) to the Tampere page. Yet, when I hover over the location on the map, the message says "2h k". What did I do wrong? JIP (talk) 17:13, 3 January 2015 (UTC)

I've noticed the same problem. It seems the hover message isn't configured to display certain characters. -- AndreCarrotflower (talk) 17:23, 3 January 2015 (UTC)
The '+' symbol is used when passing parameters to a page through the URL; it represents a space (since space characters can't be used in URLs). When the parameter is encoded for placing in the URL, spaces are converted to '+' characters, so any '+' characters will get converted back to spaces upon decoding.
The likely cause of this bug is that text like listing names isn't being properly URLencoded before being passed as parameters. Unfortunately, I know only enough to identify the problem, not enough to fix it.
-- Powers (talk) 22:15, 3 January 2015 (UTC)
The script poimap2.php for the dynamic map is wrong here. I will try to fix it in the next version. -- Joachim Mey2008 (talk) 17:34, 4 January 2015 (UTC)
A plus sign is also possible in name fields now. 1 Hotel Chip + Dale, 77 Chipmunk St.. -- Joachim Mey2008 (talk) 13:42, 8 January 2015 (UTC)

Static dynamic maps[edit]

Swept in from the pub

I have started writing a new script to make dynamic maps suck a bit less on paper/offline/NoScript:

  • Create a screenshot of the dynamic map
  • Upload it to Wikimedia Commons
  • Add it as the "staticmap=" parameter of the Mapframe

Proof of concept at Tokyo/Roppongi, it looks great on Kiwix (offline Wikivoyage reader). Some issues to solve:

  • I need a name for this script, and "static dynamic maps" is not great, clever suggestions appreciated :-)
  • Is it OK to store all of these images on Commons?
  • We will need to update each file when POIs are modified, not sure what is the best strategy here. I am thinking of regenerating every time the article is edited, then comparing with the previous image and uploading only if it has changed. Generation will not be cheap, taking about 30 seconds of computer time.

Cheers! Nicolas1981 (talk) 16:12, 22 January 2015 (UTC)

If we could figure out some way to generate a map legend to replace the functionality of clicking on a dynamic map's POIs, that would be good too. -- AndreCarrotflower (talk) 16:30, 22 January 2015 (UTC)
"Every time the article is edited" is probably too much, since people will make multiple edits in the space of a few minutes. Maybe we should limit it to once an hour or once a day? WhatamIdoing (talk) 16:33, 22 January 2015 (UTC)
Would it not be possible to analyse the changes made in the edit and generate the map for comparison only when POIs are modified in ways the script used cannot see are irrelevant? Relevant changes would be removal or addition of POIs, change in coordinates or change in listing type. Something else? When moving the POIs the script would probably not be smart enough to see nothing was changed but in trivial cases. Even with a quite simple script we could avoid map generation when the edit e.g. affects only running text. Waiting while somebody is doing extensive changes would of course be good to (as with the suggested timer or more cleverly). --LPfi (talk) 16:42, 22 January 2015 (UTC)

Many of the articles may need more than one static map, for example maps of different parts of the city taken at different zoom levels. Therefore, I strongly suggest that the script should work not with MapFrame directly, but with another (e.g., MapPrint) template, where maps relevant to the print/offline version could be specified. Even the Tokyo example shows that at a lower zoom level some of the POIs overlap, while at higher zoom levels some of the POIs are outside the map. We will typically need at least two maps (whole city + city center) as most printed travel guides do.

Storing images on Commons should be fine, but they have to be placed in proper categories based on the information taken from Wikidata. Regarding the updates, I think that one could start with the script running daily for every article edited during that day, but its scope should be restricted to usable articles and above. When we are sure that this thing works reasonably well, one could try to devise a better algorithm of finding which edits are substantial and which are not. Then thousands of outline articles could be included as well. --Alexander (talk) 17:41, 22 January 2015 (UTC) --Alexander (talk) 17:41, 22 January 2015 (UTC)

How does this script handle overlapping icons? Powers (talk) 18:13, 22 January 2015 (UTC)
The current script does not handle that. If I can find a way to know whether there is overlap or not, I could easily generate other images at higher zoom levels, but not sure where to put these images so that they appear in print but not to Web users. Any idea how to solve this, or reduce overlay? Nicolas1981 (talk) 04:04, 23 January 2015 (UTC)
It's not only about the overlay, but about choosing zoom level and area that are most suited for a printed map. Creating a template that adds a static map to the print version but not on the web is trivial, isn't it? The printonly CSS class can be used. --Alexander (talk) 07:41, 23 January 2015 (UTC)
Another question. What happens when such a static map is created and then the article subsequently receives many new/updated listings? Most editors won't notice the existence of this 'out of date' static map (since the picture will be similar) but end users will be impacted. Andrewssi2 (talk) 20:43, 22 January 2015 (UTC)
The "staticmap=" parameter of the Mapframes are often out-of-date. One of the goals of the present script is to fix this problem, by re-generating the image when needed. Nicolas1981 (talk) 04:04, 23 January 2015 (UTC)

For the script name, I can't decide between "PepeFreez" and "DoraStone". Nicolas1981 (talk) 04:37, 23 January 2015 (UTC)

For now this script takes screenshots of the right size and saves them on the local disk. I will be travelling soon, so if someone wants to take the lead or get involved in this project now is a great time :-) The next steps would be to get the list of target articles, write the code that uploads to Commons, and write the code that inserts the "staticmap=" attributes. Cheers! Nicolas1981 (talk) 12:55, 23 January 2015 (UTC)

Dynamic map server down[edit]

Swept in from the pub

The dynamic maps server has been down for half a day now. Can someone look into this? -- AndreCarrotflower (talk) 05:20, 28 January 2015 (UTC)

@Mey2008: --ϒpsilon (talk) 05:25, 28 January 2015 (UTC)

The map tool stopped around 1am. I restarted it by hand and it works now. Not sure what the problem was... --Alexander (talk) 09:11, 28 January 2015 (UTC)

Does the image set as "staticmap=" in the Mapframe get displayed in such circumstances? That would minimize impact a lot. A example article is Tokyo/Roppongi. Cheers! Nicolas1981 (talk) 10:23, 28 January 2015 (UTC)

Question about map markers[edit]

Swept in from the pub

Someone recently changed the entry for Nakukymppi in the Padasjoki article from "do" to "event", and somehow that seems to have caused the marker for it to disappear from the map. Clicking the entry's marker in the listing still zooms in to the correct place on the large map, but even that doesn't actually show the marker. Is this a bug or by design, seeing as the event is still over three months in the future? JIP (talk) 18:05, 20 February 2015 (UTC)

Probably discovered a limitation on template. Is still at status experimental and probably needs to be added to the map marker algorithm. --Traveler100 (talk) 19:13, 20 February 2015 (UTC)
For proper automatic numbering is missing "type=do" in the template:event. Or "{{event | type = do | .... }}" must be entered in the source article text. But I'm not an expert on templates. The numbering for the dynamic map I will adjust later. -- Joachim Mey2008 (talk) 06:27, 22 February 2015 (UTC)

Dynamic maps everywhere[edit]

Swept in from the pub

Right now when I browse WV, I always need to have another tab with Google maps open. I often find myself on a page with no clue where it is (other than its country). Its difficult to visualize where things are with just static image maps. Dynamic maps are just much more usable, especially when trying to quickly visualize the sub-regions, some of the 'go next' pages mentioned, or jumping from things on the map to other WV articles.

I think a long term project of WV should be to replace static maps with dynamic maps. If we can then overlay on top of this things like directions and all the WV listings, it would make WV and all its listings so much more usable.

Any thoughts? Magedq (talk) 00:26, 26 February 2015 (UTC)

You might want to have a look at WV:Dynamic maps Expedition, particularly the "Current stage: PoiMap2 broader deployment" section, which may address the points you've raised. -- Ryan • (talk) • 00:36, 26 February 2015 (UTC)
As long as they are reasonably up-to-date, static maps should not be removed. Feel free to add dynamic maps to articles that you feel would benefit from one :-) Having both a static map and a dynamic map is good I think, it is even better than having only a dynamic map, as they can focus on different scale/areas, for instance a static map for the historic center and a dynamic map for the whole city, including landmarks in the suburbs. Automatically inserting dynamic maps in all articles is an option, and actually it is what the French Wikivoyage has done last year (although they put it in their infobox, while we don't use infoboxes here). For each article with no dynamic map we could generate one and put it in the Get Around section, the map would be useful as it shows the destination's streets layout, even in cases where no POIs have coordinates. Let's wait for everyone's opinion about this :-) Nicolas1981 (talk) 02:10, 26 February 2015 (UTC)
I believe in substituting dynamic maps for static ones when the dynamic map is obviously more easily readable only. Ikan Kekek (talk) 03:35, 26 February 2015 (UTC)
I don't think it should be out of question to replace static maps with dynamic ones once they become outdated to a certain degree. On the contrary, I would regard that as an inevitable concession to the reality that our community simply doesn't have enough members experienced with static mapmaking to handle the level of upkeep required by all the Wikivoyage articles that have them. -- AndreCarrotflower (talk) 04:17, 26 February 2015 (UTC)
I also believe a move towards the acceptance of Dynamic Maps is the pragmatic way forward for this site to engage a broader set of contributors. At the same time I do understand the position of those Static Map people who have put in a lot of effort crafting those static maps and would feel slighted if those same maps are dumped as soon as they become ever so slightly outdated. Andrewssi2 (talk) 04:20, 26 February 2015 (UTC)
I think there's a clear difference between a sightly outdated static map and a hopelessly outdated one, and the threshold a static map has to cross before it's justifiable to start talking about replacing it with a dynamic map is certainly debatable. But as to your point about the hard work of static mapmakers, to cater to whose who cry foul about their maps being replaced would run afoul of a fundamental wiki principle regarding ownership of articles. The good of the project has to come first - and in the long run, like it or not, static maps are dinosaurs. -- AndreCarrotflower (talk) 04:28, 26 February 2015 (UTC)
As long as User:Saqib is here and willing to continue with his great map-making, static maps will continue to exist. He can update them, too. Ikan Kekek (talk) 04:30, 26 February 2015 (UTC)
Is he alone up to the task of ensuring that all the static maps on Wikivoyage are kept up to date, though? -- AndreCarrotflower (talk) 04:32, 26 February 2015 (UTC)
I don't know. How many of them are there? Ikan Kekek (talk) 04:40, 26 February 2015 (UTC)
Do you mean city/district static maps or region static maps? I imagine there are a few hundred region maps (every country, plus many states and provinces), probably fewer city/district maps. I still draw static region maps and can fix them up if someone points them out. City/district maps, on the other hand, I usually leave to dynamic maps since I feel they're almost always a better option. -Shaundd (talk) 05:25, 26 February 2015 (UTC)
Also User:LtPowers makes static maps. Even I do it to some extent, but like Shaundd I always use dynamic maps for pointing out attractions in cities and city districts but static maps for regions and city districtification. ϒpsilon (talk) 05:37, 26 February 2015 (UTC)
(This has been discussed already before.) Anyways for the record, I'm in strong favour of static maps for regions and big cities (districtification). I know still there're plenty of regions/big cities articles out there without a static map, but it is because either the article is very outline so there's really no need of a map or lack of sources (boundries issues) from which a map can be traced. For instance, Athens missing a districtification map because I couldn't able to find a source from which I can trace the map. For cities/districts, offcourse dynamic maps are better as of now giving that we have lack of map making team. In-fact, Karachi using a dynamic map. With that being said, I'm always available to help out with maps if I get request. --Saqib (talk) 09:28, 26 February 2015 (UTC)

(reindent) Yes, I probably should have specified that everything I have said above pertains to bottom-level destinations only. Country, region, Huge City, etc. maps are obviously a whole other kettle of fish. Static maps are ideal in those circumstances because what the map depicts is itself a lot more static - a country officially changing its borders, or the Wikivoyage community deciding on a new regions scheme, is obviously a much rarer occurrence than a business closing its doors or a new listing being added to a city article.

Still, as it pertains to bottom-level articles, I stand by what I said above about static maps: obviously at this point dynamic maps are much more commonplace for districts and non-districtified cities, but there are still some that have static maps, and those that do are crippled to a significant extent by there being a much smaller number of editors capable of updating them. The fact that static maps are disproportionately well-represented among Star articles, supposedly the best work we have on this site, is especially concerning.

-- AndreCarrotflower (talk) 13:06, 26 February 2015 (UTC)

Okay, I would say we should have static maps for star articles atleast, even if they're districts. Star articles should have both (dynamic as well static maps). WHY? There're plenty of reasons. And I'm more happy to update the maps of star level articles and we should create a project page somewhere to list the star articles that need map update. I'm happy to work on them. --Saqib (talk) 13:28, 26 February 2015 (UTC)
If there are plenty of reasons, please offer them. I should think a dynamic map would be rather redundant on, say, Walt Disney World/Epcot. So long as our dynamic maps are horribly jumbled collections of plus signs and numbers obscuring street names and POI labels, locked into a north-up orientation, and lacking the flexibility to include things like insets and legends, static maps remain essential.
I once again have to strenuously object to the completely unfair characterization of maps as things that only "a much smaller number of editors" are "capable of updating". Our map paradigm was designed under the principle that anyone can edit them, just like our articles are. Just like nearly everyone is capable of updating articles, nearly anyone should be capable of updating maps.
To address the original point of the thread, I would point out that we can never hope to duplicate the functionality of Google Maps. We shouldn't even try. What we could do, if it would be useful, is place a "vicinity" map in the Go Next section that shows the relationship of the destination to nearby destinations mentioned in that section.
-- Powers (talk) 01:03, 27 February 2015 (UTC)
Replace the words "capable of updating" with "interested in learning how to update" and/or "interested in putting forth the effort to update when the same thing can be done on a dynamic map in a fraction of the time", and the essence of what I said remains the same. No matter how much effort we go to in scolding people for not being interested in learning the ways of static maps, the fact remains that our community is made up of volunteers who are under no obligation to do or learn anything - and there aren't very many of us to begin with. Given that, some concessions to reality are in order. -- AndreCarrotflower (talk) 01:15, 27 February 2015 (UTC)
With respect to the point about a "vicinity map", the dynamic maps already do that - click on the third icon ("POIs <-> destinations") and you'll get a map that shows all articles in the immediate area, and you can click on any marker to view that article. -- Ryan • (talk) • 01:37, 27 February 2015 (UTC)
This should definitely be more prominent! Have been looking for something like this for a while Magedq (talk) 04:19, 27 February 2015 (UTC)
I tested this out. When I click that icon, all I see are a mass of unlabeled blue markers. I can hover over some of them to see what city they refer to, but that's tedious. And others are so close together that they do not show up as individual markers. A hand-crafted map would be much more readable and usable. Powers (talk) 16:43, 28 February 2015 (UTC)
The zoom / scroll functions and the direct jump to each neighboring article, you forgot to mention. - How can you do something like this with static maps? -- Joachim Mey2008 (talk) 19:11, 28 February 2015 (UTC)
While dynamic maps are obviously a sore subject for a few people, for the vast majority of users the dynamic maps seem to be a highlight of the move to Wikivoyage. Mey2008, I don't think you and the others who maintain this functionality get thanked nearly enough, so many, many thanks for the work you do on this feature - today we have over 1500 articles with maps that would likely not otherwise have them, which is a massive usability win for our site. -- Ryan • (talk) • 19:30, 28 February 2015 (UTC)
Direct jumps can be implemented with imagemaps, if deemed necessary -- but keep in mind that the text list would appear in the article right next to the map. I'm afraid I don't see how zooming and scrolling serve to solve the problems I pointed out. A well-designed static map can tell the user at a glance what it would take these dynamic maps several seconds or minutes of scrolling zooming and hovering to find out. Powers (talk) 18:35, 1 March 2015 (UTC)
An imagemap is no alternative. First you need to check all neighboring destinations whether an article already exists. A monotonous and tedious task. Then you have to manually detect hundreds of pixel coordinates and dozens of polygons. This lasts many hours. A single mistake makes the whole map unusable and caused extensive search. - To create a dynamic map is only required {{mapframe|zoom=auto}}. That's all. The only (logical) precondition is that some listings with coordinates should be available. - Try this once on my test page [93] and you will be amazed. -- Joachim Mey2008 (talk) 06:47, 2 March 2015 (UTC)
I didn't say it'd be easy. Much that's worthwhile isn't. But I'm also not convinced that the links are a vital part of this puzzle given the caveats I mentioned above. Powers (talk) 02:37, 3 March 2015 (UTC)

I'd say nearly all articles should have a dynamic map; that just needs geo co-ords added. Just doing the city gives a map, then if there are co-ords in listings, it improves. Co-ords can be added even by someone like me who has approximately the same ability with graphics as the average turnip and is not much interested in learning more. For example, I added a lot to Suzhou and Dumaguete.
Then some should have a static map added. Of course a good static map can be better than the dynamic ones if someone has the time & skill.
I think there are some open problems with dynamic maps. One is that many people do not set zoom= when they insert co-ords; this can give a map of an island or region that shows far less than the whole thing, or a city map that shows only the center. Another problem, I think, is that the map icon, off in a corner of the screen, may not be noticed by readers; I'd like to replace it with MAP. Pashley (talk) 01:53, 27 February 2015 (UTC)
Agreed about noticibility. I consider myself a regular user, and always wanted there to be maps, but never knew that button existed. I'd say that the map should even be displayed by default, with a button to expand to full screen. Magedq (talk) 04:19, 27 February 2015 (UTC)
I agree that the map icon is not noticable. Even when I have told friends about a page here and that there is a map, unless I point at the icon on their screen new users don't recognise it. Changing it to "MAP" and / or adding it to the left menu would be good. AlasdairW (talk) 15:33, 27 February 2015 (UTC)

About maps[edit]

The Amana Colonies are on the northeastern edge of Iowa County in Iowa.
The Amana Colonies are in east central Iowa.
Major highways near the Amana Colonies in Iowa

Magedq, I'm curious about the kind of information that would be really useful to you. So I'd like to offer an example, and see what you (or anyone else) think. I've been working on Amana Colonies. It's a collection of historically important villages in the US. I added a dynamic map that's been set to show each village. Would one of these two maps be helpful to you? (I was thinking that it could be placed in the ==Get in== section.) Or do you want something more detailed, e.g., with highways and cities marked? WhatamIdoing (talk) 04:56, 1 March 2015 (UTC)

For me browsing this page, the US map is the most useful because I have no clue where Iowa is, so I want to be able to place villages on a map I know. But I definitely am not the normal/expected(?) user for this page. Would it be someone who regularly drives through the area? Then maybe one with roads/highways would be most useful. This is why dynamic maps make so much more sense to me, especially if it can be simple to jump between layers and get to the info that you're specifically looking for. Magedq (talk) 05:13, 1 March 2015 (UTC)
You definitely should not give a map of the entire US, showing where the entire state of Iowa is, in an article about the Amana Colonies. I think the locator map, showing the whole county, is modestly useful, but I wouldn't include that, either. What's really needed is a road map, showing how to get there. So I ultimately agree with Magedq about a dynamic map for the larger area, in addition to maps of each village — unless you'd prefer to make a clear static map, showing the placement of the different villages and roads between them. Ikan Kekek (talk) 05:59, 1 March 2015 (UTC)
I've added a third option: the state of Iowa, with the major highways marked (US 6 in red, all the interstates in blue). I'm thinking that you would need to add a dot that shows the location of the Amana Colonies. (It's a little west of where the red line and one of the blue lines intersect in the right side of the map.) Also, the highways ought to be labeled, if you want to use them as driving directions. I'm not sure how helpful this would be to someone who doesn't know where Iowa is, though. Even if you've narrowed it down to "one of the square states in the middle", that leaves a lot of room for error. WhatamIdoing (talk) 19:59, 2 March 2015 (UTC)
I don't like it because I really don't get any useful information from it. But the main point that I'd like to make is that this site operates on breadcrumbs, so if someone doesn't know where Iowa is, they can go up the breadcrumb trail to look at the Iowa article, and if that doesn't help, the regional article for the Midwest or the USA article. We don't need to and shouldn't show a map of the entire country, the entire state and the entire county in every city article. Ikan Kekek (talk) 20:18, 2 March 2015 (UTC)
I would find a good locator map useful, but I think that they probably take far too much work to create. It would be better to spend the time creating a static map for Eastern Iowa. The location of Amana Colonies can probably be covered effectively with a sentence: "The Amana Colonies are about 25 miles northwest of Iowa City, 20 miles southwest of Cedar Rapids, 100 miles East of Des Moines and 250 miles west of Chicago." This should let readers have a reasonable idea of where the place is, Get in can then provide the details of road numbers, bus times etc. AlasdairW (talk) 12:21, 7 March 2015 (UTC)

Availability map server[edit]

Swept in from the pub

The availability of the map server is bad. Wikipedia uses the same server and it's the same problems. - I get every 15 minutes an email when errors occur (www.my-cronjob.de). Here are the messages today:

times status
27.02.2015, 07:04 not ok (500)
27.02.2015, 06:47 not ok (500)
27.02.2015, 06:33 not ok (500)
27.02.2015, 06:15 ok (200)

However, I do not have access rights to the wmflabs server. Maybe an admin is interested in such messages to help out? - Joachim Mey2008 (talk) 07:07, 27 February 2015 (UTC)

Labs is having problems recently: https://lists.wikimedia.org/pipermail/labs-l/2015-February/003429.html Nicolas1981 (talk) 08:51, 27 February 2015 (UTC)
  • We have indeed; sorry for the inconvenience. Over the past two weeks we suffered a hardware failure followed by a mysterious failure of the host where the virtual machines were moved to. All told, parts of labs had some six hours of outage over the past couple of weeks. We're hard at work increasing our redundancy. MPelletier (WMF) (talk) 21:19, 1 March 2015 (UTC)
Map Server is evidently down again. Matroc (talk) 03:23, 31 March 2015 (UTC)
It should be better now. A long-planned improvement (to improve stability and availability, ironically) had some temporary problems. WhatamIdoing (talk) 06:12, 1 April 2015 (UTC)

Maps on Firefox[edit]

Swept in from the pub

For about 24 hours when I view a map from a Wikivoyage page I do not get any of the controls such as zoom or POI type or map style. This only appears to be a problem on Firefox. Is this a problem just with my settings or are others seeing this too? --Traveler100 (talk) 06:50, 20 March 2015 (UTC)

Yes this happens to me a lot when I use Firefox, but it's OK with Chrome. Antiv31 (talk) 09:04, 20 March 2015 (UTC)
Please close all WV tabs / windows. Important! Then clear the browser cache. Data structure has changed in the last version. -- Joachim Mey2008 (talk) 10:14, 20 March 2015 (UTC)
That fixed it, thanks. --Traveler100 (talk) 11:06, 20 March 2015 (UTC)
Worked for me too. Antiv31 (talk) 01:43, 21 March 2015 (UTC)

Create an exhibition city map[edit]

I want to create a dynamics map on an exhibition page for all cities created in WV for South Korea.

For listings, can I automatically get a list of names, article status and geo-locations for all articles under the South Korea category?

For extra bonus, can I then change the pinpoint icon color depending on article status? (i.e. outline, guide, etc) --Andrewssi2 (talk) 23:03, 28 March 2015 (UTC)

Map of Dynamic maps Expedition
The WV map provides only this representation. The markers are clickable and linked with the WV articles. But the article status is not evaluated. - Joachim Mey2008 (talk) 12:44, 29 March 2015 (UTC)
Thanks Joachim ! --Andrewssi2 (talk) 23:51, 29 March 2015 (UTC)

Dynamic maps not showing[edit]

Swept in from the pub

I get this error with any dynamic map:

No webservice
The URI you have requested, /wikivoyage/w/poimap2.php?lat=35.6457&lon=139.7729&zoom=12&layer=M&lang=en&name=Tokyo_2020, 
is not currently serviced.

Is someone working on it at the moment? Cheers! Nicolas1981 (talk) 07:44, 31 March 2015 (UTC)

Only administrators @Zhuyifei1999:, @Torty3:, and @Atsirlin: can restart the service. Programs were not changed, and run the same version without any error on the WV.eV-server[94]. - Joachim Mey2008 (talk) 08:06, 31 March 2015 (UTC)
I can't even log in to tools.wmflabs.org at the moment, so we can't do anything. Please, ask WMF why the tools server is so unreliable. --Alexander (talk) 08:15, 31 March 2015 (UTC)
I temporarily changed the server address to WV-eV-server. Full Screen maps are functional again. -- Joachim Mey2008 (talk) 08:38, 31 March 2015 (UTC)
Yes Done Restarted --Zhuyifei1999 (talk) 08:53, 31 March 2015 (UTC)
I think that this is related to w:en:Wikipedia:Village pump (technical)#Labs is going to be slow. That team is aiming for 99.5% uptime, and they still have a chance at it (for the year, but probably not for the quarter that ended a few hours ago). WhatamIdoing (talk) 06:23, 1 April 2015 (UTC)
wmflabs not responding - Matroc (talk) 04:47, 2 April 2015 (UTC)
Further failure of WMFLabs servers since 2:40 (UTC). Reason: 504 Gateway time-out. Also Wikipedia's dynamic maps are affected. -- Joachim Mey2008 (talk) 05:02, 2 April 2015 (UTC)
Thank you Joachim for the information - Matroc (talk) 05:12, 2 April 2015 (UTC)
It seems that everything is working again. -- Joachim Mey2008 (talk) 05:22, 2 April 2015 (UTC)
Looks like a hardware problem. There were problems two days in a row. See this incident report if you want the gory details. WhatamIdoing (talk) 20:16, 2 April 2015 (UTC)

Stability of map server[edit]

Swept in from the pub

Dynamic maps were not showing again for some time this afternoon. If this is going to continue to be a problem, perhaps we should revisit the question of whether we should be using dynamic maps, instead of static maps, throughout the site. Ikan Kekek (talk) 21:00, 13 April 2015 (UTC)

Or whether we should do something about the stability of the server, or moving to another. I missed most of the discussions on that - what's the status? Meanwhile, everybody willing can start making the missing hundreds of static maps, should be lotsa fun! PrinceGloria (talk) 21:33, 13 April 2015 (UTC)
Yeah, it's not very practical, but at least those relatively few articles with static maps will have visible maps while the dynamic map server is on the fritz. Ikan Kekek (talk) 21:39, 13 April 2015 (UTC)
Sorry if I ask a stupid question, but... What's wrong with dynamic maps? Hobbitschuster (talk) 21:42, 13 April 2015 (UTC)
They're fine if they're visible. When the map server is on the fritz, they can't be viewed at all. Ikan Kekek (talk) 21:46, 13 April 2015 (UTC)
How so? "Nginx error" is a fine, historic city and well worth a visit. K7L (talk) 21:48, 13 April 2015 (UTC)
"Nginx" - awesome city with stylized gardens on the coast, best food just outside of Tokyo - Matroc (talk) 21:52, 13 April 2015 (UTC)

At any rate - what's the status? I don't notice the lack of maps anyway, as to show them I need to manually change the settings of my browser to non-secure every time I need to see the map. Can we do something about it as well? Or at least add a link to instructions how to make your browser see dynamic maps? PrinceGloria (talk) 22:06, 13 April 2015 (UTC) PS. Making hundreds of static maps is not feasible, but there are many maps in the Commons we can link to - better than nothing.

Dynamic Maps are a long standing issue. Although we have some great volunteers who make great efforts, the map server is basically still an experiment and would never be used for a commercial business.
So the problem is... how to move it from the experimental phase? AFAIK there is no other place we could host it.
I actually think a good solution would be to get rid of the map server completely and replace it with a Javascript control that would call OpenStreetMaps directly. This would also have (significant) technical challenges, but it would remove the dependancy on WMF labs... Andrewssi2 (talk) 03:05, 14 April 2015 (UTC)
Has WMF ever been asked for an alternative solution, e.g. hosting on a different server? Whatever holds e.g. the general Wikivoyage stuff seems to act up very rarely. PrinceGloria (talk) 05:00, 14 April 2015 (UTC)
Is does act up rarely.. enough for myself (for example) not to be too bothered. However if we do see significantly increased readership (one of our general aims) then that will have the effect of knocking the map server over more frequently. Andrewssi2 (talk) 05:03, 14 April 2015 (UTC)
PrinceGloria, I don't have to change anything in my browser to see the maps, and most other people don't have to do it either. Which browser do you use? Have you checked that it calls tools.wmflabs.org and not other servers (that are not trusted indeed)? --Alexander (talk) 07:10, 14 April 2015 (UTC)

WMF does not allow us to embed any content from third-party sites (OSM included) because this would mean transferring information about your session elsewhere, which is against the privacy policy. Very stupid, but that's how it is. There is no solution other than using tiles on the WMF server, so the best thing to do is to ask WMF directly why they can't arrange a stable map server. Another solution is not to embed any maps and simply link to the wikivoyage-ev.org server that is fully under control and perfectly stable.

Regarding the server load, no, Wikivoyage hardly makes any significant fraction of it. There are lots of embedded maps in Wikipedia nowadays. They generate a lot of traffic. --Alexander (talk) 07:10, 14 April 2015 (UTC)

Two maps in one article[edit]

Swept in from the pub

I am currently trying to give the article on American Football a better geographic representation. So far I have found the coordinates of all 31 NFL stadiums as well as Wembley and made listings for them, which already appear splendidly in a map.

I wanted to the same for our Canadian friends of the CFL. However, I encountered two problems. First only three of the nine stadiums appear to have coordinates and I don't want to just guess them or use the coordinates of the city they represent instead. The second problem is that I would like (for aesthetic as well as practical reasons) to have a second map that contains the CFL stadiums and only them. How would that be done if it is doable at all? Best wishes. Hobbitschuster (talk) 14:08, 17 May 2015 (UTC)

You can only have one dynamic map visible on a page. It is possible to have a formatted link to other maps, see example on the Rheinburgenweg page. Alternatively create static maps. On the coordinates of stadiums I would think they are listed as articles on English Wikipedia. --Traveler100 (talk) 14:27, 17 May 2015 (UTC)
They are, but only three of them offer the coordinates or at least I couldn't find them in the other six... Hobbitschuster (talk) 14:43, 17 May 2015 (UTC)
Are you looking in the upper right corner above the infobox? I just checked w:TD Place Stadium and w:Tim Hortons Field and they have coordinates there. You can also check on Wikidata (ex: d:Q7008048). Powers (talk) 15:50, 17 May 2015 (UTC)
It's done. Thanks. I would almost think that our article on American football is fast approaching guide territory. However, the coverage of Canada and minor leagues is still insufficient... Hobbitschuster (talk) 16:26, 18 May 2015 (UTC)
Hobbitschuster, Traveler100, to show more than one dynamic map in one single page, MediaWiki:Gadget-MapFrame.js, must be patched like the it:voy one. --Andyrom75 (talk) 13:17, 21 May 2015 (UTC)
I don't know about the technical details, how is this done and what would be (possible) downsides? Hobbitschuster (talk) 22:06, 21 May 2015 (UTC)
Hobbitschuster To allow two maps an admin must patch the above script, and I don't forsee any downside on doing that. --Andyrom75 (talk) 23:01, 23 May 2015 (UTC)

Mapnik broken on tools.wmflabs.org[edit]

Edit: No answer required The problem is explained on this page. Original message: Hello, I am mainly a contributor in French Wikivoyage, and I noticed that "tools.wmflabs.org" does not display Mapnik tiles anymore, but a gray background (example; trying to accessed a tile gives a page "Internal Server Error"). Note that the English Wikivoyage uses the MapQuest Open tiles, which are currently working (not hosted there, though). The problem is that currently the French Wikivoyage uses Mapnik, so I wonder if we should switch to "MapQuest Open" (possibly temporarily) or if there is something planned for repairing Mapnik. Any information?

Also, the strange thing is that the French Wikivoyage uses "tools.wmflabs.org" for the embedded map (in an iframe), but it uses "maps.wikivoyage-ev.org" for the link to the external map (which is currently ok, and also display the points of interest). Maybe it what partially switched from "wikivoyage-ev" to "wmflabs.org" in order to support HTTPS, so I guess that switching to the former is not an option for the embedded map. Cheers - Fabimaru (talk) 18:48, 29 June 2015 (UTC)

NEW APP! Wikivoyage offline on your Android[edit]

Swept in from the pub

Wikivoyage on your phone! Get it from Google Play Store now!

  • 100% offline
  • Works out-of-the-box
  • Whole world, only 918MB including maps/images
  • Click on a POI to open it in your GPS app

Please report any bug. This app has a huge potential: Once the app is rock-solid, it might become a way to attract new editors to Wikivoyage. But first we need your feedback! Currently known issues: 1) Welcome page is broken 2) Articles have no table of contents 3) Large images/maps are off to the left Syced (talk) 06:58, 11 June 2015 (UTC)

Do the dynamic maps also work in offline mode? If so then that would be a nice feature. --Andrewssi2 (talk) 07:07, 11 June 2015 (UTC)
Yeah offline dynamic maps would be awesome, unfortunately the Kiwix engine does not support that yet. At least we should embed a "frozen" version of the dynamic maps. For now, the best is to generate a GPX file for the area using http://maps.wikivoyage-ev.org/w/gpxmap.php?lang=en before leaving home. Syced (talk) 07:57, 11 June 2015 (UTC)
Ah, so basically it just holds static maps (images) if they exist?
Actually given that we have the geo-coordinates of listings, perhaps we can just leverage the mobile Google Apps... --Andrewssi2 (talk) 09:44, 11 June 2015 (UTC)
Clicking on a listing opens your favorite maps app. But showing all listings on a single map requires either implementing a GPX algorithm in Kiwix, or using "frozen" maps. Syced (talk) 06:08, 16 June 2015 (UTC)

Dynamic to static maps within Kiwix[edit]

This problem has been solved by the amazing people at Kiwix per [95]. That means a static version of our dynamic maps will be in the files :-) Travel Doc James (talk · contribs · email) 12:39, 13 June 2015 (UTC)

Reading the bug report, it doesn't say that it will render Dynamic maps into Static maps. It just says that it will use Static maps if the 'staticmap' attribute is used. AFAIK this attribute is not used very much. --Andrewssi2 (talk) 23:40, 13 June 2015 (UTC)
I was emailed by the lead of Kiwix who said he fixed it and the dynamic maps should be there as static in the July edition. Travel Doc James (talk · contribs · email) 10:20, 14 June 2015 (UTC)
If correct then that would be very interesting. The same technique could generate Static maps for our print view as well. --Andrewssi2 (talk) 00:01, 15 June 2015 (UTC)
Andrewssi2 is correct, we have to create/maintain staticmap attributes on our side. Kiwix will include a static map only when there is such a staticmap attribute. I wrote the DoraStone script for this purpose, but unfortunately a bug on my machine prevents me from using it. Anyone willing to become the project leader for that script? Thanks! Syced (talk) 07:30, 15 June 2015 (UTC)
Looking at the underlying code this gives maps in Kiwix {{Mapframe|35.66262|139.73060|zoom=16|height=540|width=520|staticmap=POI-Roppongi.png}} This does not {{Mapframe|49.513611|-115.768611|zoom=12}}
We need a bot to create and add the static maps. Travel Doc James (talk · contribs · email) 19:51, 11 July 2015 (UTC)
This also raises another question for existing static maps which is going to be contentious. Once all the static maps are generated then there will be no way to determine whether the static map was hand crafted or automatically generated with the technique above.
This is problematic because I would assume we would run the bot every month to regenerate all maps from their dynamic counterparts, regardless of whether the original was handcrafted...
It would effectively mean the end of hand crafted static maps. Andrewssi2 (talk) 23:45, 11 July 2015 (UTC)
So, if something like Adirondacks#Towns and villages links both a static and a dynamic map for the same region (dynamic maps don't cope with dividing a region very well), won't any script think the hand-drawn map is just another random image which can safely be ignored, and not part of the {{mapframe}}? K7L (talk) 03:59, 12 July 2015 (UTC)
Yes this would only pertain to "mapframe"
I assume that this one is hand drawn [96]?
We just need a way to stipulate which mapes are hand drawn and which are automatically created and simply give preference to the hand drawn ones.
This could be done by adding a new parameter to mapframe like "staticmapauto" which works like staticmap but only if staticmap is not filled in. That is were we would place the auto generated static map links Travel Doc James (talk · contribs · email) 07:28, 12 July 2015 (UTC)
This discussion seems rather important to be hidden in this sub-discussion. I have raised a new discussion here: Wikivoyage_talk:Dynamic_maps_Expedition#Future_of_static_maps_with_autogeneration.3F Andrewssi2 (talk) 02:26, 13 July 2015 (UTC)


Future of static maps with autogeneration?[edit]

This thread was somewhat hidden on the pub, so I thought I would highlight it here

Basically it suggests that autogenerated static maps will be available at some point in the future, and I asked the question about what implication this has for existing 'hand crafted' static maps?

It was suggested that an additional attribute to the map template called 'staticmapauto' could be added to the map template, thereby instructing the map to regenerate or not. Andrewssi2 (talk) 02:25, 13 July 2015 (UTC)

It'll be cool to get more maps, but I still think there's a place for well-designed static maps, particularly at the region level. A snapshot of the dynamic map of a region is better than no map, but it'll be worse than a good static map in most cases (e.g., no subregions, not all transportation routes will be visible). Having the ability to turn auto generation on or off seems like a good idea although it will be quite manual to configure it for static maps we want to keep. -Shaundd (talk) 05:29, 13 July 2015 (UTC)
BTW - just to be clear, I don't think a dynamic map/mapframe should be replacing the existing colour-coded region maps yet since it can't display subregions. And if we go down the route of auto-generating and someone draws a region static map, I think it should supercede the dynamic map and auto generated map. Apologies if my thoughts are a little all over the place, it's late!. -Shaundd (talk) 05:51, 13 July 2015 (UTC)
I think the suggestion is to ONLY use snapshots of dynamic maps if a handmade static map is NOT available. Travel Doc James (talk · contribs · email) 20:39, 13 July 2015 (UTC)
It's suggested, but I also got the impression Andrewssi2 wanted a wider discussion. Regardless, after re-reading the pub discussion, I'm confused. What actions are being proposed and how is it going to work? -Shaundd (talk) 04:30, 14 July 2015 (UTC)
The current 'status quo' (as far as I understand it) is:
  1. if an article has no static map image, then a dynamic map may be used
  2. if an article has a sufficiently outdated static map image, then a replacement dynamic map may be considered
  3. if an article has a dynamic map, then a static map can be added to the 'staticmap' attribute for printing purposes
This is already rather unclear. On top of this we are proposing extra logic to dictate when 'static maps generated from dynamic maps' can be used.
I don't have an answer to this, I'm simply highlighting a confusing approach to maps generally. Andrewssi2 (talk) 05:56, 14 July 2015 (UTC)

Maps - tools lab is down[edit]

Swept in from the pub
  • see Details here. Thought everyone should know this and hopefully they will not have any difficulty restoring systems etc. -- Matroc (talk) 21:56, 18 June 2015 (UTC)
It was down all day yesterday but thankfully it's now partially back. The Mapnik layer still doesn't load. ϒpsilon (talk) 08:12, 19 June 2015 (UTC)
And once again no maps. ϒpsilon (talk) 14:26, 19 June 2015 (UTC)
I have changed the server address to WV-ev.org. Now the full-screen maps works. -- Joachim Mey2008 (talk) 19:25, 19 June 2015 (UTC)
Thank you Joachim! - Matroc (talk) 20:38, 19 June 2015 (UTC)
Vielen Dank! I'm doing some work on the districts of Seoul and the absence of the map functionality has been really annoying. ϒpsilon (talk) 20:44, 19 June 2015 (UTC)
I have temporarily changed the template mapframe. Please check spelling. - Template will be reset when WMF tiles server is back online. -- Joachim Mey2008 (talk) 04:42, 20 June 2015 (UTC)

Labs are up and working since yesterday morning, but the map tiles remain unavailable. Mey2008, Syced or perhaps someone else, do you have an idea whom to ask? I believe it will not recover by its own. --Alexander (talk) 11:05, 20 June 2015 (UTC)

The tiles server is also running again. I have reset the temporarily modified templates. --- Joachim Mey2008 (talk) 11:25, 22 June 2015 (UTC)
https://tools.wmflabs.org/wikivoyage/w/poimap2.php?lat=43.96&lon=-74.33&zoom=8&layer=OB&lang=en&name=Adirondacks gives me "504 Gateway Time-out nginx/1.4.6 (Ubuntu)" and the {{mapframe}}s are also timing out after a very long delay. K7L (talk) 17:17, 22 June 2015 (UTC)
Seems to be working OK now. Syced (talk) 02:51, 23 June 2015 (UTC)
Unfortunately, still lacks zoom level 17 for the colored Mapnik layer. Some other Mapnik zoom levels have partially gaps. Well, wait and see. -- Joachim Mey2008 (talk) 14:55, 24 June 2015 (UTC)
@Atsirlin try running "php unzip.php" on tool labs in case the map scripts needs an update. (I think you have the access if wikitech:User:Atsirlin is the same user as you.) If that fails, since I don't monitor that tool so often, would you give me a ping? --Zhuyifei1999 (talk) 14:35, 1 July 2015 (UTC)
Zhuyifei1999, I have access, but the problem is not on our side. The Wikivoyage tool runs smoothly, but it fails to get Mapnik tiles from some other repository on tools.wmflabs.org. And I don't even understand where this repository is, and who may be responsible. So annoying... --Alexander (talk) 17:03, 1 July 2015 (UTC)
Checking the page source and Mey's comment below shows tiles.wmflabs.org as the source, but the host is undocumented. Searched "tiles" instead and found wikitech:Nova_Resource:Maps. cURL'ed all the instances and found maps-tiles3 gives the same output as tiles.wmflabs.org. So very likely the admins on wikitech:Nova Resource:Maps are who to find. --Zhuyifei1999 (talk) 03:53, 3 July 2015 (UTC)

I hear that this is resolved, but it's possible that a few files were lost. wikitech:Incident_documentation/20150617-LabsNFSOutage says that they had to restore from week-old backups. (I don't know much about this, but I can help you figure out who to ask if you need more help.) WhatamIdoing (talk) 18:53, 24 June 2015 (UTC)

The Wikivoyage scripts are restored properly. The problem is the map tiles server. This applies to all users, even Wikipedia. It lacks all the tiles to the zoom levels 3, 6, and 17. This only applies the https addresses: e.g. https://tiles.wmflabs.org/osm/17/x/y.png. But even in other zoom levels are missing several tiles. -- Joachim Mey2008 (talk) 05:12, 25 June 2015 (UTC)
WMFLabs provides no more map tiles since June 26. I have therefore provisionally replaced the three layers "Mapnik", "Mapnik b&w" and "Hill shading" by similar external provided layers. -- Joachim Mey2008 (talk) 15:35, 6 July 2015 (UTC)
WMFLabs layers are back again. -- Joachim Mey2008 (talk) 17:56, 16 July 2015 (UTC)

poimap2.php is 404?[edit]

Swept in from the pub

Go to any random page, click the map icon at the upper-right corner and get sent to somewhere like http://maps.wikivoyage-ev.org/w/poimap2.php?lat=49.28133&lon=-123.11987&zoom=15&layer=M&lang=en&name=Vancouver/City_Centre ... which gives a fat HTTP 404 error. I'm seeing this on every page. K7L (talk) 23:03, 26 July 2015 (UTC)

Might have something to do with a new tile server in process? server address is different (not tools.wmflabs.org) = Matroc (talk) 04:00, 27 July 2015 (UTC)
Looks like it is being corrected as my markers are now working correctly. - Matroc (talk) 04:10, 27 July 2015 (UTC)
The server address 'http://maps.wikivoyage-ev.org' has failed due to problems in the files system. I have changed the address back to '//tools.wmflabs.org/wikivoyage'. -- Joachim Mey2008 (talk) 04:11, 27 July 2015 (UTC)

Dynamic maps[edit]

Swept in from the pub

Hey All. We appear to have an issue with the dynamic maps. They call tile from mapquest which means that the user's IP is exposed to a third party which is not allowed per our privacy policy. Thus I have been informed that some layers of the dynamic maps need to be turned off.

Now the good news. WMF is putting together its own tiles which should be available soon. If you are interested in helping they are looking for front end java script developers. [97] Travel Doc James (talk · contribs · email) 04:44, 20 July 2015 (UTC)

This is extremely annoying. At the moment, we do not include any tiles from mapquest automatically. We only call them if the user decides to do so by switching the tiles manually, which is perfectly in line with the privacy policy because the tiles section contains clear information on which tiles are from the WMF-controlled servers, and which are not.
However, the tile server on tools.wmflabs.org is extremely unreliable, and most problems with the dynamic maps are caused by overloads and down-times of this server that is, unfortunately, beyond our control. WMF should establish a reliable and complete tile server before making any complaints or forcing us to switch off certain tiles that we do need for making our travel guides useful. --Alexander (talk) 13:46, 20 July 2015 (UTC)
Previously (ie yesterday) when I went to Cranbrook it automatically pulled tiles from mapquest without me selecting it. Now I need to select mapquest before it will load from their. That seems a reasonable compromise to me User:Atsirlin and hopefully enough for those involved with maintaining privacy. Travel Doc James (talk · contribs · email) 15:48, 21 July 2015 (UTC)
Hi Alexander, could you show me the usual process for enabling tiles from mapquest? Is this an option in {{Mapframe}}? Thanks! Stephen LaPorte (WMF) (talk) 16:56, 22 July 2015 (UTC)
Go to a page with a map, for instance Amsterdam/Binnenstad#Get in. At the upper-right corner of the map, there's an icon with a stack of layers, which brings up a menu. From that menu, various tiles can be manually chosen by the user. K7L (talk) 17:05, 22 July 2015 (UTC)
Thanks! Stephen LaPorte (WMF) (talk) 17:53, 22 July 2015 (UTC)
@Atsirlin:, I agree 100% - this is very annoying indeed, and I hope the new OSM-based tile server, hosted in WMF production cluster, will be available within a few weeks - Max and I are working on it every day. --Yurik (talk) 23:17, 22 July 2015 (UTC)
On a side note, apparently this issue has been discussed on meta before. --Yurik (talk) 23:17, 22 July 2015 (UTC)
Yes, we have discussed it, and I thought that our current solution (tiles from external server not loading automatically) is fine with everyone. Nice to know that someone is working on the new tile server. Thanks for the effort that you put into it, and I look forward to seeing it operational! --Alexander (talk) 11:24, 23 July 2015 (UTC)

Is there a source repository for PoiMap2 somewhere? I found https://github.com/nicolas-raoul/PoiMap2, but it looks like an outdated fork. I wanted to make a pull request. MaxSem (talk) 19:57, 11 August 2015 (UTC)

Hello MaxSem! PoiMap2 is maintained by Joachim, who is not a Git fan it seems, but I have access a copy on an FTP server and can mirror the script to my Github whenever requested. I have left a message on his talk page saying you want to collaborate, the best is probably to explain to him what you intend to develop, or send him the source code if written already :-) Thanks a lot for your interest in dynamic maps! Hopefully they can be reused on other projects Syced (talk) 07:28, 14 August 2015 (UTC)

New service, https://maps.wikimedia.org is coming to Wikivoyage. Maps provide two features - tiles and static images, but at this point only has the basic one-language labeling. We hope it can replace the frequently breaking labs instances as a default base layer. This is a trial service - once it is clear that the service is needed, we will have to throw more hardware at it (relatively easy from the technical perspective, but requires some work and budget allocations). See also Maps home. --Yurik (talk) 16:46, 27 August 2015 (UTC)

Yurik, that's great news, but I think that I did not get the point. Do you want us to use maps.wikimedia.org instead of labs from now on? I believe we can do it (of course, with Joachim's consent), provided that you are available for resolving bugs and problems. --Alexander (talk) 17:21, 27 August 2015 (UTC)
@Atsirlin:, yes, that's the idea, but there is one "but": - user:MaxSem and I have been working on the new service for about 4 months now, and we think it is ready for real trials. Wikivoyage is a perfect place to be its first user, but I will not be online for the next week (taking my first vacation in a year and disconnecting from the grid), so I will not be able to assist with resolving bugs until I come back September 8th. It would be awesome if the community could evaluate the new service and report any issues found to Maps discussion page or in the phabricator, but I think we should wait one week until I come back to actually switch all of the map templates to it. What do you think? --Yurik (talk) 04:36, 28 August 2015 (UTC)
I agree. Moreover, it takes a few days before map scripts (which are also sitting on tools.wmflabs) are updated. Joachim, what is your opinion? --Alexander (talk) 07:20, 28 August 2015 (UTC)
First of all, the access from *.wikivoyage-ev.org to maps.wikimedia.org must be made possible. Otherwise, I can not test anything. -- Joachim Mey2008 (talk) 17:30, 28 August 2015 (UTC)
@Mey2008:, I just noticed this, sorry for not doing it earlier. Phabricator is a much better way to get this solved quickly - it gets tracked and processed properly. I created a patch to fix this, could you clarify who owns the domain? (People asked for it in the comments). Thanks!
@Mey2008:, update - the patch has been merged, you should be able to use it now. --Yurik (talk) 17:04, 18 September 2015 (UTC)
Thanks for the additional release of access. - The owner of the domain is the state-registered and non-profit association "Wikivoyage e.V."* under German law. The association is officially recognized as a charitable organization and exempt from all taxes and fees. *The addition "e.V." means "eingetragener Verein" (registered association). -- Joachim Mey2008 (talk) 04:40, 19 September 2015 (UTC)

Geo URI's on Web version[edit]

Swept in from the pub

The offline Kiwix is great. The geo URI's work well with offline maps.

Could we also have geo URI's on the webpage? Maybe not by default since not all user agents can handle it, but there could be a link to an offline version of the page with geo URI's.

My motivation is that before I travel somewhere, I update Wikivoyage and Openstreetmap with things I might find useful when I get there. But usually I am too late for my updates to be in the Kiwix and Osmand updates. So I save the destination page from the browser. Which works, except it is difficult to use the POI locations -- I could copy paste them into Osmand or maybe find the street address in Osmand. But if I could save a WV webpage with geo URI's I would be happy.

Maybe my use case is not that common, but I think it is important because it encourage contributions to WV instead of e.g. just creating personal favorites in Osmand --Elgaard (talk) 00:21, 13 August 2015 (UTC)

Alternatively, you can download all POIs as GPX file (maximum of 25 articles grouped together) [98]. You can import this file into OsmAnd. All search and routing functions are possible with this GPX data. - Joachim Mey2008 (talk) 05:16, 13 August 2015 (UTC)
I have exactly the same use case. I also use the trick mentioned by Joachim, but indeed I support showing geo URIs if the browser is a mobile browser. Do templates have the ability to know whether it is a mobile browser or not? Syced (talk) 08:47, 13 August 2015 (UTC)

Announcing the launch of Maps[edit]

Swept in from the pub

The Discovery team has launched an experimental tile and static maps service https://maps.wikimedia.org

Using this service you can browse and embed map tiles into your own tools using OpenStreetMap data. Currently, we handle traffic from *.wmflabs.org and *.wikivoyage.org, but we would like to open it up to Wikipedia traffic if we see enough use. Our hope is that this service fits the needs of the numerous maps developers and tool authors who have asked for a WMF hosted tile service with an initial focus on WikiVoyage.

Getting started is as easy as mw:Maps#Getting Started. We'd love for you to try our new service, experiment writing tools using our tiles, and giving us feedback. If you've built a tool using OpenStreetMap-based imagery then using our service is a simple drop-in replacement.

How can you help?

Based on usage and your feedback, the Discovery team will decide how to proceed. We could add more data sources (both vector and raster), work on additional services such as static maps or geosearch, work on supporting all languages, switch to client-side WebGL rendering, etc. Please help us decide what is most important.

mw:Maps has more about the project and related Maps work.

In depth

Tiles are served from maps.wikimedia.org, but can only be accessed from any subdomains of *.wmflabs .org and *.wikivoyage.org (referrer header must be either missing or set to these values). Kartotherian can produce tiles as images (png), and as raw vector data (PBF Mapbox format or json):

.../{source}/{zoom}/{x}/{y}[@{scale}x].{format}

Additionally, Kartotherian can produce snapshot (static) images of any location, scaling, and zoom level with

.../{source},{zoom},{lat},{lon},{width}x{height}[@{scale}x].{format}.

For example, to get an image centered at 42,-3.14, at zoom level 4, size 800x600, use https://maps.wikimedia.org/img/osm-intl,4,42,-3.14,800x600.png (copy/paste the link, or else it might not work due to referrer restriction).

We would like to thank WMF Ops (especially Alex Kosiaris, Brandon Black, and Jaime Crespo), services team, OSM community and engineers, and the Mapnik and Mapbox teams. The project would not have completed so fast without you. --Yurik (talk) 23:17, 17 September 2015 (UTC)

Yay :-) If there is no immediate blocking bug, I think we should start using it right away and see how it scales, to solve problems as fast as possible? I guess Joachim is the person who can make the change? Syced (talk) 03:25, 18 September 2015 (UTC)
There are a lot of quality bugs (like clipped labels), but no blocking bugs. Go for it :) --Yurik (talk) 04:02, 18 September 2015 (UTC)
Given recent issues around the change of Banner template, please isolate any changes on a low traffic article for evaluation first :) Andrewssi2 (talk) 04:18, 18 September 2015 (UTC)
Yurik, as far as I remember, Joachim asked to allow access from wikivoyage-ev.org. This is needed for testing. Otherwise, you can't expect us to switch to the new service. --Alexander (talk) 07:27, 18 September 2015 (UTC)
@Atsirlin:, thanks, I just saw it yesterday. Phabricator is a much better way to file such requests - that's how we prioritize work. The patch is done and waiting for the ops approval. --Yurik (talk) 16:29, 18 September 2015 (UTC)
PS. The patch has merged, should work now. --Yurik (talk) 17:05, 18 September 2015 (UTC)
Yurik, alright, we will use Phabricator in the future. At this point, we need a discussion and not a simple patch, though. What is your opinion about the issue raised in this thread? Can one add more detail to your maps? Can one perhaps configure a special map style for Wikivoyage (at least on a longer run), or is it completely unfeasible? --Alexander (talk) 07:02, 19 September 2015 (UTC)
I've wrote a script for the comparison of the Wikimedia map with Mapnik. There is missing a lot of information that are of interest for tourists: stops for trains and trams and the like. Names for city parks, squares and the like. Please compares itself [99]. -- Joachim Mey2008 (talk) 11:03, 18 September 2015 (UTC)
Yes, you are right. On the other hand, the new map goes in the direction of the original concept that we had back in WT times: a simple map where only POIs relevant to the travel guide (and those described in the travel guide) are shown. It may be an option to have this "simple" map embedded in Wikivoyage articles, while a more detailed map will be, of course, available as an alternative and also for offline use with OsmAnd. I do find the current version of Mapnik a bit "overcrowded" with different signs and labels.
Altogether, I would not mind to go for the simpler map from maps.wikimedia, provided that it is stable and accessible at any time. Other layers, including the detailed version of Mapnik, should be, of course, available too, and users may switch to them if they want. --Alexander (talk) 12:00, 18 September 2015 (UTC)
Congratulations to the WMF Maps team. I find the new maps to be visually much nicer, clearer and less daunting. While we don't yet have a test page to go off, I'd imagine our listing POIs will be a lot clearer on the map and not get lost in the surrounding noise. However, I do agree that simply too much info has been removed. That includes pretty much all public transit info (station names and locations, tram and bus stops, etc), at least for Melbourne. That sort of information is just non-negotiable on a travel guide map; parking, supermarkets, places of worship, etc are less important, and could be viewable by changing the layer to a more complex one. So I would like to see a test page, but I cannot support a wider implementation until a reasonable amount of public transport info is included. James Atalk 13:42, 18 September 2015 (UTC)
Thanks for raising important points! Our original intent was to build a vector tile platform - which has mostly been a success. Now is when we start thinking of what and how to draw on it. All the data, such as POI, etc, are in our database, and usually it is fairly easy to add extra features to the map. Yet, we need to have a very clear understanding of who needs what -- OSM standard map was designed mostly for the map editors, who needed to see all available data so they can see what is missing or incorrect. On the other hand, various map sites tend to show only some of that info that is relevant to their use cases. Wikivoyage is a map consumer, so we should be very specific on what data each type of article should show.
With mapnik/mod_tile approach, each tile generation was a very expensive process - it used 10-20 SQL queries for each tile to get all the needed data, convert it into an image, and cache that image. Vector tiles give us the ability to get all the needed data and cache it as data, not image. This means that the actual image gets generated in milliseconds, and we can decided at the last moment what data to include (labels languages/POIs/...) and what style to draw it in (road colors/width/icons/etc). On one hand, we want to keep caching "hit-rate" high, and only have a small number of different styles. On the other, it is very quick to add a new one once we have an agreement of what is needed.
Please take a look at Improving our map style to see what styling tools are available (similar to editing CSS in a visual tool). --Yurik (talk) 14:08, 20 September 2015 (UTC)
P.S. There is always an alternative path - multiple layers. WMF maps would provide the base layer, plus it would be overlayed with additional data from either Wikivoyage pages that contain KML data, or some database that resides on the wmflabs instance. WikiMiniAtlas uses both approaches. Since all the heavy lifting to generate the base map will be done by WMF maps, the labs service should be able to handle the load of extra data without problems. This route will also give the community much greater control over what and how is displayed, and allow for much more rapid changes. --Yurik (talk) 00:39, 21 September 2015 (UTC)
Yurik, thanks for your response. Regarding additional layers generated on wmflabs, I am not sure that we can extend this beyond our current position, namely, the POIs taken from Wikivoyage articles. After all, it is not easy to handle huge databases in a wiki format, and it would be strange to have our own storage of, e.g., public transport information when this information is more up-to-date in other sources. I think that we should rather go in the direction of slightly customizing your maps to our needs. One problem here is that none of us (except for, perhaps, Joachim) understands the OSM structure and will be able to contribute to the css-like styles that you mentioned. I understand how they are written, but I have no idea which extra things to write. Therefore, the main feedback from Wikivoyage users (including myself) is something that you have already seen in this thread: we would like to have information about public transport displayed on the map. It would be great if any of you guys could implement this for us. Then we may have other wishes, but, hopefully, they won't require too much effort from your side.
At this point, it seems to be crucial to include public transport and, when we have no other outstanding objections, implement the new maps site-wide in order to collect additional feedback. JamesA, Joachim, what do you think?
Joachim, can we have something like poimap3.php handling the new maps (in the beginning), so that we could easily switch between the old and new versions on-wiki? --Alexander (talk) 08:09, 21 September 2015 (UTC)
That sounds reasonable to me, Alexander. The only necessity I can think of for now would be public transport data. That is, train stations and names, tram stops and bus stops. Road data is already displayed, so not sure why this was overlooked. Indeed, Google Maps strikes a good balance in terms of how much data it displays I think, POIs aside. Then I'd be interested in seeing a few test articles, followed by a wider implementation for testing purposes. James Atalk 09:59, 21 September 2015 (UTC)
We should think carefully about whether this new Wikimedia map is already in a usable state. Please compare: left Mapquest, Mapnik, and right new Wikimedia map [100] or [101] or [102] or [103]. You can zoom and drag the left map for your own examples. Clicking creates a corresponding link in the address bar. -- Joachim Mey2008 (talk)
The scary rectangle over Braunschweig is its airport's airspace. There are two problems about this: it shouldn't have been mapped in the first place and we shouldn't have displayed it in any case. I fixed the first part on OSM side, by nuking both airspaces in existence. The second part is done with this commit, we will try to regenerate the affected area soonish. MaxSem (talk) 22:52, 21 September 2015 (UTC)
The map data are at least two months old. These roads in Coudersport, PA I have mapped two month ago [104]. For an update Mapnik required max. 10 minutes and Mapquest one day . -- Joachim Mey2008 (talk) 12:26, 21 September 2015 (UTC)
Joachim, I played a bit with the comparison. One major problem that I found is the lack of green spaces. I would not say that the greenery is absent completely, some parks are displayed of the map, but many of the smaller parks or green spaces like boulevards are missing. This makes the new maps rather dull in appearance and less friendly for users. Will you or Yurik know which features should be added?
Another thing is the yellow-orange-colored areas such as parking lots. Those may be also worth adding. --Alexander (talk) 06:12, 22 September 2015 (UTC)
Tracked at phab:T113479. Feel free to comment or add new tasks to Phabricator - i might miss requests in the discussions. --Yurik (talk) 14:54, 23 September 2015 (UTC)
The map update from OSM (phab:T110262 and phab:T108459) is at the top of our priorities que, will get done soon, right after we resolve phab:T113008 (displaying disputed boarders). I think we could get the transportation POIs done quickly (subways, bus, train, ships), while other POIs might take a bit longer. Max would know better about the OSM's POI data. --Yurik (talk) 21:13, 21 September 2015 (UTC)
Added phab:T113310 -- creating Points of Interest, including transportation POIs. Please comment on the task. --Yurik (talk) 23:19, 21 September 2015 (UTC)
Yurik, thanks for providing the links. It's much easier this way because Phabricator is scary for most of the regular editors=) Please, also check my reply to Mey2008 above. I hope that you can re-phrase it in a more meaningful language. --Alexander (talk) 06:12, 22 September 2015 (UTC)
Alexander, I have added the new base layer "Wikimedia" and an overlay "Traffic" with stops (+ name) and lines (+ numbers) for testing purposes.[105]. Apart from the lack of car parks the Wikimedia map now not urgently needs to be extended, I mean. -- Joachim Mey2008 (talk) 10:37, 22 September 2015 (UTC)
Thanks, Joachim. Will it be available on tools.wmflabs.org in the next days, or is it planned for the Wikivoyage server only? --Alexander (talk) 13:15, 23 September 2015 (UTC)
. After the next update on Monday "poimap2test.php" will also be available on tools.wmflabs.org. -- Joachim Mey2008 (talk) 04:32, 26 September 2015 (UTC)

Transportation POIs are here: SF, NY, London, Japan. Please take a look and tell us if this is this is enough to get started with the wikivoyage migration. Also, I am thinking of implementing an MW extension to support <map> tag natively, but with the ability to expand it via common.js and other similar methods. Would love to get feedback on how to better structure it to provide both the stability/integration with other tools, while being flexible and expandable by the community. Thanks! --Yurik (talk) 23:20, 12 October 2015 (UTC)

Hi Yurik , would you be able to explain in layman terms what you are proposing with this migration? Are you replacing the existing maps control? Will you be able to use it on a few experimental pages in the first place? Andrewssi2 (talk) 23:52, 12 October 2015 (UTC)
@Andrewssi2:, re transportation POIs - the majority of the transportation POI work is done, and once the community is happy with the result (see city links above), we will update the main servers to show it on all maps that come from the maps.wikimedia.org. @MaxSem: thinks that we might need to hide POI's labels in some lower zoom levels to make it less cluttered, but that shouldn't take long, so please evaluate and let us know.
 Regarding the second portion of my message (completely unrelated to POIs): at this point, there is a large number of labs-based maps, such as the great one implemented by @Mey2008: on tools server (used by Wikivoyage), WikiMiniAtlas by @Dschwen:, and many others. Yet, because they are not on the WMF production servers, they do not scale well to be included on all articles for all users. Additionally, they all share a lot of similar functionality. So my proposal is for the tech community to agree on one common maps framework for all wikis to use, something that will provide common mapping functionality such as showing static and dynamic maps, but also allow community to add additional content and functionality specific to the project/language. Each community should not reinvent the wheel if it was done for another community, it should only add what is missing in the existing implementation. And WMF with community's help will implement the maps basics that everyone can work with, and that will scale to handle all the traffic. Also, this will NOT replace the existing map controls from the beginning - instead it will allow a few articles to be tested with it, and once everything is good, the community will be able to migrate at its own pace. Also, the new system will allow the Visual Editor map insertion -- see demo. See also technical architecture at phab:T115290. --Yurik (talk) 01:22, 14 October 2015 (UTC)
Sounds good Yurik . I would suggest creating a new discussion in the pub to announce this when you have a deployment plan ready. --Andrewssi2 (talk) 01:58, 14 October 2015 (UTC)
I'm quite interested to see where this goes. If the maps can someday do what is displayed in this image from the Phabricator link above, it would go a long way in enabling dynamic region maps. Including KML data also looks interesting. I draw static maps based off of shape files, but I think I could export them (or at least some features) as KML files, too. -Shaundd (talk) 04:31, 14 October 2015 (UTC)
Re: transport POIs, it's a welcome improvement, but still fairly patchy. Just checking Melbourne, tram stops and tram lines are completely absent, although train stations/lines and bus stops have been added (they're hit and miss, but that's an OSM data issue). Ferries are also absent.
I also agree with Andrew that any implementation into Wikivoyage itself must be done slowly and progressively on a few articles at a time, to test for bugs and other issues. While the new banner extension which was recently implemented is welcome, the implementation was very poor, with dozens of issues and bugs causing and continuing to cause sitewide issues and I'm disappointed it was not implemented more carefully. We do not want to see the same mistakes repeated with Wikimedia Maps. James Atalk 08:42, 14 October 2015 (UTC)
Not to sidetrack this thread, but in fairness to User:Sumit.iitp the initial banner rollout was done on a small number of articles, went through several feedback cycles, and overall went quite smoothly. It has mainly been the many surprise changes to the extension since then that have resulted in sitewide issues. -- Ryan • (talk) • 21:51, 14 October 2015 (UTC)
In the real world, if something changes in the underlying system then is actually quite common in IT for end users to blame those associated with that change when something goes wrong. I feel that there should be better transparency and formal process in new changes so that we can avoid exactly that perception.
I raise this now precisely because I don't want to see those people who are spending time and doing awesome work in improving the technical implementation of the site getting wrongly blamed for new problems just because they were associated with (for example) a new map system.
It would help if we could have a dedicated page on WV for announcing and discussing technical changes, rather than using the pub which I believe invariably causes confusion to most. A request to change the CSS file should not (for example) be posted here because it just looks bad when something goes wrong afterwards (rightly or wrongly). Just my 2 cents. Andrewssi2 (talk) 00:25, 15 October 2015 (UTC)
You know, an ideal system would involve things like CSS changes being handled like real code, rather than like changing words on an article. The person proposing the change ought to be able to submit a suggested "edit" (a patch) that isn't live until other knowledgeable people have reviewed it and approved it. Unfortunately, there's no way to have a "two-key system" in MediaWiki right now. WhatamIdoing (talk) 20:52, 15 October 2015 (UTC)
Yurik, summarizing the relevant part of this thread, it would be nice to have more transport POIs per JamesA's suggestion above. Once these new POIs appear on maps.wikimedia.org, we can switch a few pages to the new maps. Then we will ask for a broader feedback that, again, will most likely concern the content of the maps and not their implementation. This whole process will go much faster if our current map server has another long downtime, so that everyone understands what real benefit the new map server has... --Alexander (talk) 07:35, 15 October 2015 (UTC)
So, should I make the lab servers crash again to promote maps? :)))) Anyway, Max will see what he can change with POIs, and I will regenerate the data the moment he is done. In any case, once POIs are "good enough" for a certain region, we could try adding them to the articles of that region to have a wider visibility/discussion. Lastly, what page is the best for the tech discussion on WV? Thanks! --Yurik (talk) 18:10, 15 October 2015 (UTC)
I think that Pub is the best place for this, and in fact it is the only page that everyone reads. --Alexander (talk) 19:21, 15 October 2015 (UTC)
Alexander - I'm not suggesting you stop announcing these things on the pub, but I am suggesting that the technical detail should go into a separate discussion page.
WhatamIdoing - You are right that we can not have a good technical process, such as a GIT pull request. We could however create a formal page for these changes to be announced and discussed, something like Wikivoyage:Script_nominations . If there is support I can go ahead and progress this. Andrewssi2 (talk) 21:56, 15 October 2015 (UTC)
Can you clarify what is being proposed? If the goal is to "approve" services used by Wikivoyage that are managed elsewhere (such as the banner extension), a local page won't make any difference since those tools are going to get deployed whether or not we approve them, and it is up to us to track them and stop using them if they become problematic. If the goal is simply to have a place to discuss things like the banner or maps outside of the pub, would a separate page be the best way to handle that, or would it be better to just suggest moving discussions to Wikivoyage talk:Banners or Wikivoyage talk:Dynamic maps Expedition if things get too detailed? -- Ryan • (talk) • 22:15, 15 October 2015 (UTC)
Not 'approve' but 'formalize'. I believe the way technical changes are proposed (the above being a good example) is too ad-hoc for comfort. Announcing a change on the pub and pointing to Wikivoyage talk:Banners or Wikivoyage talk:Dynamic maps Expedition would help a great deal, although if this is too hard for people to practice then a separate page would help as a focus point. I don't buy the fact that we have to have everything on the pub because "it is the only page that everyone reads".
I maintain that having too much technical discussion on the pub is inappropriate and causes confusion, and therefore I was only trying to help by suggesting a better way of doing things. If there is no support for this position then fine, I won't persue it any more and let things run as they are. Andrewssi2 (talk) 20:46, 18 October 2015 (UTC)

Individual engagement grant for Wikimedia Maps rendering[edit]

Swept in from the pub

I've proposed an individual engagement grant to improve some aspects of the maps style: https://meta.wikimedia.org/wiki/Grants:IEG/Wikimedia_Maps_Rendering_Improvements. I'm looking at road name rendering and boundary rendering. Pnorman (talk) 06:16, 28 October 2015 (UTC)

Dear Wikivoyage, please support this proposal - Paul is an expert in the field, and has already helped us with many mapping issues. If he gets a grant, we will be able to substantially improve the quality of our maps.
P.S. @Atsirlin: @JamesA: Transportation POIs are now part of the map (here), and should finish generating in the next day or two. --Yurik (talk) 14:09, 29 October 2015 (UTC)

Blockers and non-blockers[edit]

While I thank you guys for your hard work, I still think it's not as good as the OSM implementation. Just checking Melbourne here, the map becomes covered in the little black POIs which makes it look a little too cluttered. While slightly different, the train and tram POIs look about the same despite being very different modes of transport. And when you zoom in on that map to a more district level, all of the POIs vanish.
I acknowledge this may take time, and I don't want to hold up the entire process. If you guys wanted to seek consensus to test on one or two articles, I wouldn't oppose that. But it's still not ready for site-wide deployment. James Atalk 00:14, 30 October 2015 (UTC)
@JamesA:, thx for the feeback, and you are right! The raster style is well polished, but cannot move forward - there is no map in Melbourne article because servers will melt :) Kartotherian is not as polished, but it can improve much better. But the only way WMF will allocate more resources to Maps, is if Maps are used more than the current 3.5K users/day, 100K tiles/day. (see stats). Plus, if many users don't like something, there is a higher chance one of them will volunteer to fix it. So we could try to get it all perfect before using it on high-usage pages, or we could offer the non-perfect service with the expectation of a much more rapid fixes. Regardless, any help is welcome to try to make it better :) --Yurik (talk) 01:59, 30 October 2015 (UTC)
I'd prefer you guys start implementing on a few pages, and go from there, rather than us sit here and nit-pick all day! The map itself seems to work, with a few minor bugs in regards to labels. I'd suggest you guys go ahead and create a new topic below in the pub proposing implementation on 10 pages or so as an initial test :) James Atalk 08:30, 30 October 2015 (UTC)
Yurik, I started a discussion in Russian Wikivoyage where it may be easier to reach consensus instead of doing 10 pages (and testing what?). Since I guess that you read Russian, you are welcome to join.
Here I will try to organize deployment on a few pages in the beginning on next week, unless you or someone else will do it earlier. But mind my previous comment: the consensus for the new maps will be immediate when the current map server stops working again. On the other hand, you may spend ages trying to address every comment of ever user here. --Alexander (talk) 08:38, 30 October 2015 (UTC)
All we need for now is for Joachim (please and thanks!) to replace the current poimap2.php, with the poimap2test.php as it is functionally the same except for the additional layer. Discussion about where the Wikimedia layer is to be used, or when it can replace the Mapnik layer as default, can be discussed separately - instead this will just act as another option in {{Mapframe}}, eg. the relief maps and Mapquest Open previously, though Module:Layers needs to be checked for restrictions. I also think there is still a little bit of misunderstanding about what the Wikimedia map server can do for now, because any stoppage of the current map server in Tools Labs will occur regardless of whether the new Wikimedia layer is being used. In future plans as said, hopefully it can be moved wholesale to the Wikimedia map server, though I'm not sure how they'll handle external developers. -- torty3 (talk) 11:29, 30 October 2015 (UTC)
I agree. poimap2test.php can be and should be merged into poimap2.php (Joachim, Danke im Voraus!), and new Wikimedia maps will appear as a non-default layer in every article. However, this does not answer Yurik's question. They need more usage and more traffic, and this won't come unless their layer is used as default. --Alexander (talk) 13:13, 30 October 2015 (UTC)
Poimap2 now has a new layer "Wikimedia" (layer=W). Therefore, "B&W" layer is no longer present. "Mapnik" layer is further default. Update runs on Monday if no other opinions. -- Joachim Mey2008 (talk) 07:18, 1 November 2015 (UTC)
I applaud the work done, and I'm looking forward to where it will go and to using it. However, I agree with JamesA that it's not ready for wide implementation just yet. @Yurik, is this assumption that WMF will only allow progress on your maps work when it's already widely implemented an actual management decision? Or is it just your expectation? I'd be surprised, considering the experiences with VisualEditor and Mediaviewer. Surely if we, as a community, confirm our interest and commitment to this project it can first be properly developed before we implement it site-wide? JuliasTravels (talk) 15:09, 1 November 2015 (UTC)
I don't work with that team, so I don't know any specifics. Speaking generally, most of the teams will start talking about their quarterly goals (for January through March 2016) later this month. The teams won't be deciding "Maps or no maps?". They'll be deciding "Maps (which is barely getting used) or this other thing (which might have a bigger effect)?".
If you want more development on Maps, then your goal will be to convince them that Maps is a better use of their time than any alternative project. This is generally done by deploying it now (or soon), or by agreeing that you will accept it as soon as it reaches a specific, defined level. This second option requires producing a complete list of actionable blockers, and agreeing that the community will prevent the goalposts from shifting. Making a list of non-blocking requests is also very helpful, because it helps people differentiate between things that are useful or desirable, and things that are absolutely necessary for the product to be functional. (Also, it increases the chance of getting what you want.)
The line between "blocker" and "non-blocker" can be drawn wherever you want. However, you should remember that getting continued work on a project like this is a negotiation between you and the devs (and indirectly, with the rest of their department, which might want them to stop work on Maps and instead focus on something else), so the higher the "price" you put on your agreement, the less likely you are to make a deal in the end. WhatamIdoing (talk) 23:31, 3 November 2015 (UTC)
Yes, absolutely! --Alexander (talk) 00:59, 4 November 2015 (UTC)
Well said WhatamIdoing, thanks! Highly recommend it to everyone. JuliasTravels, unlike Visual Editor, the maps has been done by two engineers with the blessing of our immediate managers. Now our managers need to convince their higher ups that maps project should be invested in. Our numbers is what everyone will look at at the end of the day. This quoter is dedicated to working with the community, see what feedback we get, what should be improved. Also, I am working on [[mw:Extension:Kartographer <maps> tag]] to bring some of the amazing work poimap2 has done to production, suggestions are welcome. --Yurik (talk) 19:44, 4 November 2015 (UTC)

New map layer added for Wikimedia/Kartotherian[edit]

Now Salzburg is using the new map (the old one can be accessed via the link "Click for full-screen map"). I suggest to discuss this change till Sunday and proceed with a broader implementation, provided that no reasonable suggestions are given. To understand the meaning of "reasonable" in this phrase, I refer everyone to the discussion taking place right above the horizontal line in this thread. We are not in a position of a customer who pays and who can ask developers to address every quirk and wait until everything is perfect. In fact, we are very lucky to get things for free, but we have to acknowledge the fact that Wikivoyage users have neither skills nor capacity to develop any tile servers on their own. Therefore, we either use one of the available options, or we suck.

I am perhaps the only active contributor who has access to the wikivoyage scripts on tools.wmflabs.org. Every time maps are not displaying properly I get a ping and requests to "do something". But you have to understand, guys, that I can't do anything but re-start the service. It is Joachim who is doing all the script writing, but even he has no control over the tile server that we are currently using. In fact, we have no connection to this tile server at all. When it is working, we are fine. When it stops working, we sit and wait until it is up again (this happened in June when regular maps were not available for about 2 weeks, and we used external map server, which is against basic WMF policies). It is a very fragile situation, and we fully rely on the tile server that is beyond our reach and control. Therefore, it is absolutely crucial to have people like Yurik and his team, who can provide the support that we need and who can also help us with future development if we want to. --Alexander (talk) 00:47, 6 November 2015 (UTC)

I would suggest you guys start a new discussion at the bottom of this page. This recent discussion here in this thread hasn't engaged a very large cross-section of the community, probably because it's not very visible. Otherwise, I suspect there may be a lot of unhappy people post-implementation. We had a lot of bugs after the banner extension went live, and continue to have a lot of bugs. I know a lot of people worked hard on that project, but such rushed implementations are simply not ideal. I certainly support a wider implementation, but not on a huge scale which could have significant effects on thousands of our articles. James Atalk 13:07, 6 November 2015 (UTC)
What means "wider, but not on a huge scale"?
I also think that constant references to the pagebanner extension are absolutely irrelevant here because we do not discuss any functionality available on site. We discuss changing one tile server to another tile server, while the functionality of poimap2.php and {{Mapframe}} will stay exactly the same as before. Neither the template nor the poimap2.php script are going to fail when they take the data from another tile server. --Alexander (talk) 13:42, 6 November 2015 (UTC)

I just switched Salzburg, Jaipur, Valencia, and Budapest to W by default for evaluation purposes. The question is - what is the process for community to decide if the example succeeds? --Yurik (talk) 23:24, 5 November 2015 (UTC)

  • I have just made this switch at the article on Istanbul's Old City, to check it out. I noticed losing all the street and attraction's names, and most urban transport routes, which I think it's not cool. Ibaman (talk) 14:36, 6 November 2015 (UTC)
Street names are there when appropriate zoom level is used. The lack of other features has been explained above. --Alexander (talk) 14:49, 6 November 2015 (UTC)
Ibaman, are you talking about Istanbul Old City? I just tried the layer switcher, and noticed that it still showed most of the street names. What exactly did you miss when you switch? Also, by attractions, do you mean POIs generated by poimap2? Or something that is part of the map itself? In any case, please see the comment by WhatamIdoing above - community needs to be very specific on goals and blockers so that we can move forward. There is no unicorn, but we can certainly work towards perfection. --Yurik (talk) 22:58, 6 November 2015 (UTC)

Issues: Roads under bridges[edit]

One thing that does not appear clearly on the Wikimedia layer is when roads go underneath road bridges, and there is no connection between the different height roads. I first noticed this with the North Bridge and Dean Bridge in Edinburgh, but the problem is probably more clearly seen with Newcastle upon Tyne. Look at the area around this marker: 4 Tyne Bridge. On Mapnik, Mapquest and Relief Map it is clear that there is no connection from the Quayside to Tyne Bridge, as it is on the ground. But the Wikimedia layer shows a connection there. It also shows connections in several other incorrect places nearby. Similar things can be seen with the Sydney 5 Harbour Bridge, and that case it also is not clear (compared to the other layers) that the Harbour Tunnel is a tunnel. On a more positive note it does seem to respond quicker than Mapnik AlasdairW (talk) 15:52, 6 November 2015 (UTC)

Thanks AlasdairW, this is in part what Paul is planning to work on, please give you support to his proposal here. Also, this issue has already been reported, but please add your examples to it so they don't get lost when someone is working on them. Once again, thanks for reporting! --Yurik (talk)

Issues: Transport POIs[edit]

<quote>While I thank you guys for your hard work, I still think it's not as good as the OSM implementation. Just checking Melbourne here, the map becomes covered in the little black POIs which makes it look a little too cluttered. While slightly different, the train and tram POIs look about the same despite being very different modes of transport. And when you zoom in on that map to a more district level, all of the POIs vanish. James Atalk 00:14, 30 October 2015 (UTC)</quote>

I agree on this point. Bus stops and train/metro stations are near indistinguishable at zoom level 17 and 18, which I find problematic for travelling since buses are usually not the first choice in any city which has a great subway or metro system. In comparing Google Maps and Kartotherian, I noticed that for the equivalent scale for Google (zoom level 16), bus stops are not shown at all. See Chinatown in Singapore for an example, can you tell where the train station is? -- torty3 (talk) 09:35, 11 November 2015 (UTC)

Issues: One-way roads[edit]

One-way roads are not visible on the new map layer. -- torty3 (talk) 09:35, 11 November 2015 (UTC)

Issues: Map sync time with OSM[edit]

<quote>The map data are at least two months old. These roads in Coudersport, PA I have mapped two month ago [106]. For an update Mapnik required max. 10 minutes and Mapquest one day . -- Joachim Mey2008 (talk) 12:26, 21 September 2015 (UTC)</quote>

How often is the data recollected from OSM? -- torty3 (talk) 10:30, 11 November 2015 (UTC)
Once implemented, it will be done multiple times per day. MaxSem is working on it right now. --Yurik (WMF) (talk) 01:05, 12 November 2015 (UTC)

Issues: Language[edit]

All labels on Japan areas are in Japanese, despite OpenStreetMap having English names for at least some of the objects I have checked. Even for Japan maps, the English Wikivoyage should show maps in English as much as possible. The same problem is present with current maps, but that would be nice to solve that. Thanks! Syced (talk) 11:47, 18 November 2015 (UTC)

This would be a killer advantage of course. -- torty3 (talk) 12:50, 21 November 2015 (UTC)

Consensus to change default map layer to Wikimedia/Kartotherian[edit]

For me, the new map layer is much clearer compared to Mapnik, and that it is worth moving forward with Kartotherian. Mapnik was not the initial choice in the first place for being too messy, but was the fallback after the security and legal problems that external map layers had. I have reservations about some of the public transport POIs and other rendering issues, though I'm confident User:Yurik will take note of them. Otherwise, please do state clearly what would be expected before this switch is to be made. I apologise for the mega-chop of discussions, but it got entirely too unwieldy (huge Mediawiki fault). -- torty3 (talk) 09:42, 11 November 2015 (UTC)

I give my support to changing the default layer to the new Wikimedia Maps, although only under the condition that it will be continually improved in the near-future. Every time I use it, I note more and more problems, such as a lack of distinction between roads at different levels in the hierarchy (in some cases, gravel roads are marked the same as 4-lane highways). However, I understand that we cannot continually stall the process and also desire some progress. I note that those guides which were apparently changed to the Wikimedia default above (such as Salzburg) still appear as Mapquest Open for me (indeed, all my maps are Mapquest Open, Mapnik is never the default). James Atalk 11:23, 11 November 2015 (UTC)
Without more definite support, I would perhaps suggest the Maps team (@Yurik:) improve some of the map rendering:
  1. Give train stations and ferry terminals labels at zoom level 16.
  2. Make train stations and ferry terminals more prominent icons than bus stops at zoom levels higher than 16.
  3. Remove bus stop labels? (this is iffy)
Once that's done, we will switch right away to using the Wikimedia layer as default, although if more people chime in, an immediate switch could occur too.
Apparently gravel roads being marked the same as highways is a debate of style, see phab:T111884. -- torty3 (talk) 14:30, 17 November 2015 (UTC)
Comment. I'll defer to torty3 on issues related to maps and will support a change if recommended, but could someone summarize what is being proposed, and why? As I understand it:
  1. We want a map service that is fully supported by Wikimedia, and this proposal will switch to a service that will eventually get that level of support.
  2. At the present time that service isn't as good as the existing maps (see the bugs and feedback above).
  3. There is a belief that only by increasing usage of this new service will it be given the needed attention to improve.
Is that correct? Again, I'm happy to do what the people who support our maps infrastructure want to do, but if wider support is being requested then it would be nice to better understand what is being asked. -- Ryan • (talk) • 15:34, 17 November 2015 (UTC)
Yes, it's a fair summary. Technically, the new map service is already supported by WMF because its developers are WMF employees. --Alexander (talk) 16:46, 17 November 2015 (UTC)
Support per the discussion above. --Alexander (talk) 16:46, 17 November 2015 (UTC)
Seems like a leap of faith in many ways, but all efforts to move towards a stable map tool are very much appreciated. Support Andrewssi2 (talk) 22:10, 17 November 2015 (UTC)

Comment. I think that the "Roads under Bridges" issue is a serious problem for a few city centres - generally those on steep river banks. It is a minor irritation if a road connection is not there when driving and a one mile diversion is required as a result, but it is more irritating when walking about a city centre, and finding yourself walking 100 feet underneath the road that you want. I find that the Mapnik or Mapquest layers are clearer for most places, but there are some like West Coast Tasmania where the Wikimedia layer is best. However I do recognise that this is the start of what could be great, and is responsive, and so I won't go as far as opposing this provided editors can still select the best layer for a particular city. AlasdairW (talk) 00:11, 18 November 2015 (UTC)

Support under the understanding that it is what WMF think is the best (correct me if I am wrong). Syced (talk) 11:54, 18 November 2015 (UTC)

Support - I think the information on the default OSM layer is better, but I'm increasingly frustrated by its lack of stability and some tiles just not loading, particularly when I zoom in. I agree with whoever said it's a bit of a leap of faith at this point, but I think this map layer gives us a more stable platform and more potential for the future so I support. -Shaundd (talk) 18:49, 18 November 2015 (UTC)

Support - Let the use of Maps increase than the current 12K users/day, 150K tiles/day. Quoting Yurik, if many users don't like something, there is a higher chance one of them will volunteer to fix it. Csyogi (talk) 10:26, 19 November 2015 (UTC)

Comment From what I am seeing, most of the negative feedback about the Wikimedia layer concerns the more detailed levels of zoom (16-18). Having looked at a few more maps, I think that the Wikimedia layer is the best for zooms of around 10 or less. Would it be possible to start by having it as the default layer for low zooms (say 1-12) and Mapnik the default for high zooms (13-18)? The threshold could be moved up as issues are addressed. AlasdairW (talk) 11:47, 21 November 2015 (UTC)

While I agree with your statement, I don't agree with that action at all, which would be a de facto non-change given that the vast majority of articles would have zooms higher than 13 (at least for cities). I'm even a little pessimistic about the volume of traffic the developers expect to measure before such a hobbling, let alone after. Just to note for posterity, currently 2279 cities have mapframes and 21571 articles have a link to the map. It is possible, but also with added complications eg. conflicts with other Wikivoyages
To add one more point to Ryan's succinct summary: that definite blockers that prevent action (transport POIs was one) be set otherwise. I think the discussion has been constructive though, in gathering a list of concerns/non-blocking items from the community that should assist developers in deciding the priority for tasks, and also a sample of map style design philosophy for low, medium and high zoom levels (still more work to be done here). @Yurik: One more refined request for map labelling too after a bit more checking, for airports, train stations and ferry terminals to be labelled at zoom levels 15 and below.
Nonetheless, I'm going to plunge forward and make the change, it's easily reversible after all and individual pages can be set to Mapnik. -- torty3 (talk) 13:13, 21 November 2015 (UTC)
@Torty3:, this is the first level (z14) that shows transportation POIs, including ferries. We have been thinking about hiding everything at z14 (phab:T117154). Is that what you are asking? Or are we missing some transportation POIs at z15 somewhere? --Yurik (WMF) (talk) 00:29, 22 November 2015 (UTC)
P.S. Thanks for switching!
I think that may be a good move, or perhaps the size of the icons could be reduced also? The transportation POIs are all there, but I was trying to distinguish between icons and labels. Labels only show up at z17 right now. Train stations and airports are usually good landmarks, so the label names would help at z15 and z16 (after checking through most city and city district articles are using those levels), although that is at your discretion. Also in my opinion bus stop labels are never shown on most maps, and ideally POIs at z17 and z18 would look something like POIs at z16 in terms of icon size difference. -- torty3 (talk) 03:57, 22 November 2015 (UTC)

Crossing the 180th meridian causes problems[edit]

I was checking out Pacific War and spotted a problem: the map doesn't loop across the 180th meridian. When the page loads the map, item #5 (Pearl Harbor in Hawaii) is absent from the map. If you scroll the map to the west... past Asia, past Europe, past North America... you get to Hawaii, and there's the missing POI marker! But keep scrolling westward to Asia and none of the other markers are present. It's only drawing the POI marker on a single point on the map, and not taking into account that the globe wraps at the 180th meridian. --Bigpeteb (talk) 21:41, 1 December 2015 (UTC)

Map layer option in User preferences?[edit]

I wonder if it would be possible to add an option to the User preferences menu where users could choose a personal default map layer? I, for instance, prefer the Mapnik layer. It's good when doing major edits to an article and I think it looks nicer too. Yes, it's just two clicks away in the dynamic map menu but it would still be practical if I could choose it as my personal "default map". ϒpsilon (talk) 13:27, 3 December 2015 (UTC)

Wikidata integration[edit]

What about integrating a Wikidata ID parameter in the listings templates? The dynamic map could show pictures, auto descriptions, websites or other related information based on this mapping. It would be especially useful for sights. The map could also gain a multilingual feature based on the translations stored in Wikidata. What do you think? T.seppelt (talk) 12:27, 9 May 2016 (UTC)

A {{listing|wikidata=...}} parameter was suggested but (at least on en:) nothing was ever done about it. No one had given any thought to integrating it into the map. Interesting idea.
The question of whether {{listing}} could auto-lookup address, telephone number or other missing fields was raised. That could be done in a few ways: a listing editor which uses Wikidata to populate other fields (which would then be saved with the page), an automated "bot" script using the Wikidata link to look up and populate other fields in the listing or the listing template/module looking up the missing fields on-the-fly when the page is rendered. While it's now possible for a Lua module: to look up an arbitrary field from any arbitrary Wikidata entry, this lookup is "expensive" in server time. That may be one reason that no one has actually tried to use this. Some languages (fr: at least) do have a "wikidata" field in {{listing}} which generates a visible, clickable link but their current deployment implements no automated lookups based on the information.
Wikidata might be usable as a way of detecting that a change has to be applied to multiple language pages ("oh look, the Super 8 is now rubble, lets remove it from fr:Fort McMurray") if it gave the listings a unique identifier (such as a Wikidata Q-number) to identify them as the same venue. The downside is that every listing would need a Wikidata entry, which is a huge number of records to be created. We could try to identify a listing uniquely from a telephone number or other contact info, but that's risky as the listed number is often the franchise chain´s reservation desk. +1-800-800-8000 tells us the property was a Super 8, but doesn't tell us which Super 8. Contact info also is likely to be affected by franchise affiliation changes (so a Knights Inn becomes a Days Inn and the website or freephone numbers change, while the rest of the local info is the same).
Occasionally, we do translate entire articles from other languages: Amqui is a blatant ripoff of fr:user:Amqui's article on francophone Wikivoyage and Matane is just more of the same. A Wikidata link might get us the English-language name of an individual venue, but the description text would still need to be rewritten.
I suppose there are two key unanswered questions: (a) how do we get a Wikidata number for every listing in the first place? (b) how do we avoid this causing a lot of time-consuming lookups every time the server regenerates the page? Neither is unresolvable, but little has been done to pursue this as the odds of a site having a Wikidata Q-number listed in any-language Wikivoyage if the rest of the info is incomplete in the listing is low.
I'm also a bit unsure what you intend by "auto descriptions" on the map pop-up captions. There isn't much room in that bubble for anything more than a name and a thumbnail image. I suppose d:Q134883 could cause the cartoon caption style box to pop up when clicked with "w:CN Tower, www.cntower.ca" instead of just the name; until it's clicked, nothing happens so no huge change in server load? (We handled an image field that way, listing|image=...whatever... only displays when a map icon is clicked.) (Oddly, neither WP nor Wikidata has the telephone number for this building, but both know it is precisely 553.3±0.1 metres tall). K7L (talk) 18:12, 9 May 2016 (UTC)
I've been giving some thoughts to Wikidata integration for listings based on the discussion at Wikivoyage talk:External links#Revisit policy on linking to sister sites?. For places that have their own Wikipedia article (and thus an existing Wikidata item) I think this field could be very useful at least for lat/long, official link, and possibly link to Wikipedia, with the possibility of utilizing additional fields as time goes on. At least initially I'd suggest limiting this type of integration to only existing Wikidata items, and NOT create new items for places like the local Super 8 motel. Also, as K7L notes, performance would need to be investigated, and language differences would initially limit the number of fields that would be feasible for sharing. I haven't had time to pursue this integration yet, but I think it might not be too hard to add a Wikidata lookup to the listing editor, and it would then be easy enough to use that field to modify the listing templates to display lat/long and official link from Wikidata (if that info isn't explicitly included in the listing data). -- Ryan • (talk) • 18:30, 9 May 2016 (UTC)
I'm wondering if moving clickable Image logo indiquant que la suite affiche un lien wikipédia Image logo indiquant que la suite affiche un lien vers l'élément wikidata Image logo indiquant que la suite affiche un lien openstreetmap Image logo indiquant que la suite affiche un lien facebook Image logo indiquant que la suite affiche un lien twitter icons into the pop-up cartoon bubble on the map (like we do for listing|image=... now) might be a possible compromise to keep this stuff out of the main text body? It'd appear (under the image) only if the map icon is clicked. There are fr:Modèle:Listing icons for everything from wheelchair access to wi-fi; moving these to the pop-up map bubble minimises clutter, at the expense of displaying only if valid (lat, long) are present.
The other possibility is that the wikidata= field is used only behind the scenes to do other lookups, and not displayed as a clickable link at all.
That still leaves the issue of how to get the Q number into the listings. Telephone number as unique identifier is more difficult than I expected, as too many records like d:Q1631006 seem to omit it (and that's a really famous number). Maybe we could use the phone number to match en: listings to listings in other-language WV editions, then see if those {{listing}}s contain Wikidata or WP links which an automated script could use to access useful or interesting information via Wikidata. K7L (talk) 19:58, 9 May 2016 (UTC)

Bugs and comments about the new maps[edit]

Swept in from the pub

New maps have been enabled on en-wikivoyage. Please add your comments here, or create Phabricator tickets. All layers code is at MediaWiki:Kartographer.js, so either experiment there or do pull requests at GitHub. Once the code is more stable, I will move it into a proper MW extension, so that it can be localized and shared for all other languages (please don't copy it to other langs just yet).

Done[edit]

  • Yes Done {{mapmask}} does not seem to be implemented for the new maps - see Culver City for an example of an article that should include a mask. Is there another way to implement this functionality with the new maps? -- Ryan • (talk) • 21:35, 8 June 2016 (UTC)
  • check out the new and greatly improved {{Mapmask}}. Some documentation help is needed. --Yurik (talk) 03:40, 9 June 2016 (UTC)
    • Thanks! -- Ryan • (talk) • 04:09, 9 June 2016 (UTC)
  • Yes Done I'm not sure if this is temporary or not, but Kern County no longers shows any markers on the map. -- Ryan • (talk) • 21:35, 8 June 2016 (UTC)
  • A new version of Kartographer was deployed today, and we forgot to add a config flag. Thanks for the heads up, it is now fixed. --Yurik (talk) 23:21, 8 June 2016 (UTC)
  • Yes Done When editing Helsinki/South about an hour ago, I was wondering why someone has put a superfluous sleep price range box above the dynamic map. It doesn't show up anywhere in the article's wikicode either. Then I noticed the same thing in all other Helsinki district articles. And in every article with a mapframe from Nashville to Nuclear tourism. Perhaps it has something to do with the new map?
  • Sorry, must have accidentally copy/pasted an extra line from somewhere. It was already reverted (thanks @Doubleplusjeff:) --Yurik (talk) 15:32, 10 June 2016 (UTC)
  • Yes Done Also, the mapmask doesn't seem to work any longer. ϒpsilon (talk) 06:58, 10 June 2016 (UTC)
  • Technically the mapmask is incorrect because the last point has to be the same as first (at least according to my reading of the geojson spec). But it seems to work ok without it, so i removed the validation. --Yurik (talk) 15:17, 10 June 2016 (UTC)
  • Yes Done Would you also consider adding a parameter to {{mapframe}} so that user can select which group(s) ie. |groups=go,sleep,do| go on a map as well? otherwise use default list? -- Matroc (talk) 16:19, 10 June 2016 (UTC)
I'm not sure if it's necessary to be able to switch on/off different types of labels individually. In the former version of the dynamic map it was possible to either see all POIs or no POIs and I didn't find it problematic. ϒpsilon (talk) 17:44, 10 June 2016 (UTC)
  • @Matroc: the parameter is already there - show=... Please help with updating the docs. --Yurik (talk) 02:07, 12 June 2016 (UTC)
  • @Yurik: - I tested {{mapframe}} with parameter "show=see,do,city" and the result was only those 3 groups will show on a map and in layers dropdown - if you do not have a "show=" parameter in {{mapframe}} then the default list appears -- will leave a note in Template : mapframe talk page for this to be added when things quiet down a bit??? (nice to be aware of) -- Matroc (talk) 04:38, 12 June 2016 (UTC)
  • Yes Done 169 pages with script errors - Lua error in Module:Map at line 89: Polygon's first and last points must be the same. (coordinates issue) -- Matroc (talk) 15:22, 10 June 2016 (UTC)
  • I suspect this was due to most mapmasks having non-standard coordinates. See my answer above. I removed the verification, so all of them should be gone. --Yurik (talk) 15:38, 10 June 2016 (UTC)
  • P.S. There were tons of bad markers with trailing commas. I fixed them. --Yurik (talk) 02:07, 12 June 2016 (UTC)
  • Yes Done Some of the problems noted above can be resolved using <mapframe> and <maplink> directly. I see the process and issues of trying to pack (program) the functionality of these 2 into existing templates (which is probably preferable) than having to learn the Kartographer extension outright. -- Matroc (talk) 17:14, 10 June 2016 (UTC)
  • Agree, that's what i have been doing. Thanks for the note. --Yurik (talk) 02:07, 12 June 2016 (UTC)
  • Yes Done Itineraries are no longer numbered correctly. Previously a route would list POI in sequential numbers irrespective of type of listing. It now creates number sequences for each listing type. See for example Rheinsteig and Wales Coast Path. Not as easy to read. --Traveler100 (talk) 12:30, 10 June 2016 (UTC)
  • Thanks, should be relatively easy to fix with an extra param to use the same numbering group. I will have to think how to change the templates for that. --Yurik (talk) 15:47, 10 June 2016 (UTC)
    • Might also consider adding color as an extra param as well. -- Matroc (talk) 16:19, 10 June 2016 (UTC)
      • I see you have added a counter parameter to listings. This is not going to work. I add a new listing in the middle of a route with 100 POIs, how many editors are going to manually edit all the existing listing to keep it sequential. This experiment that has been made active before fully testing has broken the listing numbering system of itineraries. --Traveler100 (talk) 14:18, 12 June 2016 (UTC)
        • Traveler100, you misunderstood the meaning of the word "counter". This is the "name" of the counter, not the "value". The new maps can do counting just fine on its own, but they need to know WHICH counter variable to use. So you can have multiple counters on a page. As long as all the items (see, go, listing, etc) have the same counter parameter, they will share the same sequence. In short, take a look at Rheinsteig. Itineraries are now done. --Yurik (talk) 14:47, 12 June 2016 (UTC)
          • Ok my misunderstanding, looks good, thanks. --Traveler100 (talk) 21:38, 12 June 2016 (UTC)
  • Yes Done A minor question (not a priority and may not be applicable for us) - listings and markers in general are numbered on an article page and show as such on a map .... in the future, will we also have the capability of outputing a letter (A-Z) (similar to using -letter in Kartographer. -- Matroc (talk) 01:35, 13 June 2016 (UTC)
  • Matroc, You already have that capability, exactly as you described -- with "-letter" or "-letter-<countername>" (same as with -number). Also, you can always just set it to the value you want, e.g. "x", or any number, e.g. "42". --Yurik (talk) 02:10, 13 June 2016 (UTC)
  • Yes, this is possible using <mapframe> or <maplink> directly -- what I was trying to ask: "Is there to be a parameter in {{listing}} (see,do,sleep,eat etc.) templates to accomplish this?" (perhaps a parameter "countertype=" with values of 'number' or 'letter' ).... Thanks! Matroc (talk) 03:17, 14 June 2016 (UTC)
From Buffalo/West Side. This is not 300x650px!
From Historic Churches of Buffalo's East Side. What's the deal with the dead space on the left?
  • Yes Done mapframe had broken width/height. Original reports:
  • Trans-Siberian Railway#Go. In addition to what has been mentioned above, the whole map is split in half, both the GPX tracks and POIs are gone on the map, and the originally red markers in the text are now pink. ϒpsilon (talk) 12:49, 10 June 2016 (UTC)
  • The split map seems to be a problem related to the width/height parameters: the box around the map uses them, but the map in the box ignores them. This is also problematic when the width is so small that the control buttons on the left side get hidden: {{Mapframe|59.32502|18.07083|zoom=14|height=370|width=320|layer=|staticmap=|align=|name=}} Xsobev (talk) 14:43, 10 June 2016 (UTC)
  • @Ypsilon:, @Xsobev: I will look at width/height. The labels are missing because they have type=color, e.g. type=blue, and do not fall into one of the predefined groups: mask,around,buy,city,do,drink,eat,go,listing,other,see,sleep,vicinity,view. We could reduce the number of groups to make it easier to show in the layers picker, and simply add all others to "other" group. Would that work? Which groups do you think should stay? --Yurik (talk) 15:45, 10 June 2016 (UTC)
  • @Yurik: I can confirm that width parameter of mapframe now works. Thanks a lot for fixing this. Xsobev (talk) 13:47, 17 June 2016 (UTC)
  • Pinging Yurik. I'm not sure if this issue has already been brought up, but it looks like there are some bugs when it comes to mapframes with custom dimensions. See screenshots at right. -- AndreCarrotflower (talk) 01:29, 13 June 2016 (UTC)
  • AndreCarrotflower This seems to be an issue with the {{mapframe}}, not the Kartographer. Seems like the width/height are not being passed to Kartographer. Investingating... --Yurik (talk) 02:21, 13 June 2016 (UTC)
  • Yes Done Map images (photos) are no longer displayed when one clicks on an icon. –StellarD (talk) 17:56, 10 June 2016 (UTC)
  • @StellarD: could you give a link to a page with the problem? Thanks --20:31, 10 June 2016 (UTC)
  • Valencia has many map images, none of them now visible, even though they are still shown in the listing editor. –StellarD (talk) 20:46, 10 June 2016 (UTC)
  • @StellarD:@Traveler100: image support is done, please verify they are the right size. The "description" field could be any wiki markup. --Yurik (talk) 03:52, 13 June 2016 (UTC)
  • @Yurik: Out of several dozen map images for Valencia, three only now appear: those for the bus station and the two train stations. The map image for Estació de València Nord is the correct size; the other two are too large. –StellarD (talk) 09:03, 13 June 2016 (UTC)
  • Correction: when one clicks on the map icon in the upper right and opens the map in a new tab, the map images do appear and are the correct size. When clicking on the icons within the mapframe on the article page, the map images do not appear (except for the three mentioned above, two of which are sized incorrectly). –StellarD (talk) 09:56, 13 June 2016 (UTC)
@Yurik:, I think it is not completely done yet. Most of the images have the right size, but the red marker #1 (train station) in Valencia displays a much smaller image (not 300px). I see the same problem in other articles, where some images are smaller and some are bigger. Why? --Alexander (talk) 20:35, 13 June 2016 (UTC)
  • Yes Done layers - different layers should be lined up on the left - now they are ragged left ... Matroc (talk) 03:03, 9 June 2016 (UTC)
  • Yes Done layers - scrollbar not working - or present ... -- Matroc (talk) 03:03, 9 June 2016 (UTC)
  • Yes Done groups - in layers - is there a way not to have a select box for a group if that group does not have any any markers on the map? -- Matroc (talk) 03:31, 9 June 2016 (UTC)
  • Yes Done multiple {{mapframe}}s are now allowed on the same page. --Yurik (talk) 15:37, 16 June 2016 (UTC)
  • @Yurik: - that is great! -- now can create extra maps with using the show parameter for different sections etc. -- Matroc (talk) 00:28, 17 June 2016 (UTC)
  • Yes Done Yurik, and one more thing, which is really strange. Mapframe behaves in a very weird way when placed inside a div environment. Check here, Открыть карту. Same bug happens when I remove the wrap/unwrap part but keep any kind of div around the mapframe command. --Alexander (talk) 20:22, 13 June 2016 (UTC)
  • Tracked in phab:T137815
  • Was seeing similar issue as I had a mapframe etc. within a collapsible div... Evidently some change has occurred fixing the issue - perhaps a .css or javascript refresh was added after the map is opened to insure height and width etc... I tried Atsirlin's Открыть карту (open map) and I could see it working - it also seems to do a (slight pause) refresh - just a passing note -- Matroc (talk) 00:59, 17 June 2016 (UTC)
  • Merged and already live. JGirault (WMF) (talk) 22:29, 17 June 2016 (UTC)

GPX discussion[edit]

  • Could you explain what these template do? I am a bit confused. Or point to a doc. Thanks! --Yurik (talk) 03:40, 9 June 2016 (UTC)
    • @Yurik: The template is used to add a boundary or track to a map. There is some documentation of the process at Wikivoyage:How to use dynamic maps#Adding boundaries and tracks. -- Ryan • (talk) • 04:09, 9 June 2016 (UTC)
      • @Wrh2:, I played with them a bit. I seriously doubt that we would want to invest into full GPX support at this point simply because I think it can be easily converted to GeoJson and hosted right here on the Wiki. See on the right. Yurik (talk) 04:59, 9 June 2016 (UTC) P.S. Btw, that GPX file contains an error it seems - it has 3 segments, but the first two only contain one point each, making it impossible to draw a line. I removed them. Also I used an online conversion tool and some simple regex to get this. Yurik (talk) 05:15, 9 June 2016 (UTC)
  • How do you switch on the GPX plot for the article? --Traveler100 (talk) 12:36, 10 June 2016 (UTC)
GPX routes no longer visible on the in page map style and option not available on the map you get when you click on a listing number icon. --Traveler100 (talk) 21:44, 10 June 2016 (UTC)
  • @Traveler100: Yes, GPX is broken at the moment. I could try to implement a GPX parser in Lua, but it might take considerable efforts, and I think it's a dead end technology - geojson has much more descriptive language for this data, so I think we should migrate to it (see an example above). --Yurik (talk) 02:07, 12 June 2016 (UTC)
So what is involved in migrating from GPX format. Not there are many tools to generate GPX and a number of web site offering such data. --Traveler100 (talk) 13:57, 12 June 2016 (UTC)
Traveler100, depends on how many there are. If English WV is the only wiki that uses them, I see there are about 20-30 of them, might not be worth writing an elaborate script (will take much longer, and can only be done by a developer, thus preventing that developer from doing something that community cannot do easily). I would suggest converting the data using this tool (make sure you select GPX in the dropdown), and copy/pasting the resulting geojson into one big wiki page somewhere, wrapping each geojson in <mapframe>. This way everyone can look at them easily, and move them to the needed artiles (or make templates out of them). Eventually I hope we will have a proper geojson storage on commons. --Yurik (talk) 14:59, 12 June 2016 (UTC)
P.S. Seems there are over 70 GPXs on enwiki alone, I will try to migrate myself. --Yurik (talk) 19:15, 12 June 2016 (UTC)
  • Semi-done - all data has been converted, see User:Yurik/Sandbox/Gpx1 and User:Yurik/Sandbox/Gpx2. The task is tracked at phab:T137677. I suspect some of them were exported from OSM and stored as a page, which we shouldn't do - instead maps service should provide a way to export that data on the fly into the map that needs it. See phab:T134084 - a service to get an outline of a city, etc. --Yurik (talk) 01:01, 13 June 2016 (UTC)

General map questions[edit]

  • Yurik, I need your comment on a related issue: this set of coordinates is geojson, isn't it? How can I integrate it into the new mapframe technology? Note that same boundaries will be used on multiple pages, so we need a way to store the boundaries somewhere, not on the page itself, as {{mapmask}} is currently doing. I believe that this requires some tweaks of Module:Map, but I am unable to do this myself (and I have no idea what you had in mind when writing Module:Map in the way it is written). --Alexander (talk) 13:49, 13 June 2016 (UTC)
  • Alexander, yes, they look like geojson coordinates, and in theory can easily added to the mapframe/maplink by simply doing a search/replace into a 59.4318956570169,24.736855030059814|59.43198295738759,24.737563133239746|... sequence (notice that lat/long order is reversed). Then the data can be used as {{mapframe|geotag=Polygon|data=values|59.43...}}. In the long run, my goal is to enable geojson storage on commons, similar to the tabular storage (phab:T120452). Those pages will store raw geojson, and will be accessible from maps (or Lua) everywhere (i already have it working on my machine). I wouldn't want geojson to be stored as wiki markup - not stable, breaks in many ways, cannot be easily previewed, and many other issues. This Wednesday there will be an RFC discussion about the tabular data, but most of the technology is the same. --Yurik (talk) 18:13, 13 June 2016 (UTC)

Styling <maplink>[edit]

  • The style of the squares with numbers in the text is different - is there a reason why this was changed? Thanks again for all your work. Xsobev (talk) 17:23, 9 June 2016 (UTC)
  • @Xsobev:, I thought our links in text were exactly the same style as before. What changes and on which pages do you see? Thanks! --Yurik (talk) 22:25, 9 June 2016 (UTC)
  • You can see the difference if you compare an older WV page on archive.org with any current page (the changes are not page-specific). The main difference I could see is the grey border and the larger font size in the new version. In the old version, the border has the same color as the background of the box, and font size seems to be set to 0.85em. Obviously, this has low priority. Xsobev (talk)
Xsobev, this can be changed in Common.css, as shown here. You can find suitable parameters by playing with the code in User:Xsobev/commons.css. Then I will copy it to Mediawiki:Common.css, in order to apply this style globally. --Alexander (talk) 19:50, 13 June 2016 (UTC)
  • Yurik, I am not sure what the outcome of phab:T136260 is. Your Module:Map has no style= parameter. Does it mean that we are not supposed to pass any style information to maplink, or how should it work? It would be awesome to adjust the in-text map marker using standard CSS styles. Note also that the current style of map markers is very different from what was used before. --Alexander (talk) 10:19, 13 June 2016 (UTC)
  • Alexander, <maplink> uses mw-kartographer-autostyled CSS class for all automatic links. I thought it was identical to how it used to be, but lets configure it in Common.css to the way it should look - I think someone else also commented about it above. (You can try it in your own css user file until you like it, tell me how it should be changed) I do not want to introduce "style=" attribute (mediawiki plans to remove it outright in other places), but maplink/mapframe do support "class=" parameter so that styling can be consistently controlled with the CSS. --Yurik (talk) 18:26, 13 June 2016 (UTC)
See here for the CSS style optimized for Russian Wikivoyage. Thanks! --Alexander (talk) 19:50, 13 June 2016 (UTC)

@Xsobev: @Atsirlin: I updated the style for this wiki based on the above. Is it acceptable? If there will be no comments, i will mark this as done. --Yurik (talk) 19:56, 15 June 2016 (UTC)

  • @Yurik: The style of the marker boxes is almost the same again. The only missing part is a 1px border in the same color as the background of the box, for example: "border: 1px solid forestgreen" for the general green "listings" type marker. Old examples of marker styles can be seen here for example. Thanks a lot for your time. Xsobev (talk) 14:02, 17 June 2016 (UTC)
  • Update: I spoke with our other engineers and our UI specialist, and it seems we need to slightly adjust these links. They might be okayish from the design perspective for desktop, but they may need to be adjusted for the mobile - they may be too small for the touch screen. I propose that we establish guidelines for these markers, and create a set of predefined classes that are global to all Wikivoyages (part of the maps code), and appear good on desktop and mobile. The community will then establish a set of additional classes, such as "kartographer-link-see" or "...-eat". Templates like {{see}} and {{eat}} will add corresponding classes. The classes will only modify the background color, and won't touch any other aspects. This allows us not to hardcode the color of the link, but instead use a much better CSS system, while also maintaining good UI and cross-language consistency. Thoughts? --Yurik (talk) 00:02, 16 June 2016 (UTC)
  • Does this then force wikivoyage to only use templates in order to create links/maps? Is the use of <mapframe> and <maplink> to be avoided when they may be used for some condition that the templates don't provide for (such as creation a different group, different color other than the default color for type other, or even the use of various marker icons)? Or will the changes in maps code apply to both situations. Just wondering! -- Matroc (talk) 01:11, 16 June 2016 (UTC)
  • @Matroc: well, its not forcing anything - because you can still have <maplink class="my-class-name" .../>. But templates make it more consistent. After all, the backend code only affects the <maplink> and <mapframe> tags, not anything done in templates or modules. That said, I think it is better to use classes defined in MediaWiki:Common.css - like create a maplink-eat (or whatever other name community wants) class. This provides for consistency across pages. --Yurik (talk) 01:21, 16 June 2016 (UTC)
  • I checked the mobile version and I don't see any problems with the markers. Do engineers want to make them bigger, or what?
From previous experience we know that getting something decided across all language versions of Wikivoyage is next to impossible, so I would at least keep the option of CSS customization in the same way as it works now. If someone thinks that defaults should be different, well, let's see how these new defaults look like, and whether they fit into Wikivoyage articles. --Alexander (talk) 07:46, 16 June 2016 (UTC)

Questions from Developers[edit]

I agree that it is redundant. --Alexander (talk) 20:09, 13 June 2016 (UTC)
Category:Has_mapframeis not redundant, is used in statistics and status pages. Also useful when using boolean cat scan such as which articles in a country do or do not have map frames. As for Category:Pages with maps, not sure what this is saying, where is it generated? --Traveler100 (talk) 09:50, 14 June 2016 (UTC)
Traveler100, Category:Pages with maps is a Special tracking category, automatically populated whenever you have a <mapframe> or <maplink> on a page. How is that different from the Category:Has_mapframe, which gets populated by the {{mapframe}}? If someone inserts a map via some other method, like directly using <mapframe>, it won't be in the old category, but it will still show up in the automatic one. Plus there is a page to track broken maps (something that you cannot do from wiki markup). --Yurik (talk) 12:59, 14 June 2016 (UTC)
Hi @Yurik:, I think you just explained it yourself, Category:Has_mapframe is a subset of Category:Pages with maps, which is indicated by 2000+ pages in one category and 7000+ pages in the other. Whether a maplink is sufficient, since it opens up a full screen map (not a big fan actually), or that a mapframe should be inserted into articles to make maps more obvious could be further discussed. -- torty3 (talk) 09:20, 15 June 2016 (UTC)
Or rather, I think map links are great for mobile phones, but not so much for desktop experiences. And the other way around for mapframes. Nice to see the progress on everything though, and thanks for that. -- torty3 (talk) 09:24, 15 June 2016 (UTC)
@torty3: that was my point - if you simply want to know "what links to the mapframe template", use this search - special page, if you want to find all maps, you can use the automatic tracking category. If you want two tracking categories - one for maps and one for links - create a task, and we can discuss it. But it makes no sense to me to have a category that duplicates "what links here". WRT full screen on link - that was the behaviour before - we simply made it much faster, more stable, and with some new features. If you think link click should do someting else, make a proposal and lets discuss. --Yurik (talk) 13:20, 15 June 2016 (UTC)
@Yurik:, the key is equivalent functionality. Perhaps if WhatLinksHere had an actual count and ability to be used in a tool such as CatScan, yet right now it does not. I'm not sure why it was decided not to have two different categories since they aren't the same in the first place. The speed and stability is definitely very much appreciated, but again opening full-screen maps is another use case that doesn't have equivalent functionality. Maplinks are not actually links that can be opened in a different tab/window. If I want to have the wiki page on one window and the map on another (and I didn't realise how much I used it in this manner), I have to do it in a roundabout fashion. I guess it's fairly minor in the scheme of things, but still irksome to me. -- torty3 (talk) 15:34, 15 June 2016 (UTC)
@Torty3: yes, the ctrl+click has been asked before - see tracked tasks. --Yurik (talk) 18:30, 15 June 2016 (UTC)
  • if the reason why it is needed can be solved with a better solution then sure we can discuss an alternative methods. It was initially introduced to provide readers with a POI map for a section of a long itinerary, for example in Trans-Canada Highway. We could not work out a method of displaying more than one map on a page at the same time. If you can work out a way to display more than one map in an article that would be an improvement. --Traveler100 (talk) 04:49, 16 June 2016 (UTC)
  • I migrated some of the pages that use {{PoiMap2}} directly to use {{PoiMap2raw}}. This is not a good solution overall, so maybe its usage should be rethought? --Yurik (talk) 01:24, 16 June 2016 (UTC)

Marker/pushpin-related issues[edit]

  • Symbol shape. The lack of distinctive shapes for each type of listing makes it more difficult interpret what the POI is unless you are very familiar with color scheme. --Traveler100 (talk) 12:33, 10 June 2016 (UTC)
  • Not having different shapes for different types of listings is a step backwards. --Traveler100 (talk) 21:52, 10 June 2016 (UTC)
  • Yep, its a TODO - see phab:T131618. I will try to get it soonish. Any help is greatly appreciated (like designing the icon in SVG, per bug comments) --Yurik (talk) 02:07, 12 June 2016 (UTC)
  • Update: we could use some help on this one (no image designers on the team) - please create an SVG image for each of the needed icons just like these two files: [107] and [108]. The second one is for the shadow and an outline. Do not change the colors of the SVG - they are changed dynamically. Also, unless really needed, keep the same position of the images as in the examples. Please license the images under CC0. Thanks! --Yurik (talk) 18:26, 16 June 2016 (UTC)
  • This turns out slightly more complicated than anticipated. Apparently "pin" is hardcoded into the map, and might require some additional investigation. We are still investigating this one. --Yurik (talk) 10:57, 21 June 2016 (UTC)
  • @Yurik: When requesting a marker with a different style, for example "circle" instead of "pin", then the parameter gets accepted. The error seems to be returned only because there is no circle*.png image. So at least the makizushi code doesn't seem to contain any hardcoded values. Could you please give more details? Xsobev (talk) 13:50, 13 July 2016 (UTC)
  • Bug report: There seems to be an area below each pushpin (with a similar width & height as the pushpin itself) which reacts to a single click in the same was as if clicking on the pushpin, which means it shows the name of the listing. Expected behaviour: The label should only be shown if clicked on the pushpin, but not on its surrounding area. Xsobev (talk) 12:12, 20 June 2016 (UTC)
    • @Yurik: Ok, I found the answer to why this area below the pushpin exists on github: The pointy bit of the pushpin has to be the centre of the image, so that it is positioned correctly on the map, which seems like an unfortunate limitation. Luckily, if we can use the marker symbols previously used on wikivoyage (see example), where the centre of the image is also where the marker should be placed, then the empty area below the marker won't be necessary anymore. Xsobev (talk) 13:42, 13 July 2016 (UTC)

Fit map to all markers[edit]

  • In the previous mapframe version, there was a button ("Map center - all markers") which allowed to zoom out & center the map so that all markers of a page are visible in the mapframe (with one click). Would it be possible to add this feature in the new version? Thanks a lot. Xsobev (talk) 17:23, 9 June 2016 (UTC)
  • If you look at the old map, for example here for Stockholm, you can see a button with four arrows (with a tooltip that says "Map center <-> all markers") in the top-left corner (in the new map this button is now used to show the map in full screen mode). If you click it once, the map zooms out so that all makers on that map are visible. If you click it again, the zoom level goes back to where it was before. (Feel free, to copy this description to a new Phabricator ticket.) Xsobev (talk) 14:33, 10 June 2016 (UTC)
  • Cannot fit map to all markers. --Traveler100 (talk) 20:10, 23 June 2016 (UTC)

Other maps issues[edit]

  • I noticed that there are about 30 pages that use a color instead of the proper marker "type", for example California#See. Is that needed, or can we switch to named types? --Yurik (talk) 05:20, 10 June 2016 (UTC)
  • I would prefer to use named types everywhere - it will be confusing if someone decides to use the "eat" color scheme for "buy" listings, so rather than providing the ability to specify a color as a type value I think it would be better to add more types with distinct styles as needed. -- Ryan • (talk) • 15:28, 10 June 2016 (UTC)
  • There seems to be something weird about the numbering too. For instance, in United States National Parks, all POIs with a number larger than 99 are numbered 99, both on the map and in the article. ϒpsilon (talk) 07:27, 10 June 2016 (UTC)
  • This is a limitation of the labeling system - it can only create numbers 0..99 and letters A..Z, but in any color and 3 different sizes. Also for maps like that I think it makes sense to simply use some icon instead of numbering? Its not like anyone will be trying to locate a park number #42 on a map among 300 other markers. Also we could set different colors, one per state? --Yurik (talk) 15:32, 10 June 2016 (UTC)
  • I believe the numbers are needed as reference to numbered text on page... I believe marker doesn't have color or an icon option as parameters. -- Matroc (talk) 16:39, 10 June 2016 (UTC)
  • @Matroc: I really doubt anyone would look at a map with 500 markers, and try to find that index on the page. I think we should add all the relevant information about the mark into the mark itself - this way user can simply click on it and get a popup with everything. If you still insist on the numbers, lets differentiate numbers by some region colors (should be better than to pick a different color for each state) --Yurik (talk) 02:07, 12 June 2016 (UTC)
@Traveler100: I think Roman Empire map should be broken down into multiple maps - there is very little use to add all POIs to the same map while the actual item is far below on the page. Instead, I think it would be much better to have multiple maps, one for each region, with its own POIs. What do you think? --Yurik (talk) 10:02, 12 July 2016 (UTC)
You may have a good case for the Roman Empire article. But could you please point me in direction of documentation for the counter parameter. Made quick test at Roman Empire#England but does not achieve quite what I was expecting. Also still think numbers larger than 100 are going to be needed for long hiking trails. For example Wales Coast Path and Rheinsteig are still work in progress projects, listings are going to increase. --Traveler100 (talk) 11:07, 12 July 2016 (UTC)
@Traveler100: The main doc is at Kartographer help page (please help improving it). For WV, Module:Map has some docs, plus the {{listing}} & {{marker}}. More specifically, each listing has to be marked with the right group, plus the map itself should be set to only show that group. I think we will need to cleanup the marker & listing templates, because currently they accept the type, group, and show, arguments, but don't work too well with them. I will see what I can do in the next few days to clean it up. Or feel free to poke at it yourself. --Yurik (talk) 18:50, 12 July 2016 (UTC)
@Yurik: I started to write something, see User:Traveler100/map-listings-explained but having difficulty understanding how counter influences groups on the map or the symbol used for the poi. See comments at Template talk:Marker#using multiple counters. --Traveler100 (talk) 17:30, 14 July 2016 (UTC)
@Traveler100: from the <mapframe/maplink> perspective, counters and groups have no relation with each other. Any data marked with the same "group" value will be shown for all maps in that group, plus it will be shown whenever the group is listed in the "show" parameter.
{{marker}} sets two values that are used in the Module:map: marker-symbol=-number-{{{counter|{{{type|listing}}}}}} | group={{{type|listing}}}. The module does not modify either of these two params, it simply passes them to the <mapframe/maplink> tags. Also, I think it is a mistake to set any params in the {{marker}} because the module can pick up params from the template that uses {marker} - this way marker template could become much simpler, and templates like {{see}} and {{do}} can set all the needed arguments. --Yurik (talk) 18:40, 14 July 2016 (UTC)
sorry but that explanation has not helped. What do mean by "will be shown for all maps in that group"? Also where can you set the show parameter if you have other types or is this hardcoded? For example why is only the group listing being show in