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)[reply]

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)[reply]

This is pretty god damn awesome if you ask me :) --Stefan (sertmann) ^talk 08:40, 26 February 2013 (UTC)[reply]

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)[reply]

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)[reply]

What needs to be done to get our listings to generate POI directly? --Peter ^Talk 21:24, 28 February 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

That's very nice! --Nick (talk) 18:27, 23 March 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I think that makes perfect sense. Wikivoyage:Roadmap/Dynamic maps should be merged & redirected there. --Peter ^Talk 17:03, 28 March 2013 (UTC)[reply]

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)[reply]

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)[reply]

The Wikimedia Foundation updates the data dumps once each month.96.241.26.218 16:26, 27 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

No, you don't. Just click on the number, and you will see the name. --Alexander (talk) 13:21, 12 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Good work, Torty; I like the Wikivoyage-style. LtPowers (talk) 16:22, 14 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

By the way, the new Wikivoyage layer looks great ;) --Peter ^Talk 19:58, 15 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Proposal[edit]

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

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

--Peter ^Talk 17:43, 17 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

Oh right- I hadn't realised! Ignore that then; my support is unconditional! --Nick (talk) 18:27, 17 April 2013 (UTC)[reply]

Support - it is a necessary step. --Alexander (talk) 19:37, 17 April 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

How do we poke the bugzilla people about this? -- torty3 (talk) 16:49, 15 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

A Wikivoyage:Bugzilla Expedition, then? Anyone else? --Peter ^Talk 02:13, 16 May 2013 (UTC)[reply]

Tags to templates[edit]

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

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

VoyageMap widget[edit]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Can't we fill in latitudes progressively as we implement new dynamic maps? JamesA ^>talk 08:09, 2 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Joachim, you have been doing amazing work, and deserve a vacation ;) Have fun! --Peter ^Talk 15:33, 12 June 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Excellent! Can one make the map itself clickable instead of putting the link into the caption? --Alexander (talk) 10:27, 9 June 2013 (UTC)[reply]

That's really fantastic! This is definitely something worth rolling out site-wide if we can! --Nick ^talk 10:40, 9 June 2013 (UTC)[reply]

(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)[reply]

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)[reply]

What tiny empty square is that? • • • Peter (Southwood) ^(talk): 15:09, 9 June 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

For continuous auto-numbering by article I already have a new PoiMap2 version [21]. -- Mey2008 (talk) 13:09, 10 June 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

That only adds to the argument of keeping individual numbering per each section. PrinceGloria (talk) 15:03, 14 June 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

It sure did! Works and looks brilliantly, thank you Nicholas and everybody involved! PrinceGloria (talk) 15:35, 11 June 2013 (UTC)[reply]

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

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

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

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

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

Stage 1: Limited testing[edit]

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

1. Copy code from Template:Mapframe/MapFrame.js to Mediawiki:MapFrame.js (also remove pre tags)
2. Add importScript('MediaWiki:MapFrame.js'); to Mediawiki:Common.js
3. Add the following code to Mediawiki:Common.css

/*** counter for mapping listings ***/ .page-Wheaton span.listing-map:before {     content: counter(mapnumber);     counter-increment: mapnumber; }  .page-Singapore_Chinatown span.listing-map:before {     content: counter(mapnumber);     counter-increment: mapnumber; } 

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

Stage 2: Site-wide[edit]

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

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

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

Stage 3: Full featured maps[edit]

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

Comments[edit]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Maplinks[edit]

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

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)[reply]

Cool, how do you do that? -- torty3 (talk) 13:23, 4 July 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

GPX tracks[edit]

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

Nice! How did you go about generating the GPX tracks? --Peter ^Talk 08:14, 9 July 2013 (UTC)[reply]

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)[reply]

Very cool! --Peter ^Talk 05:45, 10 July 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Icon sizing[edit]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I agree. Pashley (talk) 19:51, 4 July 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Done (use GeoMap). -- Joachim Mey2008 (talk) 16:52, 23 July 2013 (UTC)[reply]

Bravo & thanks. Pashley (talk) 16:49, 28 July 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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.)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Automatic separate numbering[edit]

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

Ok that's excellent, I will go ch