Wikivoyage talk:Dynamic maps Expedition/Archive 2013

Integrate {{poi}} and {{listing}} as one template

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

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

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

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.
  • http://maps.wikivoyage-ev.org/w/artmap.php?lang=en
• 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.
  • Sabah on de: ... here you can see multiple hierarchies
  • Washington, D.C. on en: ... DotM and a star
  • and it's quarters
  • Kota Kinabalu on de:

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

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

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

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

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!

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

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

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

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

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

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

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

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

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!

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 A ▪ talk 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 A ▪ talk 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 A ▪ talk 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 A ▪ talk 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

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

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

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

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

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

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

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;
}

Done. The problem appears to be fixed. James A ▪ talk 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

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 A ▪ talk 13:26, 5 July 2013 (UTC)

GPX tracks

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

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 Template:Marker/sandbox.  -- torty3 (talk) 13:10, 5 August 2013 (UTC)

ShareMap.org - evaluation welcome

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

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

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?

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

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?

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

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

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

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 A ▪ talk 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

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

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

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

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"

• 1 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

• 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. 

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. Frank^e-mail_talk 14:44, 7 August 2013 (UTC)

Green flower for "Do", gray dot for unspecified listings

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. –Thatotherperson^talkcontribs 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.
Thatotherperson^talkcontribs 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. –Thatotherperson^talkcontribs 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. –Thatotherperson^talkcontribs 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? –Thatotherperson^talkcontribs 07:18, 15 February 2014 (UTC)

Mitigating the additional download times for readers

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. Frank^e-mail_talk 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. Frank^e-mail_talk 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. Frank^e-mail_talk 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

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

Performance test

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

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

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. Frank^e-mail_talk 15:22, 10 August 2013 (UTC)

Missing images and missing maps

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. Frank^e-mail_talk 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. Frank^e-mail_talk 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

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

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. Frank^e-mail_talk 16:30, 25 August 2013 (UTC)

OSM with style

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. Frank^e-mail_talk 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

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

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

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. Frank^e-mail_talk 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. Frank^e-mail_talk 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. Frank^e-mail_talk 16:36, 22 August 2013 (UTC)

This looks very good, danke sehr Joachim! PrinceGloria (talk) 17:55, 22 August 2013 (UTC)

Edit button

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

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

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

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. Frank^e-mail_talk 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?

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

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

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. Frank^email_talk 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. Frank^email_talk 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

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. Frank^email_talk 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

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?

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

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:

• Screen cast : Creating POI map for WikiVoyage with ShareMap

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:

• ShareMap Twitter Channel
• ShareMap on Wikimedia Commons

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

English in OSM maps

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

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?

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?

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)

Map of all destinations in a country, with labels

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

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)