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, use tags "eat" "see" e.g. and special icons shapes. -- 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 . 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 , , , 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 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 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

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

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 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 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 . 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? 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 . I am currently working on integration of gpx files. Here is a first example . Any number of tracks can be displayed. The tracks can be divided into track segments. Waypoints would also be possible . So you could already represent some. Gpx files can be easily stored as text files . - 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 , 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 . -- 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

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.

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

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 ...) . 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 and Melbourne . -- 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