Wikivoyage talk:Dynamic maps Expedition/Archive 2014-2015

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

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

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

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

Step one, which I think is largely done, is to get geo tags into articles so we automatically get a dynamic map link up at the top. I often check those on various articles I'm editing; I occasionally find bad co-ordinates and quite often incorrect zoom. I'd say the first priority is to make sure the geo tags are all present and correct. We might also discuss ways to make the link more obvious; I doubt that readers unfamiliar with the site are likely to notice the current icons.

As for adding other dynamic maps, it sounds like a good idea though I am very much of the opinion that the above comes first.

The only other concerns I'd have are the language problem (#Shanghai map and #English in OSM maps above) and whether metro or other public transit routes can be shown. Pashley (talk) 18:12, 4 January 2014 (UTC)

Making a considered decision to add a carefully oriented dynamic map to a specific article is one thing, but adding them systematically across the board is a more difficult question. I remain concerned that large-scale systematic addition of dynamic maps will depress interest in proper mapmaking, as articles will cease to appear "incomplete" in the absence of a good Wikivoyage-style travel map. I fear that would detriment the site in the long-term. Powers ^(talk) 18:45, 4 January 2014 (UTC)

@Pashley: The layer N = Traffic line network already displayed all subways, commuter trains, bus lines etc (all public transport). Including line numbers and names of the stops. The data must only be contained in OSM. -- Joachim Mey2008 (talk) 14:23, 5 January 2014 (UTC)

@all: Static maps can be updated only by a few "specialists". This has a negative effect to the article text. I have previously drawn many static maps. After five years, 50% of the hotels, restaurants and bars were changed. No one dared the complicated updating of static maps. The articles were therefore not updated and remained at the level as five years ago. That was the main reason why I programmed the dynamic map. Those automatically correspond with the current article text. This aspect should also be noted. - Joachim Mey2008 (talk) 14:57, 5 January 2014 (UTC)

Given the concerns of Powers and Pashley, would it be acceptable to add a "Stage 3" to update Wikivoyage:Dynamic maps Expedition#Test to reflect that a broader manual deployment of dynamic maps (and not an automated large-scale deployment) is now acceptable, leaving in place the existing guidance about adding missing {{geo}} coordinates where needed? I am envisioning two bullet points, and the same "known issues" as stage two:

• Manually add maps to articles where an editor feels that a dynamic map would be beneficial and would not be adversely affected by known issues using {{mapframe}}. Guidelines for adding a dynamic map:
  1. Only add dynamic maps to articles at the lowest level of the article hierarchy (city or district).
  2. Add the dynamic map to the top of the "Get around" section.
  3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
  4. Use the default map size (width/height). Zoom should be modified as appropriate.
  5. Do not add more than one dynamic map without discussion on the article talk page.
• Update {{listing}} tags with appropriate lat/long coordinates as outlined in Wikivoyage:Dynamic maps Expedition#Sub-expedition: Fill all the latitudes!.

I believe that would provide some implementation guidelines that would let us formally move ahead with these maps while addressing the concerns above. -- Ryan • (talk) • 17:53, 5 January 2014 (UTC)

That seems like a reasonable compromise. Powers ^(talk) 19:25, 5 January 2014 (UTC)

Adding dynamic maps only where there's no static map, only once co-ordinates exist in most individual listings would be reasonable. Certainly there's no use in a map with only one POI, or none at all. Requiring the map be in "get around" may be awkward if the article already has photos in or near that section which would need to be moved to make space. It might be worth looking at fr:modèle:Info Ville (a quickbar-like template for cities which has the map, a photo of the town and info such as region, population/area, telephone prefix and postal code); fr:Lac-Mégantic has an example of this. The default map scale might not work well for huge rural regions (like Anticosti), not sure if this was what you meant by "map size". Leaving regions to be dealt with separately is reasonable as the points of interest in a region are cities, not individual listing venues. K7L (talk) 19:22, 5 January 2014 (UTC)

I've clarified the "map size" comment (width/height should use the default, zoom can be whatever works best). As to articles with only one POI, I still think the map is useful as it shows roads and nearby cities, but if others feel that maps should not be used unless there are multiple POIs then we should discuss. Regarding "Get around", I actually prefer putting the map at the top of "Get in", but think we should standardize if possible and "Get around" had been suggested previously. As to quickbars, general consensus has been against them in the past, so it may be better to save that discussion for another time and just focus on a basic map rollout for now. -- Ryan • (talk) • 19:33, 5 January 2014 (UTC)

The appropriate location for the map depends on the specifics of each article. Some destinations have more complex Get In information than Get Around information; others are the other way around. In addition to the obvious layout issues resulting from these differing section lengths, it also points out that sometimes the map is more needed for one purpose than for another. Powers ^(talk) 02:08, 6 January 2014 (UTC)

@LtPowers: is right in suggesting that map positioning is best left to independent editor judgement in each individual article. Default width (ie, unspecified - like thumbnail width) is best in many cases, but there are quite a few conurbations (and even countries like Chile) that are long and narrow and benefit greatly from having a larger height. Equally, "wide" areas may benefit from having a reduced height.

What's the reasoning behind suggesting "Do not add a dynamic map when a Wikivoyage-style static map is already present", please? --118.93.235.201 04:38, 6 January 2014 (UTC)

I believe that idea comes from Powers's assertion that "A good cartographer can beat a computer every day of the week and twice on Sundays". He is correct. However the amount a 'good cartographers' we have available is limited, and not all static maps are created to such a high standard, or current.

If I want to add a restaurant listing to an established article then there is no way I can gain ready access to the source of the original static map, and unrealistic that most contributors would know how to even if they had. With a dynamic map I just need to add the latitude and longitude to the listing and I'm done. Andrewssi2 (talk) 05:16, 6 January 2014 (UTC)

Likewise, the number of good writers we have available is also limited; does that mean we should begin relying on computers to generate prose for us as well? Powers ^(talk) 19:38, 6 January 2014 (UTC)

This is a case of User:LtPowers vs. the world. It is quite obvious he stands steadfast by his POV, and that everybody else does not share it. Let's move on, there really aren't many editors here, so wasting time on beating a dead horse is the last thing we should do. I keep deploying Dynamic Maps in articles and see no reason why we should refrain from doing so. Happy deploying, editing and finding latlongs! PrinceGloria (talk) 07:19, 7 January 2014 (UTC)

PS. There are always many considerations as to where to put the map in a specific article, but I believe it helps avoid unnecessary hangups and discussions to agree to have them at "Get around". Specific cases can always warrant an exception, this is not law, just a useful guideline.

PS2. Width and height should absolutely be left out to individual decisions though. They should serve the particular map best, every area has a characteristics and POI distribution. Even advising of "ideal" height/width would be unnecessairly confusing matters. The map should be legible and encompass the entire area of the article with all POIs, if possible, and this determines the height/width and zoom level.

I don't feel the counterpoint for having 'good editors' is fair. The technical bar to come on WV and start writing content is very low, regardless of one's ability with prose. Designing maps is a different kettle of fish altogether requiring good knowledge of A) Mapping software and B) Drawing software.

Even if you can use the software then you still can't easily obtain the original drawing files, meaning a new map would have be drawn each and every time (although SVG format may get around this). Andrewssi2 (talk) 08:41, 7 January 2014 (UTC)

Although I very much agree the esthetics of hand-drawn maps is much superior when done by an experienced mapmaker, I don't see how we could keep the destination article maps up-to-date. For that we should fully use the potential of dynamic maps. On region & country level the hand-drawn maps still have no competitor in dynamic maps and I believe this is where we should concentrate the mapmaking effort. Danapit (talk) 08:57, 7 January 2014 (UTC)

Agreed. This isn't an argument about the whether dynamic maps are inherently better than static or vice-versa. The dynamic maps are providing a good deal of value already to articles that have no forseeable prospect of getting a hand crafted static map, and some articles experiencing high amounts of listing updates also benefit from this new approach. Andrewssi2 (talk) 09:15, 7 January 2014 (UTC)

Yet again, my opinion on this site appears worthless. Lovely. Powers ^(talk) 18:50, 7 January 2014 (UTC)

Powers, the statements above were not against you, and I do not read anyone here inferring that your opinion as worthless. I certainly value your opinions. Andrewssi2 (talk) 04:24, 9 January 2014 (UTC)

I don't know how else to interpret "This is a case of User:LtPowers vs. the world. ... Let's move on,..." Powers ^(talk) 20:02, 9 January 2014 (UTC)

OK, I'd agree that it rather dismissive. Please bear in mind that PrinceGloria does use her distinctive style quite widely and I choose not to take it personally myself. Andrewssi2 (talk) 00:58, 10 January 2014 (UTC)

I certainly got my fair share now that I got to be referred to as "her". Thank you so much, gentlemen (presumably). PrinceGloria (talk) 15:42, 10 January 2014 (UTC)

Sorry PrinceGloria. I had assumed (incorrectly?) your gender purely based on the second part of your name. Andrewssi2 (talk) 15:18, 12 January 2014 (UTC)

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

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

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

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

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

I've added Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment to reflect the proposal and discussion above, making clear that the top of "Get around" is the preferred location, and that the default size is preferred, but that if there are specific reasons for using a different size or location then that is acceptable, provided the reasoning is explained. -- Ryan • (talk) • 03:39, 9 January 2014 (UTC)

I removed the part you added that read "Do not add a dynamic map when a Wikivoyage-style static map is already present." since the consensus immediately above seems clearly against that and no rationale for this has yet been advanced despite continued requests. --118.93.244.91 04:04, 9 January 2014 (UTC)

@Wrh2: why are you edit warring about this?

Nobody that I have read above is suggesting removing Static maps when a Dynamic map is added, but I fail utterly to see where anybody (other than you in a faux "summary") has ever proposed that Dynamic maps should be removed when added to an article that already contains a Static map. Each, as many have pointed out, have their own specific advantages and one type should neither mandate nor prohibit the dployment of the other. Even Powers wrote above "Personally speaking, I would never remove a good hand-crafted static map in favor of a dynamic, auto-gen map, but I might do the opposite, depending on the quality of the maps involved. Sometimes keeping both might be warranted" at 22:04, 25 November 2013 (UTC).

--118.93nzp (talk) 05:52, 9 January 2014 (UTC)

I think that we need to be clear that the instruction only refers to those static maps that were created for WV. There are also static maps that were originally created for WP that might be good candidates for replacement. For example Eriskay has a static map that I added last year before dynamic maps were available, and I think that this would be best replaced with a dynamic one. On the other hand, Harris has a static map which although not good, does make an important point clear; in this case I would like to add a dynamic map to supplement this. Both of these maps were originally originally created for WP, but were added on the basis that an inferior map was better than no map. AlasdairW (talk) 23:22, 9 January 2014 (UTC)

The current guidance states "Do not add a dynamic map when a Wikivoyage-style static map is already present" since we are far from any agreement or plan for replacing existing Wikivoyage-style maps. However, for static maps that weren't specifically created for Wikivoyage in accordance with the guidance on Wikivoyage:How to draw a map I think it is up to the individual making the replacement whether the existing static map should be replaced (or supplemented) by a dynamic map. -- Ryan • (talk) • 00:08, 10 January 2014 (UTC)

I created a 'Wikivoyage stlye' map for the Haeundae article, however I came to the conclusion that owing to the density of many POI's it should be supplemented by a dynamic map. I think this works well, although it doesn't fit with the guidance "Do not add a dynamic map when a Wikivoyage-style static map is already present." Andrewssi2 (talk) 00:58, 10 January 2014 (UTC)

I'll leave it to others to have that battle as the initial "stage 3" proposal was meant to provide a path forward for deploying dynamic maps in more articles without upsetting individuals who have expressed their preference for static maps, and it survived a week's worth of discussion without too much dissent. Eventually we'll have to deal with that issue, but for now my hope was that we could just come to some agreement on what the next step should be. -- Ryan • (talk) • 02:27, 10 January 2014 (UTC)

OK, now I'm really miffed.

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

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

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

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

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

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

I guess we need to bother Joachim for the billionth time... FYI to the fixer; on Mac the dynamic maps do show up with Firefox version 26.0. ϒpsilon (talk) 10:18, 20 January 2014 (UTC)

It works on Internet Explorer for Windows Phone 8 and on Google Chrome for the Samsung Galaxy Tab 2 tablet.

It also works fine under Windows 8.0 with Google Chrome 32.0.1700.76

The issue seems restricted to Firefox. Has anyone else tried the dynamic maps with Firefox for Windows? Andrewssi2 (talk) 10:32, 20 January 2014 (UTC)

I am using Firefox 26.0 under Windows right now and have no problems with displaying Dynamic Maps. Neither do I with Firefox on MacOS. PrinceGloria (talk) 10:37, 20 January 2014 (UTC)

Win7 + Firefox 26.0 = no problem. Danapit (talk) 10:39, 20 January 2014 (UTC)

Hmm... Andrew is AFAIK currently based in China, where the connections can be insecure now and then; you can probably guess what I mean. ϒpsilon (talk) 10:53, 20 January 2014 (UTC)

@Andrewssi2: You may have enabled SSL scanning in your security software such as ESET or BitDefender. Try to disable this option. (compare mozilla support). Please read the section "The certificate is not trusted because no issuer chain was provided". I hope this helps. - I have also successfully tested many browsers / operating system combinations. -- Joachim Mey2008 (talk) 11:11, 20 January 2014 (UTC)

I just restarted and exact same issue. I will have a look into the trouble shooting later. Interesting since this configuration worked yesterday. And yes, I 'may' have a 'great firewall' issue in China :) Andrewssi2 (talk) 11:14, 20 January 2014 (UTC)

OK, slowly getting to the bottom of this. I just tried my work laptop (Windows 8.0, FireFox 26) and it works fine!

I actually installed Windows 8.1 on my personal laptop on Sunday, and it 'might' just be the combination of Windows 8.1 and FireFox 26. (I guess a lot of MS security fixes that affect FireFox in some way) I'll keep digging. Andrewssi2 (talk) 11:42, 20 January 2014 (UTC)

It does seem to be a Windows 8.1 issue. https://support.mozilla.org/en-US/questions/983227

The suggested fix is to import the certificate directly. Does anyone know where I can get the wmflabs certificate in Base64 text?

Otherwise I just use Internet Explorer in the meantime :) Andrewssi2 (talk) 12:01, 20 January 2014 (UTC)

I'm using Chrome on Windows 8.1 and I'm seeing this same issue. Powers ^(talk) 18:38, 20 January 2014 (UTC)

Hi Joachim, is there anyway we can get someone to look at the certificate on wmflabs in order to ensure there are no issues on that side?

I believe Windows 8.1 will become more prevalent during 2014, and many contributors (both experienced and new) may come to the conclusion that Dynamic Maps are broken. I don't think they are going to search this site to find this discussion or want to implement workarounds. Andrewssi2 (talk) 00:29, 21 January 2014 (UTC)

Sorry to bother the Dynamic map team again...

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

"Internal Server Error

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

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

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

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

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

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

Unfortunately, the same problem occurs more frequently. It was discussed right here. We use two servers. But for the mapframe-server we'll have to find more reliable replacement. - Joachim Mey2008 (talk) 17:49, 20 January 2014 (UTC)

I see. It's really a shame that the map system you've put a lot of effort in isn't available just because of some server malfunctioning :P. ϒpsilon (talk) 17:59, 20 January 2014 (UTC)

Did you send a mail again? Because now it shows up normally at least in User:Ypsilon/Milan. Yippie! ϒpsilon (talk) 18:04, 20 January 2014 (UTC)

I just wanted to send an email. But with my knowledge of English that always takes some times with google translate . -- Joachim Mey2008 (talk) 18:16, 20 January 2014 (UTC)

And now the error is back :(. And in the thread above LtPowers reports similar problems that Andrewssi2 had earlier today. Something is wrong – big time.

Schade dass torty3 jetzt nicht hier ist. Ich könnte vielleicht es versuchen den Mail zu übersetzen. ϒpsilon (talk) 19:06, 20 January 2014 (UTC)

And now it works normally again... ϒpsilon (talk) 20:19, 20 January 2014 (UTC)

To be fair, I think the certificate issue I have is an existing problem that simply hasn't been apparent because the operating system in question (Windows 8.1) has been available only recently. Andrewssi2 (talk) 00:54, 21 January 2014 (UTC)

Problems with mapframe

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

Many thanks for taking ownership of the problem Joachim

Just to ask the question.. have we considered just going directly to http://www.openstreetmap.org rather than go through http://maps.wikivoyage-ev.org/ ?

I realize such a change would not be trivial, although it seems our reliance on the wikivoyage-ev.org server is presenting a real risk to the dynamic maps initiative. Andrewssi2 (talk) 05:44, 21 January 2014 (UTC)

My understanding is that it is the server at tools.wmflabs.org that is problematical not maps.wikivoyage-ev.org, Andrew - or have you had problems with both Mapframe and the full screen dynamic map? --118.93nzp (talk) 06:10, 21 January 2014 (UTC)

Wikivoyage eV is a registered non-profit association in support of Wikivoyage. I do not see any risk for the project. - The application PoiMap2.php for map display is a short script that runs on that server. The WV.eV server (for full screen map) is highly reliable. Map tiles are not stored there. Tiles are already sourced directly from OSM or Mapquest. - Joachim Mey2008 (talk) 06:28, 21 January 2014 (UTC)

Actually, I am not familiar with the architecture of Dynamic Maps. I posed this question with the intent of discussing the architecture and how we can reach a reliable solution. Full screen maps do appear to work fine.

If the WV.eV server is reliable then how can we get better control of the component running on tools.wmflabs.org? It seems to me that we are dependent on one person volunteering to fix this script whenever they have time Andrewssi2 (talk) 06:33, 21 January 2014 (UTC)

The problem is not the script but the Tools-Server. They are running many applications at [1]. If one of these applications is faulty, the entire server fails - and often. We need for mapframe (HTTPS) a more reliable server. - For cost reasons, no HTTPS is possible on the WV.eV server. -- Joachim Mey2008 (talk) 06:43, 21 January 2014 (UTC)

And is there any discussion around moving 'to a more reliable server'? Andrewssi2 (talk) 06:56, 21 January 2014 (UTC)

Hi Joachim , is there a forum for this? I'm happy to discuss in German if it is hosted on a German community site. Andrewssi2 (talk) 00:36, 23 January 2014 (UTC)

I have found a way to greatly reduce the server load. This applies to dynamic maps with many markers. I think then the Tools-Server could be sufficient. I need to change something in the script. This will take about two weeks (due weekly update of the tools server). - I believe that User:Torty3 already discussed the need for a server change. A forum on this issue do not exist. I'm waiting for the return of User:Torty3 to this discussion. - Joachim Mey2008 (talk) 05:44, 23 January 2014 (UTC)

Thanks Joachim . I think WV can easily survive a couple of weeks without dynamic maps.

I assume however the Firefox/Windows 8.1 issue will not be resolved by this?

This is because the problem is down to the absence of a certificate on the map server? Andrewssi2 (talk) 10:48, 23 January 2014 (UTC)

About the topics of SSL/certificates/HTTPS I have no specialist knowledge and can not help. -- Joachim Mey2008 (talk) 05:20, 25 January 2014 (UTC)

So how can we progress? The issue currently only affects a minority of users (Chrome/Firefox under Windows 8.1 specifically) however what can we do when new updates are issued and more people are affected? Andrewssi2 (talk) 07:44, 25 January 2014 (UTC)

Dynamic map issue solved - can we turn back on?

I just took a look at this French WikiVoyage article:

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

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

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

We should wait for the latest script update. I hope Torty3 (the only admin) will do that in the next few days. He is unfortunately inactive for last six weeks. - The new version has reduced read and write accesses, and less load on the server. - Joachim Mey2008 (talk) 08:08, 29 January 2014 (UTC)

OK, but can you at least confirm that the Windows 8.1/Firefox/Chrome certificate issue is now resolved? Andrewssi2 (talk) 08:20, 29 January 2014 (UTC)

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

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

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

Yup, I am also seeing "Your browser sent a request that this server could not understand." in Firefox. (Windows 8.1) Andrewssi2 (talk) 12:26, 16 February 2014 (UTC)

The only admin for the mapframe server (https://tools.wmflabs.org/) is User:Torty3. But he is no longer active since December 2013. This seems to be a bigger problem. I can not help, I have no access to that server. - To the server for full-screen maps (http://maps.wikivoyage-ev.org/) users RolandUnger, DerFussi and Mey2008 have access. -- Joachim Mey2008 (talk) 07:09, 17 February 2014 (UTC)

There is only one admin who handles the mapframe server? That's astonishing. There should never be a program that depends on only one person. Ikan Kekek (talk) 07:37, 17 February 2014 (UTC)

Joachim, what happens if you start another server at tools.wmflabs.org and share access with several other people? --Alexander (talk) 08:14, 17 February 2014 (UTC)

The maps seems to be working again now, although this episode has shown us that we have a serious issue. If there is only one admin then we need to remove this weak point as soon as possible.

Although Wikivoyage is a community effort, we need a more professional SLA (Service Level Agreement) in place. Otherwise I would have to come to the awful conclusion that we should retire Dynamic Maps for now. I think the majority of the WV would hate for that to happen.

Can the problem be fixed by recreating the service as Alexander suggests, or is there something more fundamental in wmflabs.org causing this? Andrewssi2 (talk) 08:19, 17 February 2014 (UTC)

I think that this discussion goes in circles. There is a fundamental problem that tools.wmflabs.org is not very stable. One has to make it more stable (that we likely can not do), or create another map server with the proper SSL certificate. I think that we need a comment from a person who knows how to do it, and we need a comment only from this person, because someone has to make this effort. It is bloody clear that Wikivoyage needs stable dynamic maps, but repeating this statement again and again will not solve the problem.

Another account at tools.wmflabs.org could be an interim solution, if Joachim thinks that full access to the server may help. --Alexander (talk) 08:31, 17 February 2014 (UTC)

It is hardly circular. It is a simple question (that has yet to be answered) which is whether the wmflabs.org server should not be used any longer for Dynamic Maps. If the answer is yes then we can move on to discussing alternative mapping solutions.

I do have a technical mapping background actually (a commercial product called ESRI) and I do know that a new solution will take a lot of work. Therefore I do want the first question answered in the first instance. Andrewssi2 (talk) 08:46, 17 February 2014 (UTC)

Is it seriously just Torty3 who has access to the server? I think it would be obvious to give access to a couple of other persons who have knowledge and time to do something about this recurring problem (the same Bad request error showed up a couple of weeks back) - maybe Joachim and a couple of WP users? ϒpsilon (talk) 15:31, 17 February 2014 (UTC)

Sigh, what a bummer thread to remake my debut after some lovely travels away from constant support requests (I don't know how Joachim deals with it :) and general site squabbles. For what it's worth, I left instructions on how to become an additional maintainer at #Secure_site_at_tools.wmflabs.org and as soon as someone has a Wikitech account they can get control. Imagine my dismay when I left my talk page message after realising the Tools Labs account was a weak link. I think I could add User:Zhuyifei1999 who has a current account there if they want.

However, the Tools Labs have definitely not lived up to expectations, and it really is more of a development and not production server. They have constantly suffered from XFS issues on their distributed network and it's only something the actual sysadmin (and not a common maintainer or account holder) can fix. One possible solution is to try and set up a proxy server like User:Nicolas1981 tried to do before the current situation, since they may have fixed the security issues by now. Or if someone helps the maps.wikivoyage-ev.org server get a security certificate. By the way, not that it matters and any incompetence is solely my own, but *cough* I'm a she. -- torty3 (talk) 16:08, 17 February 2014 (UTC)

Hi torty3! Great to see you back! What should one do to get the security certificate? --Alexander (talk) 17:04, 17 February 2014 (UTC)

Do you mean hosting on Wikimedia Labs instead of Tools Labs? In any case my Wikitech account is https://wikitech.wikimedia.org/wiki/User:Nicolas_Raoul and the instance I did my tests on is https://wikitech.wikimedia.org/wiki/Nova_Resource:I-000005b0.pmtpa.wmflabs . Of course I can invite you to my small project if you want to modify the instance or create new instances. Nicolas1981 (talk) 10:58, 18 February 2014 (UTC)

Yep I mean the separate instance, which should be hosted on separate network clusters from Tools Labs, though their security certs may still not be functional. A WMF engineer did say they would assist in getting a security certificate, but I'm unsure as to the setup on the maps.wikivoyage-ev.org and there are quite a few online guides to help out. I agree with the Germans that it's a lot of hassle to set it up just because the entire WMF decided to move towards HTTPS, but what can you do. -- torty3 (talk) 06:25, 20 February 2014 (UTC)

"Internal Server Error

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

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

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

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

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

The service seems OK to me right now.

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

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

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

Thanks for that ;) Difference: avoids ddos attacks --Zhuyifei1999 (talk) 15:31, 25 February 2014 (UTC)

Map marker images linking to mobile site

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

It was my laziness. - This works in both mobile and desktop version, but only in full screen mode. An adjustment is on my long to-do list. -- Joachim Mey2008 (talk) 13:18, 25 February 2014 (UTC)

Alright. As long as it's a known issue. –Thatotherperson^talkcontribs 07:53, 26 February 2014 (UTC)

Default map layer

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

I'm fine with that, but seeing as it affects a lot of articles you might want to add a note to the Pub that points people to this discussion. -- Ryan • (talk) • 06:34, 17 March 2014 (UTC)

For each page view the dynamic map is automatically loaded in the frame. In each case, some map tiles are loaded. Only MapquestOpen allowed unlimited access to the tiles. Therefore, the Layer "O" must be the default. -- Joachim Mey2008 (talk) 06:49, 17 March 2014 (UTC)

I wasn't aware of any limits to the number of tiles you could load. What happens if you change the layer? I've already done so manually on a handful of articles and the only missing tiles I've noticed were in the aerial footage.
Thatotherperson^talkcontribs 07:00, 17 March 2014 (UTC)

Other providers limited the number of requested tiles per day and then block access. So my concern, but only if we use an other layer (eg Mapnik) for all the articles. -- Joachim Mey2008 (talk) 07:10, 17 March 2014 (UTC)

Actually, if we were to change the default layer I'd suggest Wikivoyage. It has some flaws, but it harmonizes best with our existing maps. Powers ^(talk) 18:05, 17 March 2014 (UTC)

I also prefer the look and feel and detail of Mapnik (OSM); however, it has a major drawback in that for many countries that do not use a Roman alphabet, many of the labels are problematic. Joachim's answer is the clincher against changing the default, though... --118.93nzp (talk) 09:19, 18 March 2014 (UTC)

Hi Joachim, I've been using Mapnik pretty much exclusively. Would you advise against doing this? Andrewssi2 (talk) 11:27, 18 March 2014 (UTC)

For city articles only the default layer ("O" = MapquestOpen) should be used. This layer has specially few signatures, then the markers are better visible. If a visitor wants more information, he/she may select a different layer. The quantity limitation of different tiles providers (except MapquestOpen) should also be considered. -- Joachim Mey2008 (talk) 12:22, 18 March 2014 (UTC)

Each map type has its advantages; Mapnik is good for finding POIs we haven't listed yet, the relief map is probably the best one for mountainous areas and national parks in general and the default maps is the best looking (IMO). Maps that can be loaded a only limited number of times are obviously not a good idea to have as default, unless that limit is high enough. Let's stick with the default map. ϒpsilon (talk) 12:46, 18 March 2014 (UTC)

Scripts update

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

Current settings is to update on 11:20 (UTC) every Monday and Thursday. Just wait another 24 minutes ;) --Zhuyifei1999 (talk) 10:56, 24 March 2014 (UTC)

We're not talking about minutes. A new version is available for three weeks now on maps.wikivoyage-ev.org/archive/. -- Joachim Mey2008 (talk) 13:17, 24 March 2014 (UTC)

@Mey2008: I have no idea of what is wrong with that auto-update script, but anyway I have manually updated it. Please check if it is up to date as I don't know what the change is. --Zhuyifei1999 (talk) 13:24, 25 March 2014 (UTC)

Thank you, everything's okay now. - The scripts are constantly being revised, some bug fixes and enhancements are relevant only in other language versions​​. -- Joachim Mey2008 (talk) 14:06, 25 March 2014 (UTC)

Proposal to separate map design from coordinate specification

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

This proposal has the following advantages:

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

Thoughts?

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

There is significant background at Wikivoyage talk:Listings#Overprecise geotagging that is useful for anyone joining this discussion.

I'm still unclear as to why overprecision in listings is a problem. I understand why saying "Los Angeles is 381.114535 miles from San Francisco" is absurd in text, but if that same information was purely metadata used internally by tools on our site I don't see how it would cause any harm, and that's the only way we're using lat/long coordinates at the present time. I'm happy to support this proposal if there is a demonstrated need for it, but at the current time it seems like it could create a lot of clutter in listings without any obvious benefit. -- Ryan • (talk) • 17:54, 26 March 2014 (UTC)

One of our explicit goals involves our data being used in external applications, such as other travel guides. As such, it is contrary to our goals to consider only what benefits Wikivoyage, and to only consider Wikivoyage's needs, when designing our features. The fact that, at the moment, the only one of our our features that uses the geo-coordinate data is our dynamic map feature means neither that a) we will never have a feature in the future that needs accurate coordinates (e.g., an expansion of the "Near this page" feature that is currently in beta, or an extension of Special:Nearby to work with listings rather than articles), nor that b) noone else out there in Internet land is making nor will make use of our data with or without our knowledge. Even if there isn't anyone looking at our listing coordinates currently, consider this a bit of future-proofing. Consider, in fact, that at one point we even did display these coordinates to readers (on hover over an icon), so this is not some far-fetched, pie-in-the-sky possibility; it's reality. Powers ^(talk) 23:37, 26 March 2014 (UTC)

I disagree that overprecise coordinates is a problem for re-users - it is up to individual re-users to decide how much precision is needed for their particular use, just as we trim or expand coordinates for our use here. It seems like this proposal is an effort to solve a problem that doesn't currently exist ("consider this a bit of future-proofing") and thus offers little or no current benefit while forcing us to maintain duplicate sets of coordinates for a large number of our listings. Others may feel differently, but I don't think it's something to pursue until there is a demonstrated need for it. -- Ryan • (talk) • 23:50, 26 March 2014 (UTC)

On a related note, perhaps adding something to Wikivoyage:Listings (or another relevant page) that suggests how much precision to use would be useful - along the lines of w:Wikipedia:WikiProject Geographical coordinates#Precision. That way we could make it clear that anything more than 5-6 digits is pointless, and provide guidance on when (and why) less precision might be prudent. Providing such guidance might allow us to standardize to some extent, which would address your concern in many cases while still allow map makers the needed flexibility. -- Ryan • (talk) • 00:35, 27 March 2014 (UTC)

First of all, precision is part of the data we are putting out there. Re-users may not know how precise the coordinates are if we don't provide the proper number of decimal places to start with. But aside from that, this isn't just about overprecision; as I understand it, some editors have taken to slightly mis-placing coordinates to avoid collisions on the map (either with other icons or with elements in the underlying tiles).

But beyond all that, I'm very disappointed to see you dismissing this good faith effort to find common ground on an issue that has caused tension. You have said several times over the last year or so that it is important for editors who oppose a new proposal to acknowledge the concerns of those who find a deficiency in current practice and find a way to meet them halfway, rather than just saying "no". Not only am I trying to do that here, but you are reacting to my proposal by essentially just saying "no". Just because you don't see the need doesn't mean that other editors don't, and it would help this discussion greatly if you could at least acknowledge the validity of that viewpoint, even if you disagree with it.

-- Powers ^(talk) 02:18, 27 March 2014 (UTC)

Geomap [2] shows decimal places according to the object size. Examples: United States [3], a building [4]. Please click on the map. Decimal digits vary from 0 to 5. Over-precision is avoided in this way, further arguments are not very important, in my opinion. -- Joachim Mey2008 (talk) 07:41, 27 March 2014 (UTC)

First of all, that's not true; it shows decimal places according to the map's zoom level. The interface doesn't appear to take the size of the object into account at all. Secondly, I'm afraid I don't understand what Geomap's functionality has to do with this proposal. Powers ^(talk) 14:11, 27 March 2014 (UTC)

Well, back to the topic (separate map coordinates). I oppose the proposal. The effort is much higher than the benefits. -- Joachim Mey2008 (talk) 15:40, 27 March 2014 (UTC)

LtPowers, first, I apologize for not being more constructive in my initial response, but I believe that my proposal timestamped 00:35, 27 March 2014 is an attempt to address your concerns without requiring us to maintain duplicate coordinates. -- Ryan • (talk) • 16:06, 27 March 2014 (UTC)

Apologies, I did gloss over that post a bit; it seemed more like an additional suggestion than a replacement suggestion. However, "duplicate coordinates" is a bit of a red herring; the only case in which we'd have to maintain duplicate coordinates is when someone decides that the position of the map icon for a particular listing needs to be tweaked slightly. In all other cases (likely 99.9%), the map will default to using the lat and long values, as it does now. This adds very little additional maintenance, by design. If I'm reading your suggestion right, the idea is to reduce overprecision in cases where it's done out of carelessness, but to allow it in those 0.1% of cases where someone wants to move the map icon; is this right? Powers ^(talk) 23:11, 27 March 2014 (UTC)

I think if we can provide some guidance on how much precision to use then it would educate editors and allow them to choose levels of precision that would address your concerns. Further, if I understand correctly, five decimals is accurate to within a meter, so we can probably come to an agreement that anything more precise can be trimmed (it would be easy to add such a rule to WV:AWB). Would that at least start to address your concerns? -- Ryan • (talk) • 05:28, 28 March 2014 (UTC)

These two markers [5] were 6 m shifted each so that they do not overlap. Do we really need more precise coordinates? - Joachim Mey2008 (talk) 06:29, 28 March 2014 (UTC)

Certainly not; I'm in complete agreement that six decimal places is far too many for any reasonable application. Five is, in my opinion, useful only for map positioning tweaks, except perhaps for small statues. Three is sufficient for most listings, two for small cities, and one for large cities. If it is felt that such guidance is useful, then by all means it should be added. But it doesn't address the basic disparity between using the coordinates for maps and providing them as information. If the maps are going to shift listing coordinates in order to achieve more aesthetic results, then the precision guidelines you're proposing don't apply anyway. Powers ^(talk) 17:42, 28 March 2014 (UTC)

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

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

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

Spiderfy

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

Spiderfy is a proven technology [6]. But it does not perfectly solve the problem. Hidden markers are visible only after a click.

My suggestion: selecting a high zoom level (eg, 16 in cities). Centering on an interesting part of the city in the map frame [7].

Scrolling is quite normal in the text area of each article. No one demands that the whole text is scale down to a screen size. The text part is dynamic. Why is not normal even pan and zoom in a dynamic map? There are two aids. The light blue edges markers indicate where additional markers are present and a quick overview with the button "Show me all the markers."

Perhaps such a solution is acceptable? - Joachim -- Mey2008 (talk) 06:43, 30 March 2014 (UTC)

I don't like the idea of zooming in on one specific part of a destination for the initial map load. Scrolling through the text portion of the page is easy and intuitive because down is always the correct direction to keep reading, whereas a pre-zoomed map doesn't present an obvious order to explore the destination in (other than zooming back out to get your bearings, a step that can be skipped if we just keep using the current zoomed-out maps). The "show me all markers" button is helpful, but not very intuitive—I didn't even know it existed until just now.
Thatotherperson^talkcontribs 01:14, 31 March 2014 (UTC)

Is that better [8]? I think not. A city map with 100 markers in a frame of 10 x 10 cm is confusing. - Are there better examples on the WWW? I have found no solution (except clustering). - Joachim Mey2008 (talk) 06:29, 31 March 2014 (UTC)

That was definitely an excessive amount of POI overlap, but the problem on that page went deeper than the zoom level. First of all, I have to wonder why a city of 2 million people would be districtified in such a way that five out of six districts represent a third of the city, while the other two thirds of the city share one article and one map. There was never going to be a good way to display that district in a single map. The problem was then made worse by using absolutely tiny dimensions for the map frame, which I have now fixed. The map still has both overlapping POIs and out-of-frame POIs, but the only way to truly fix it would be to redo the districts of Budapest. Short of that, I think a larger map with a medium zoom level is a better solution than zooming in on a specific neighborhood when the map is supposed to represent two thirds of a major city.
Thatotherperson^talkcontribs 22:59, 31 March 2014 (UTC)

Budapest Districts are currently under discussion, following a lot of content having been added in the last three months. Currently there are 3 districts, with 6 proposed. I think that the article was about a third of the present size when the map was added, so Pest is probably not a good example. AlasdairW (talk) 22:39, 1 April 2014 (UTC)

Layers

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

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

Awesome. I love the new Boundaries layer. It does bring up an issue though: the current guidelines for adding a dynamic map say to "only add dynamic maps to articles at the lowest level of the article hierarchy (city or district)". The origin of that rule seems to be Texugo's comment above: "the function of maps in metropolis, region, and country articles is to show how we have broken down the coverage. The dynamic maps do not serve that function at this time." Obviously we still can't draw custom borders on a dynamic map, but I believe a low-level region article with a dynamic map can be significantly better than one with no map, especially in light of the Boundaries and Destinations layers now existing. (On a related note, is there any way to remove the blue circles from the Destinations layer? I find them more distracting than helpful.) Is it time to do away with guideline #1? I also dislike rule #4 about needing a specific reason to customize the height and width, if anyone would like to comment on that while we're at it.
Thatotherperson^talkcontribs 23:57, 2 April 2014 (UTC)

We split large provinces & states into many colour-coded regions

Cities/towns and districts have individual {{listing}}s; 'container' articles such as regions should not. A region needs the custom borders, but at the same time likely does not need the city-style POI's. K7L (talk) 01:19, 3 April 2014 (UTC)

Custom borders of a region can be represented by {{mapmask}} (example). Your reference to POI I do not understand. In the dynamic region maps no POI's are shown (example). -- Joachim Mey2008 (talk) 04:32, 3 April 2014 (UTC)

Is there any way to colour-code and label these regions, or their neighbours, on the map? K7L (talk) 14:31, 3 April 2014 (UTC)

A lowest-level region article does not need custom borders, though, since it isn't split into further regions. A dynamic map with the Destinations layer activated could improve quite a few of these articles. As for POIs, I understand not wanting to put business listings in region articles, but that doesn't mean there will never be a good reason to use a map marker on a region article. For example, the bulk of the content at Western Utah is about art installations in the middle of the desert; none of them is anywhere near a city they could be listed with, but why not still show people where they are on a map? If someone added a dynamic map that really wasn't an improvement to the article, we could fix that without needing a broad guideline against adding dynamic maps to region articles.
Thatotherperson^talkcontribs 08:12, 5 April 2014 (UTC)

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

The boundaries of the counties in the examples are not boundaries of regions! The Eastern Finger Lakes region is bounded by the gray mask (see example). The political borders can be hidden if required (layers button in the upper right). Useful is also the layer "Destinations". There all existing articles are displayed. With [shift-click] you can directly open the desired travel destination article. - My suggestion should apply only to the lowest level of a region that has no further subdivisions. -- Joachim Mey2008 (talk) 16:00, 3 April 2014 (UTC)

Yes, I was using the word "regions" generically, not in the Wikivoyage sense (which I usually try to capitalize, as "Regions"). Regardless, though, I think "Yes, but if the reader clicks the right button the problem disappears" is getting kind of tiresome as a response when problems with the dynamic maps are pointed out. Powers ^(talk) 23:37, 3 April 2014 (UTC)

You can of course preselect the desired layers. {{mapframe|...|...|...|layer=O}} [11] or {{mapframe|...|...|...|layer=OD}} [12] or {{mapframe|...|...|...|layer=WBS}} [13]. Many other combinations are possible. -- Joachim Mey2008 (talk) 04:44, 4 April 2014 (UTC)

Anything on removing the blue circles from the Destinations layer? People aren't going to understand what the circles mean if the layer is preselected.
Thatotherperson^talkcontribs 08:12, 5 April 2014 (UTC)

If no other opinions, I will remove the blue circles in the next version. - Joachim Mey2008 (talk) 11:39, 5 April 2014 (UTC)

Dynamic region maps

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

New marker clustering

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

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

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

That's very cool! The only downside is that you can't link the numbers in the article to the map without clicking - would there be any possibility of showing the numbers when hovering over the zoom icon, or in some other way showing what listing is being represented? Even without that functionality, this appears to be a nice usability improvement. -- Ryan • (talk) • 07:05, 24 April 2014 (UTC)

I still can't get a server response from any wikivoyage-ev links. I tried four browsers. –Thatotherperson^talkcontribs 01:48, 25 April 2014 (UTC)

Please note that the WV-ev server provides only http. -- Joachim Mey2008 (talk) 04:46, 25 April 2014 (UTC)

Ryan's idea is good, but too complicated for my programming skills. - Do other users have also problems with the server access? - If no other opinion, I will activate the clustering in the next version. -- Joachim Mey2008 (talk) 05:30, 1 May 2014 (UTC)

Destinations layer glitch

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

An old error. Was quite forgotten. Is now on my todo list. - Thanks for the note, Joachim Mey2008 (talk) 05:06, 25 April 2014 (UTC)

Update is done. Please reload the page twice if necessary. -- Joachim Mey2008 (talk) 11:56, 1 May 2014 (UTC)

Dynamic -v- static maps

Swept in from the pub

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

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

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

This is not the wiki way.

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

Do you know how to edit maps? If you do, then recommending that others who lack the time or/and inclination learn how to edit maps instead of editing them yourself is also not the "wiki way." The wiki way is to plunge forward, not to complain that others are not doing so when you can. Ikan Kekek (talk) 18:48, 12 March 2014 (UTC)

(edit conflict) Many of us are of the opinion that the "fix" to the drawbacks of static maps was to implement dynamic maps. We have had hundreds of maps added to articles in the past few months, as opposed to the much smaller trickle that was added when static maps were the only option, and every editor can now edit those maps when they edit an article. Clearly your opinion is different, but saying that implementation of dynamic maps, as opposed to maintenance of existing static maps, is not the "wiki way" is an argument that is definitely in dispute. To look for a constructive path forward, let's figure out how, when and if the two should co-exist, ideally acknowledging that both can have a place on this site and that supporters of each have valid arguments. Example: Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site? -- Ryan • (talk) • 18:55, 12 March 2014 (UTC)

Lt, I think you and I are part of a dying breed. ;) I'm not overly fond of the quality of the dynamic maps myself, although I don't find them to be so offensive as to be utterly inferior. And they are pretty dang functional, I gotta give them that.

More than that though, I've just lost any kind of enthusiasm in working with the static maps because I feel like the Wikivoyage community, for the most part, has no interest in caring for them. I made a lot of static maps, and I made them in the belief that after I uploaded them here, the community would take ownership of them and keep them up-to-date, even improve them if need be. That rarely happened. Usually, the map would just sit there collecting dust (by which I mean slowly go out-of-date) and eventually I would have to come back and update it myself. And proud as I am of the work I've put into this community, I have a busy life outside of this website; I don't want people relying on me to keep this stuff in order. And I get it; Inkscape looks like a really scary complicated program and there's a reluctance among users to touch the static maps. Fine, I accept that.

In the end, if the choice is between a well-made static map that no one is going to care for, and a sloppy dynamic map that people will at least bother to update, then I'd choose the dynamic map. I don't want to see a bunch of relics on Wikivoyage, even if I'm the guy who built them. PerryPlanet (talk) 19:31, 12 March 2014 (UTC)

I do think static maps are the only way to go in region/state/country/continental section/continent articles, since they are the only way we can have maps that are color coded, labeled with our own peculiar region names, etc,. and I don't see that changing anytime soon. For cities though, I tend to agree with Ryan. Your critique about overlapping icons/names fails to take into account the ease with which the map can be manipulated around most of those problems. If they were algorithmically-created static maps, your point would be 100% valid, but they are dynamic, so the user can circumvent most of those problems, when they pop up, with a tiny movement of the mouse scroll. Texugo (talk) 19:41, 12 March 2014 (UTC)

I am with Texugo on that. I would love to see the day when dynamic maps would sort the overlapping icons issues themselves, and we could even highlight objects on the map itself that should not be obscured by the icons, but I believe dynamic maps is the way to go for city/district-level articles. This is a wiki, which anybody should be able to edit with the result being a better article, not an outdated map. PrinceGloria (talk) 20:07, 12 March 2014 (UTC)

Sometime back, when I was not a fan of dynamic maps and I really disliked them, so I created a city level map for Karachi but the map was lacking only FEW point of interests which are located in suburbs of the city so I realised a dynamic map is actually appropriate to use in such a large city POI are scattered far and wide and where new businesses such as restaurants, accommodations etceteras pop up frequently and the dynamic map can be modified easily simply by anyone accordingly. There were only minor issues with that static map I created but due to non-availbity of time, I decided to replace that static map with a dynamic map. I think I very much agree with comments of those who says a dynamic map is very useful for cities and district level articles but when it comes to a region article, a dynamic map can't beat even a incomplete and poor crafted static map. --Saqib (talk) 20:58, 12 March 2014 (UTC)

My major issue with dynamic maps is that the server is balky. If dynamic maps become unusable, we will regret that we don't have static maps for every article. Ikan Kekek (talk) 22:30, 12 March 2014 (UTC)

I actually share much of PerryPlanet's opinion, and no shared updates to static maps is what I mean by not enough critical mass. If say there were many people actively editing an article, I wouldn't mind perhaps chipping in my bit and making a static map. But I do not want to be the only one in charge of the map graphic. It's symptomatic of the problems of static maps in the past ten years. When I mean outdated, I mean five years outdated and it's not just one outdated listing, but tens. I'll even point out that one needs Maperitive and Inkscape, two different programs, to create static maps unless you painstakingly trace each and every road, since OSM no longer natively supports SVG export.

In fact I'm going to go further and say that there is a severe lack of collaboration around the entire site in the first place, where we are lucky enough to have one contributor for a city, let alone two or more to bounce ideas and keep up maintenance of maps or otherwise. I'm more interested in solutions for that, because I think it is the root problem, rather than retreading old arguments or nitpicking formatting. -- torty3 (talk) 00:01, 13 March 2014 (UTC)

The static maps have one trump card which is that they are always available. The Infrastructure behind dynamic maps is running on is not reliable and support is basically 'best efforts'. (And those efforts are very much appreciated, but we need to be honest about this functionality in order to improve it)

For that reason I would support Powers in not moving away wholesale from static maps today.

For the record, I did myself get started in creating some static maps however the effort involved meant that I simply can't justify spending the time to create or even update existing maps. Laziness? Yes, probably, but in all honesty the Dynamic Maps have a low bar for all people to get involved (a good thing) and the static maps have a rather high bar. Andrewssi2 (talk) 00:52, 13 March 2014 (UTC)

All of the objections raised are addressable with a little bit of effort. And isn't it better to take that effort on ourselves rather than ask the reader to scroll and zoom a map until everything is visible? When did we become a community that valued ease of construction over value to the traveler? Powers ^(talk) 16:13, 13 March 2014 (UTC)

"When did we become a community that valued ease of construction over value to the traveler?". Please re-read what you've just written. Nearly everyone who has argued in support of dynamic maps has stated that they provide added "value to the traveler". Everyone recognizes that there are pros and cons of each approach, but continually describing dynamic maps as if it is a fact that they are an inferior tool is not helpful; that is your opinion, and it is an opinion that is not universally shared. We need to come to an agreement on how to move forward, and while it would be great to find a compromise solution, if the choice is repeatedly painted as being between the "good" solution and the "bad" solution then I vote for dynamic maps as being far superior to static maps for everything below the region level. I hope it doesn't come to that - let's stop focusing on one instead of the other and find some middle ground that makes both sides happy. -- Ryan • (talk) • 16:42, 13 March 2014 (UTC)

I just noticed a case in point. Hong Kong Central has some lovingly hand crafted static maps. I would like to update the article listings, but I'm not willing to spend the considerable time to edit the static maps. Effectively an impasse.

As pointed out before we really need more contributors. Being a master cartographer should not be a requirement to get involved and creating awesome articles.

Perhaps the Hong Kong central article can provide a good starting point for discussing the compromise? Andrewssi2 (talk) 00:47, 14 March 2014 (UTC)

"I vote for dynamic maps as being far superior to static maps for everything below the region level"

Not to nitpick, but I'd say static maps are also the superior option for parent articles of districtified Huge Cities (q.v. Buffalo#Regions).

-- AndreCarrotflower (talk) 00:56, 14 March 2014 (UTC)

Another case in point: Do you think a dynamic map is likely to be better than the static map in the San Francisco/Mission article? There are cases to leave well enough alone. Ikan Kekek (talk) 01:16, 14 March 2014 (UTC)

No, I think the San Francisco/Mission static map is better than what can be achieved with a dynamic map. (i.e. if I want to print the map and walk around the district the static map would make it much easier)

The question is WHO is going to add new listing to this static map? If no one, then is it acceptable that the article becomes more out of synch over time? At what point does remedial action need to be taken?

And no, I have no answers to the above :) Andrewssi2 (talk) 01:41, 14 March 2014 (UTC)

Finally an HTTPS server for dynamic maps

Swept in from the pub

Dear travellers,

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

• https://voyage.wmflabs.org
• https://voyage.wmflabs.org/poimap2/poimap2.php

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

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

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

I'm seeing an error with the generic Listing icon. See here on the old server there's three green hexaflowers on the west side of town, then switch to the new server and the icons no longer load.
Thatotherperson^talkcontribs 01:34, 26 March 2014 (UTC)

Yes, the PHP source code is not up-to-date.

So, if I understand correctly, the last thing to do to get rid of the mixed-content problem is to install an OSM tiles server on voyage.wmflabs.org? Am I right? Does anyone have experience with this? Nicolas1981 (talk) 03:06, 26 March 2014 (UTC)

An own tile server for OSM Mapnik tiles is not a solution. We need tiles for all 10+ different layers. But not all providers offer data dumps as OSM (Planet.osm). Mixed content is inevitable. -- Joachim Mey2008 (talk) 06:11, 26 March 2014 (UTC)

I don't think we absolutely need to serve ALL layers as HTTPS, but at least the default layer, so that external visitors can enjoy the map instead of staring at a white rectangle. Nicolas1981 (talk) 04:55, 27 March 2014 (UTC)

I tested extensively on real hardware and could find no errors. Example: Debian 6.0/FF 28/https/not logged in [18]. Sometimes the cause is also due to specific settings (browser, proxy, virus scanners). Do other users have similar problems? Nevertheless, I will revise the scripts in terms of map tiles under https. -- Joachim Mey2008 (talk) 09:12, 27 March 2014 (UTC)

It should also be checked, whether in the personal common.js is still a trial version of mapframe.js. This needs to be deleted because it is no longer compatible. The old version caused a white map window. -- Joachim Mey2008 (talk) 13:43, 27 March 2014 (UTC)

As you pointed out, it was a problem with my common.js indeed! So an HTTPS tiles server is not absolutely needed right now :-) Thanks a lot! Nicolas1981 (talk) 15:38, 28 March 2014 (UTC)

All Mapquest and Mapnik layers now use tiles that are offered under https. -- Joachim Mey2008 (talk) 16:21, 24 April 2014 (UTC)

Destinations layer again

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

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

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

Good ideas!

1. target="_blank" - I have coded it now. Update next Thursday.
2. article markers control - This takes a little longer. My solution: markers of all the articles (worldwide) are displayed. Markers outside the map mask will darken gray. The article marker of the current article, I can not hide. But maybe display in a different color.
3. hide POI markers - You may already hide the POI layer. Example: layer=OD-P. - Joachim Mey2008 (talk) 19:22, 9 June 2014 (UTC)

I'm attempting to write an itinerary; is there any way to display destination markers for just the villages which have [[wiki]]links in my article? Radiator Springs#Prepare, if the 'D' layer is enabled (it currently is not), shows a large cluster of destination markers west of OKC based solely on radius from map centre. These appear without regard to whether any of them are listed in the article, or are on Route 66 at all. Effectively, a typical Route 66 itinerary should include tiny Adrian TX (pop 140) but ignore larger centres like Denver which are on some other route.

I suppose the same is true for standard regions, eastern Ontario includes Ottawa but not Gatineau, but those usually use static maps in order to show the region boundaries as colour.

Distance from a GPX trace might work, or show 'D' markers for just the destinations linked from the article? K7L (talk) 18:09, 10 June 2014 (UTC)

A specific limitation of the "D" layer is not possible. Other languages ​​versions used the type "vicinity" for nearby destinations (Example). Destinations can be selected individually on this way. -- Joachim Mey2008 (talk) 05:00, 17 June 2014 (UTC)

That's pretty cool. I've implemented the city and vicinity markers as a replacement for the Destinations layer at Central Nevada and I like the results. The only drawback is that there isn't an article link on the map itself this way, but I guess that's only a problem in fullscreen mode since an embedded map would be right next to a list of city links.
Thatotherperson^talkcontribs 00:35, 18 June 2014 (UTC)

Will it ever be possible to generate these dynamically?

These look interesting, although it's unfortunate the markers appear as POIs instead of destinations. On articles which list cities/villages but not individual POIs (such as Rideau Canal or Trans-Canada Highway) it might be usable - on something like Route 66 which has both a list of towns and a list of attractions I'm not sure how to avoid having POI markers for the venues overlap the marker for the town everywhere. Will this just become a sea of yellow '+' signs? K7L (talk) 14:05, 18 June 2014 (UTC)

The article "Route 66" is no problem at all. A static overview map is already available. For individual sections may be links (not mapframes) set to detailed maps. See the example Rheinburgenweg. So there are no clusters of markers. To clarify: There are only shown the markers of the current article (eg Route 66), not even the markers of neighboring articles. - Joachim Mey2008 (talk) 15:12, 18 June 2014 (UTC)

@User:K7L: Region maps can be static/dynamic [19] or fully dynamic [20]. -- Joachim Mey2008 (talk) 05:47, 19 June 2014 (UTC)

It looks like the Rheinburgenweg maps do contain 'D' markers for destinations not on the route; they're less visible because the individual maps are zoomed to 13-level (almost city-scale) instead of showing the entire itinerary (which appears to be about 200km, much like Rideau Canal#Go). If Route 66 is 2448 miles (4000km) and Trans-Canada Highway double that, it would take many individual maps to fit them all onto zoom-13 level. I'd added a map to Rideau Canal, but left the 'D' layer turned off and used marker|type=city as otherwise it seems to pull in everything from Canton to Calabogie - which are not on the route. K7L (talk) 14:35, 19 June 2014 (UTC)

Such long routes can be made ​​without detailed maps. Or just a few detailed maps for particularly interesting parts. Often also helps to click on the colored markers in the article text and zoom a little. -- Joachim Mey2008 (talk) 15:19, 19 June 2014 (UTC)

Dynamic maps icons

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

Dynamic Map - small improvements

Version 2014/18

1. The destination layer was enlarged to about 500 x 500 km.
2. The destination link is now clickable in mapframe and opens in a seperate tab.
3. Markers with preview images are marked in the tooltip.
4. Preview images are now clickable in mapframe and be enlarged in a seperate tab.
5. The buttons "Destinations" and "All markers" now have a handy toggle function.

-- Joachim Mey2008 (talk) 12:47, 16 June 2014 (UTC)

Thanks Joachim! --Andrewssi2 (talk) 12:58, 16 June 2014 (UTC)

Are you still planning to expand the Destinations layer to show all markers worldwide eventually?
Thatotherperson^talkcontribs 00:26, 17 June 2014 (UTC)

The display of all the 20,000 markers is too slow on some computers (eg mobile phones). I need some time to optimize the script. -- Joachim Mey2008 (talk) 04:31, 17 June 2014 (UTC)

Just out of interest, why is this feature desirable? (the ability to show global markers) Andrewssi2 (talk) 08:32, 17 June 2014 (UTC)

The idea was to make it so that a region or itinerary map could be any size without exceeding the boundaries of the Destinations layer, but that won't be necessary if we use the marker template instead as described above.
Thatotherperson^talkcontribs 00:35, 18 June 2014 (UTC)

I see, thanks! Andrewssi2 (talk) 01:36, 18 June 2014 (UTC)

Version 2014/19

1. Fast zooming by holding [shift] + click button [+] or [-] (improved)
2. Fast zoom in by holding [shift] + drag rectangle (improved)
3. Markers with link to WV-article possible, both in map and article. Example: 1 Hildesheim {{marker|type=city |name=[[Hildesheim]] |lat=52.149 | long=9.952 |zoom=12}} (new)
4. Minimal zoom level = 0 (new)

-- Joachim Mey2008 (talk) 14:20, 26 June 2014 (UTC)

Love it, especially point #3, but you seem to have broken the mapmask functionality. Even trying to manually activate it with layer=OG doesn't work.
Thatotherperson^talkcontribs 01:10, 27 June 2014 (UTC)

Thanks for the error message. This error affects both GPX files and Mapmask. I would test more and to watch less football. Hopefully fixed for next version. -- Joachim Mey2008 (talk) 04:49, 27 June 2014 (UTC)

Version 2014/20

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

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

Version 2014/21

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

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

Detailed maps

Have added templates to aid with sections of itinerary routes.

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

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

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

Dynamic map placement

Swept in from the pub

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

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

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

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

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

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

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

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

Disagree quite fully. The maps should never be changed from their default size and right-alignment unless it is otherwise impossible to properly frame the area in question. Putting a giant centered map not only duplicates the purpose of the full screen map, it creates a chasm in the flow of the article, creates a lot of unnecessary white space, and increases the amount of scrolling between the map and the corresponding listings in the article. Texugo (talk) 16:16, 29 May 2014 (UTC)

To Texugo's point, there was previously a discussion on this point at Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site? and the consensus seemed to be to always use the default map size unless an alternate size was need for a specific reason, such as when an area was shaped in such a way that the map needed extra vertical or horizontal space. That guidance was then captured in Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment (item #4). -- Ryan • (talk) • 16:28, 29 May 2014 (UTC)

I'm sorry that I've failed to communicate my reasoning clearly.

If everyone on earth (and, more pertinently, all travellers and potential travellers) had affordable, fast connections and viewed WV on largeish screens (or mobiles, when the layout is custom adapted) I would thoroughly agree with a default alignment (as for thumbnails) of right.

Unfortunately for a substantial (but highly handicapped minority) that's not the case. Surely you don't want to handicap those users further for a minor aesthetic niggle?

An analogy would be the construction of ramps for public buildings to allow easier access for those who are not too spry. It costs money and a bit of uglification but surely you don't begrudge that to enable easier participation in the community for those not as fortunate as yourself?

It will literally be impossible for me to geo-code many African destination articles if you keep changing the map size, zoom levels, and layers a few days after I've added them... -- Alice^✉ 16:36, 29 May 2014 (UTC)

I have set the map window to the default values​​. So the article Entebbe appears faster than before. Please press the [Control] key and click on the link "View full-screen map for Entebbe". A full screen map is loaded on a separate tab then. Now you can use them for coordinates, without having to open the article with a big mapframe again and again. Alternatively, you can use this map [21] in a separate tab. I have tested everything with a simulated very slow phone connection. -- Grüße, Joachim Mey2008 (talk) 17:58, 29 May 2014 (UTC)

There isn't unfortunately a 'one size fits all' approach to faciliate the rendering of maps for low bandwidth/small screens and high bandwidth/large screens.

There is however no problem in using a different (lower bandwidth) service to determine your longitude/latitude and input them into individual listings direcly. Andrewssi2 (talk) 04:19, 30 May 2014 (UTC)

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

Dynamic map server is on the fritz again

Swept in from the pub

503 Service Temporarily Unavailable nginx/1.7.0

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

There is no separate server for dynamic maps. The application "poimap2.php" runs as project "Wikivoyage" on the servers system "Tool Labs" by the Wikimedia Foundation [22]. The project "Wikivoyage" is managed by User:torty3 and User:Zhuyifei1999. For the project itself so far there were no program crashes.

The inaccessibility always concerned the entire server system and all the other projects that are stored there. Our project managers have no influence in this matter. The server system is maintained by administrators of the Wikimedia Foundation [23].

The projects of the former tool server at the German Wikimedia Foundation are being integrated to end-June [24]. This unfortunately occurred partly overloads or crashes. I hope the tools labs servers are stable thereafter. -- Joachim Mey2008 (talk) 05:35, 12 May 2014 (UTC)

You guys do a great job, but there are only two of you. Is any effort being made to try to recruit more sysops? Ikan Kekek (talk) 05:38, 12 May 2014 (UTC)

As I'm busy myself and torty3 is inactive since March, if anyone here wants to be one of the maintainers, has the technical ability to maintain the project (eg. login is complicated), and seems to be trusted (eg. admin?), I'd be happy to add him to the assess list.

As for the "503 Service Temporarily Unavailable nginx/1.7.0", there's no way to fix that problem by tool maintainers. Every tool with web interface uses (by default) lighttpd attached to different ports on the grid engines. However, the actual tools.wmflabs.org is a nginx-based proxy server which only the roots of the tools project have access to. Therefore, in case anything like "503 Service Temporarily Unavailable nginx/1.7.0" (no fancy decorations or explanation texts), please report the issue to the labs-l mailing list or the #wikimedia-labs channel on freenode IRC. --Zhuyifei1999 (talk) 05:35, 24 May 2014 (UTC)

Well, I believe I should volunteer. However, I have no access to wikitech and tools, so I will request it now and let you know when it's ready. In the meantime, everyone is welcome to object if you think that I am not trustful-) --Alexander (talk) 05:48, 24 May 2014 (UTC)

For reference, I have given Alexander the access to the tool. --Zhuyifei1999 (talk) 02:34, 25 May 2014 (UTC)

Missing magnification & layer selection

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

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

Layer selection and zoom buttons are missing only when low memory, for example, in a mobile phone. The script needs to be optimized. -- Joachim Mey2008 (talk) 14:34, 22 May 2014 (UTC)

Thanks for the hint, Joachim. While it's true that Firefox has been "leaking" memory for years and this latest version certainly seems no better in this respect, I have actually now had the bizarre experience of opening more tabs (I went from 10 to 17 on my trusty notebook) and the buttons re-appeared! Go figure. -- Alice^✉ 19:36, 22 May 2014 (UTC)

Same problem on a very powerful Linux computer. Only the zoom level is shown. All of the other controls are missing: http://i.stack.imgur.com/hR9bn.png Reproduced on Firefox and Chrome. Nicolas1981 (talk) 04:29, 23 May 2014 (UTC)

Oh dear.

I was hoping that this was just a rare problem related to the recent downgrades of Firefox (27.0 - 29.1 under Windows7). Your post and screenshot indicates that there is/was a wider problem since your American map (presumably displayed under Unix) shows the exact same aberration I was having problems with. However, there are an awful lot of markers on that American map, so this could still be a memory artefact, yes?

@Mey2008: have you made some code changes in the last 24h? I can't reproduce the problem today.

Incidentally, I see there is a neat new feature which now groups overlapping markers together on a dynamic map so that just one round orange disc with a white plus sign in the centre is displayed (example here). -- Alice^✉ 05:42, 23 May 2014 (UTC)

The error is due to the last automatic synchronization, yesterday at 9:30 11:20 UTC. Some data for the English version were transferred only partially. On the WV-ev-Server (original scripts) everything works properly [25]. Please wait for next synchronization. -- Joachim Mey2008 (talk) 09:07, 23 May 2014 (UTC)

OK. May I ask how often those automatic synchronizations take place? Once a week? ϒpsilon (talk) 09:11, 23 May 2014 (UTC)

Current settings is to update on 11:20 (UTC) every Monday and Thursday. But I'll ask an administrator to an additional manual synchronization, as soon as possible. -- Joachim Mey2008 (talk) 09:31, 23 May 2014 (UTC)

The update has been corrected by User:Zhuyifei1999. Thanks! -- Joachim Mey2008 (talk) 15:37, 23 May 2014 (UTC) (if applicable [26])

Thanks for the update, User:Zhuyifei1999 and for keeping us informed, Joachim. I encountered the same problem on 6 different machines at 5 different hotels here in Entebbe this afternoon from 12:00-17:20 UTC. -- Alice^✉ 17:44, 23 May 2014 (UTC)

I'm not sure what happened, but as far as I know nobody did anything manually since April, except for the automatic updates. I saw an email just now and did a manual update without knowing this has already been fixed. --Zhuyifei1999 (talk) 04:57, 24 May 2014 (UTC)

Fixed (at least for me) thanks a lot :-) Nicolas1981 (talk) 06:07, 26 May 2014 (UTC)

Update this page?

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

No, {{mapframe}} is just one method. We also use static maps and {{geo}} tags. K7L (talk) 19:07, 9 August 2014 (UTC)

Um, well, yeah. I don't disagree with that at all, K7L. The point was that we could archive all those things that we don't use and haven't even experimented with in ages, of which there are many, and use this page to organize around current challenges instead. Don't you agree with that? Texugo (talk) 02:55, 15 August 2014 (UTC)

Print versions

Swept in from the pub

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

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

Print and PDF functions are not perfect in Mediawiki. Background colors (POI numbers) and embedded windows (dynamic maps) are not printed. - I use the browser's print function instead (Firefox, IE, Chrome). Page setup: background colors on, landscape. PDFs (see example) I create with a PDF printer driver (e.g. Foxit Reader's PDF Printer). -- Joachim Mey2008 (talk) 05:57, 12 June 2014 (UTC)

Thanks for the tips, I figured out so of my own as well. That said, if we have explicit links to "print version" and "make a PDF", we should make them work or disable them and agree that for the time being we do not explicitly support printing. Oh, and the banners don't print either. Can we rectify this ourselves or do we need to raise that higher up with at the Meta? PrinceGloria (talk) 06:14, 12 June 2014 (UTC)

No, we have no control over PDF rendering. Of course, you can raise this issue at Meta, but you will have to be very persistent about it, because nobody touched the PDF module in the last few years. --Alexander (talk) 07:54, 12 June 2014 (UTC)

I don't think your edit summary is appropriate - we actually CAN, and you said what we can. I would hate for it to be "me" rather than "us" though, I sure hope I am not the only seeing this situation as bad, but one that can be changed. If nothing was done about the PDF module for years, then the potential that something CAN be done is actually quite big. PrinceGloria (talk) 08:04, 12 June 2014 (UTC)

Well, I am sure that your request will gain some support. The problem is that PDF's can't be tuned by standard editing tools that are accessible to admins. It is something about the PDF extension, so you need programming skills and eventually you have to add the modified PDF extension to the new MediaWiki release. We don't have people with the necessary experience and personal connections to code developers, except for, perhaps, Roland on de:

I think that the best strategy is to raise this question on some bigger Wikipedias and see whether people with strong technical expertise want to work on it. For example, one crucial technical issue is to make PDF converter recognize CSS styles. This will solve our problem with the POI numbers that are currently missing in PDF. --Alexander (talk) 08:15, 12 June 2014 (UTC)

Maybe a simpler approach:

# Take a screenshot of the Dynamic Map and save it as a static file

# Use this file instead of Dynamic Map in the Print View

# Profit?

Obviously you restrict yourself to one zoom level, but it is more acheivable. --Andrewssi2 (talk) 08:21, 12 June 2014 (UTC)

This is just admitting defeat - I print my dynamic maps as screenshots for my own purposes, but we shouldn't have to update screenshots everytime an article gets edited to have an up-to-date print version. I will raise that at Meta in due course, I am sure there are many people with appropriate programming skills in the Wiki community. PrinceGloria (talk) 08:25, 12 June 2014 (UTC)

Updating a screenshot isn't too difficult. The real problem with printing dynamic maps is that there's no way to expand the marker clusters once you've printed the map, leaving some POIs hidden beyond usability. I wonder if it would be possible for a full page to be added at the end of the print version showing an auto-generated screenshot of the dynamic map at the automatic zoom level? It wouldn't completely guarantee a lack of marker clusters, but it would reduce them as much as we can hope for.

Regarding your question above about including banners in the print version, I'm pretty sure it would be as simple as deleting <div class="noprint"> and the corresponding </div> tag from the {{pagebanner}} template (or, alternatively, we could move those tags so the banner prints but the table of contents doesn't) if there is consensus that the banners should be included in the print version. I would support the idea, since the banner is often an important image with no equivalent anywhere else on the page.
Thatotherperson^talkcontribs 02:30, 13 June 2014 (UTC)

This is a double-edged sword - there usually is one or more outlying POIs for every city/district article (except for small, well-formed districts that lend themselves well for mapping), which would lead the automatic function to zoom out and leave most of the POI-dense area and unlegible sea of yellow pluses somewhere near the middle of the map. That would not serve the traveller well either, or even less. I would trust the collective users' intelligence in formatting the map for online display and print by selecting which POIs to show, what zoom level to adopt and where to cut off the map, better than an automated solution.

Further on automation - do note that we deliberately made adding and editing a POI very easy in hope of having as many editors as possible jump in. This means that POIs are often added actually wrongly and with incorrect coordinates. We even discussed recently with User:Ikan Kekek how our own geolocation tools end up locating POIs in wrong cities (even if with correct street addresses, but this isn't much help) as we could two Berlin restaurants auto-located in Zurich and Leipzig (one each). Given that every new edit may change that, the numbering of POIs etc. and that direct edits to POIs are on the rise, I find generating a screenshot version of the map something impossible and quite pointless (we would be almost always guaranteed to have an outdated version of the static map that doesn't match the article).

If anything, we may want to ask Joachim to add a feature that not only indicates the existence of POIs outside of the map range, but also marks the POIs on the map's edge with icons, colours and numbers and maybe even distances. But until then, I believe the map does a fine job of letting people know there is something outside the map's scope, and the POI description also should make a mention that something is farther away. PrinceGloria (talk) 03:26, 13 June 2014 (UTC)

Supposedly, a POI that's slightly off the map is indicated as a semi-transparent blue semicircle at that edge of the map. For instance, Oswego#Get around shows this in the lower portion of the right-hand edge as an Oswego Speedway (Do:1) at the edge of town is off-map. A pair of restaurants (Eat:1,8) which are barely in the visible map area appear to also trigger this. There is no one position in which the on-page inline map shows every POI clearly without either clustering (+) or pushing a few off-page, and Oswego (pop 18000) is one of the easier, more palatable choices as a reasonably compact city. A large city (if not broken into districts) would be more difficult, but that's not the only issue. For sprawling Lac-Mégantic (pop 6000) all I can say is "bonne chance" as the tourist area wraps around the lake into the rural countryside and includes a pair of provincial parks 20-30 miles (30-50km) distant. Radiator Springs is worse, as that's an itinerary; even if it only covers half the main Route 66 beaten path, that's still 1200 miles from Baxter Springs to Peach Springs. (There's no map on our main US66 itinerary yet.) There's no map on our Underground Railroad article, but with multiple routes (anything from Ohio to Pennsylvania) and multiple POIs on each, they'd never all fit at once. Trans-Canada Highway would be the extreme case, no dynamic map, no POIs as the article scope is ridiculously the entire country so little or no detail can be provided at the local or regional level in such an overview.

A static map for a city with a static inset for downtown would be typical for a large city description in a standard printed guide. There is no one dynamic map view which fits everything without some scrolling, zooming and manipulation that isn't available in print. It's not just Wikivoyage, good luck taking something like http://ridewithgps.com/routes/3705636 and finding one view that fits a 170km cycle trip on back roads but still has enough detail to even see which roads are being taken? Couldn't see one, and bringing a laptop PC on the road isn't an option if that map was intended for cyclists. K7L (talk) 17:29, 13 June 2014 (UTC)

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

Bug report for print version?

Would it be worth opening a bugzilla: item? Issues with the MediaWiki code (or an extension) are more likely to be seen by developers there than in meta:. K7L (talk) 13:58, 12 June 2014 (UTC)

What you are asking is technically challenging, and as an IT person I would really categorize this as 'High cost, low benefit' when evaluating the value of developing this feature.

By all means raise a request in MediaWiki. I would just suggest that you may want to consider other options in the meantime that are lower cost. Andrewssi2 (talk) 15:12, 12 June 2014 (UTC)

MediaWiki software does need a good PDF converter. It will be useful even for Wikipedia, let alone other (non-WMF) sites that are using this software. The problem is that technical efforts are often spent for useless things such as new fonts or MediaViewer, so indeed, we can hardly expect any technical improvements unless we know people who are both interested in the PDF feature and can implement it.

Anyway, a bug request will not hurt, so anyone willing to submit could should mention the following crucial features of the PDF converter:

• Render CSS styles
• Control the inclusion of images (ideally, one should be able to decide whether images are included at all, and if they are, which of them should be included)
• Render iframe environment

--Alexander (talk) 16:43, 12 June 2014 (UTC)

Guys, would any of you familiar with Bugzilla be willing to file the above bug? I would like to concentrate on addressing the Meta this weekend. Let's push for it on all fronts, loudly and repeatedly, and we will be heard. PrinceGloria (talk) 20:39, 12 June 2014 (UTC)

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

Andre, you may be surprised, but on a train between Moscow and Saint Petersburg, which are two biggest Russian cities, you will find only sporadic internet connection. And if you try to read a travel guide from your smartphone or tablet in a smaller Mexican city, you will simply lose your favorite gadgets (at best). So printed travel guides remain a must for those people who really travel and not just visit popular tourist destinations. It is also important that the printing option does not hamper any "technological advances". However, both on-line and off-line versions must be developed in parallel. --Alexander (talk) 18:56, 12 June 2014 (UTC)

Further on this - while I find the "gotta mind the print version users" as abused as "gotta mind the people with low bandwidth" argument to throw stones into the cogs of progress, I believe the print version continues to be very relevant even in the digital age. Not only is it useful in places with scarce Internet connection - I tend to have a phone online all of the time with me, and generally travel with at least one laptop, but running around a new city with an open laptop is not an option, and mapping out my route using a mobile version of Wikivoyage would be a folly. I always carry a printed version of the guide I need, with my handwritten comments, directions etc. on it, which I can fold into my pocket and consult wherever I find myself. The print version is an important aspect of Wikivoyage and we should pay it appropriate heed. PrinceGloria (talk) 20:39, 12 June 2014 (UTC)

Yeah, I don't think the printed version should be paramount, but there sure are areas with no cell phone or Wi-Fi signal at all, including a very long stretch of central California coast. Ikan Kekek (talk) 21:11, 12 June 2014 (UTC)

One of my long-term goals is to improve the handling of printable versions of our guides. WTP had a pretty decent engine; it had its flaws but it was much more flexible and customizable than the current. I will say, however, that printing dynamic maps may always be problematic simply due to their dynamic nature. I would certainly not support ignoring print versions simply because dynamic maps -- which are still an in-development, somewhat experimental feature -- were added without thinking of the print impact first. Powers ^(talk) 21:27, 12 June 2014 (UTC)

Did WTP use a custom MediaWiki extension? Who developed it, who may have the code, and how does the code look like? --Alexander (talk) 22:08, 12 June 2014 (UTC)

Alexander, I believe Jani is the only one still here who knows about the printed guides. ϒpsilon (talk) 12:39, 13 June 2014 (UTC)

I don't own a smartphone or tablet. On some recent trips I have taken no computing device and used no internet. In Addis Ababa I visited two internet cafes but neither had any connection at the time. I only had what I printed before I left home. Just saying. Nurg (talk) 11:23, 13 June 2014 (UTC)

In many parts of the world there you can indeed not get online anywhere you wish. Also, it's not always a smart idea to flaunt a laptop/tablet/smartphone maybe worth four months' local salary. I now and then print out travel guides (4 pages on an A4 + cut & staple makes a good palm-sized travel guide that doesn't mark you out as a tourist on the street) and for me they work well as they are now. ϒpsilon (talk) 12:39, 13 June 2014 (UTC)

WTP used a standalone engine unrelated to Mediawiki; it took the supplied articles as plain wikitext and parsed them to produce LaTeX output, including automated ToC, page headers, and indices. Manual index entries could be produced via Template:Index. Internal links automatically became page references within the book; external links were automatically expanded in-line. Images could be set to print as two pages, as a full page, grouped with two per page, floating within the text, or as the lead image... just by changing a keyword in the File tag. The LaTeX was then used to generate a printable PDF. The output format (about 5"x8", two columns) was ideal for travel. Powers ^(talk) 13:41, 13 June 2014 (UTC)

LaTeX sounds great. A stand-alone thing could also work for us if WMF is not interested in improving their own PDF extension. But the question is: who was involved in WTP, and who may have the code? Is it only Jani? I believe we had quite a few old admins on the old (pre-migration) mailing list. Some of them might be accessible by e-mail even if they no longer contribute to the project. --Alexander (talk) 15:01, 13 June 2014 (UTC)

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

Thanks! Good to know! --Alexander (talk) 11:12, 23 June 2014 (UTC)

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

Bugzilla

Tracked in Bugzilla
Bug 68008

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

We don't have an ideal example. Three main features that I can envisage are as follows:

• Render CSS styles
• Control the inclusion of images (ideally, one should be able to decide whether images are included at all, and if they are, which of them should be included)
• Render iframe environment

--Alexander (talk) 16:03, 13 June 2014 (UTC)

Ah, I meant an ideal example of the problem, so that any interested dev could easily look at it and see that it's broken. WhatamIdoing (talk) 16:18, 13 June 2014 (UTC)

That's easy. Go to any page with POI markers (say, Berlin/Mitte) and click Download PDF to see that the PDF file is missing the map, all POI markers, and the page layout is anything but ergonomic. --Alexander (talk) 16:55, 13 June 2014 (UTC)

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

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

Do you have any links to more information on this PDF tool replacement, WAID? I'd like to get involved in its development. Powers ^(talk) 22:50, 14 July 2014 (UTC)

All I've seen is this: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077516.html WhatamIdoing (talk) 21:00, 15 July 2014 (UTC)

Alexander,

There's a question at bugzilla:68008 about why someone might want to exclude images. Do you have something in mind beyond the obvious "people might not want to bother downloading/printing them"? Whatamidoing (WMF) (talk) 17:20, 17 July 2014 (UTC)

Thanks for posting our request on bugzilla. I added a comment there, although it is pretty obvious indeed. --Alexander (talk) 18:22, 17 July 2014 (UTC)

Dynamic map templates

Swept in from the pub

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

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

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

Position of dive sites not shown on dynamic maps

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

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

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

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

Can you provide an example? When I open a map full screen (by clicking on the icon) then it shows the position of each geo-encoded listing in the article.

Also although dive sites are at sea, are they not often relative to a coastline? Andrewssi2 (talk) 09:54, 19 August 2014 (UTC)

The dive site itself is not in a listing when the whole article is about the dive site, However Joachim Mey has shown [29] me how to add a zoom and layer to the template, which does the job. • • • Peter (Southwood) ^(talk): 12:40, 19 August 2014 (UTC)

Marker types in dynamic maps

Swept in from the pub

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

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

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

To be honest, I think we are overdue for a discussion about how dynamic maps should be used in region articles in the first place, and in particular, the marker icons of {{marker}} which go beyond those used for the listing-based markers. The "city marker type" is something that was put in there by User:Torty3 when he created the template, and I believe it escaped the attention of most of us and was never in fact discussed how or when or if it should be used. (The same for the go, view, and vicinity types, which I didn't even know existed until I looked at {{TypeToColor}} just now.) There are some concerns I think we should discuss regarding use of markers in region article dynamic maps, including the question of whether we want the typical one-liner lists in the Cities/Other destinations/Go next sections to become numbered lists (which may give the impression of a ranking), the fact that the map is often already showing the cities and the icons actually obscure them (I've definitely seen some region maps somewhere where practically all the cities were already represented but icons were superimposed anyway), and the fact that some region articles also contain listing types, so the map ends up with a mix of icons of different magnitudes, i.e., for single attractions and for whole cities. There is also the question of whether it would be better to use the OD layer which automatically shows pointers for places we have an article for, instead of manually placed POIs. I've seen this in use in some articles too.

We currently have 82 region articles with a dynamic map. I think we should call a moratorium on new ones for the time being, look carefully through the existing ones and see what has been tried, what can be done, what problems and issues there may be, what improvements can be made, etc., and then talk about how we should be implementing these for region articles, so that we can do it in a consistent manner we all agree on. Texugo (talk) 03:08, 10 September 2014 (UTC)

I think that superimposing (the current way it is done) is the correct thing to do for now. OSM often does not show city names, sometimes showing the name of smaller things instead, so we are on the safe side with showing it. And since it is cited in the article, it should be clearly visible as a marker on the map. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)

I suggest we all analyze Western Finger Lakes in depth, take note of all problems, find ways to fix them, make it optimal, and use it as a base to decide what we want for the other articles. Nicolas1981 (talk) 03:34, 10 September 2014 (UTC)

I looked at Western Finger Lakes for 5 minutes and have not found any problem. The area is highlighted, there is minimal superimposition, points are sufficiently far apart from each other, it gives a good sense of how one could tour the area. Nicolas1981 (talk) 03:42, 10 September 2014 (UTC)

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

I think we should look at more than Western Finger Lakes. It's a fairly rural area without a lot of destinations on the underlying map, so it's less likely to cause problems. Texugo, can you point us to some examples where the map already shows most of the destinations? The maps I've seen to date are more like Western Finger Lakes so the markers were necessary to make the map useable. -Shaundd (talk) 14:55, 10 September 2014 (UTC)

"minimal superimposition" is still a problem. There should be none. Powers ^(talk) 20:06, 10 September 2014 (UTC)

Slightly off topic -- marker template has an image argument -- would it be worthwhile to incorporate an image argument in the listings (see do etc.) template as well? -- Matroc (talk) 02:49, 11 September 2014 (UTC)

Do you mean that in the Sleep section, instead of small numbered squares you would have small numbered houses? I would say why not, it makes it very visual. Printed guides actually often have this house logo repeated for each hotel, even though the reader could understand that it is a hotel just by looking at the section header. 58.156.2.18 06:02, 11 September 2014 (UTC)

I was thinking more on the line of when you click on a numbered location on a map for a museum or cathedral etc. - a pop up image of that museum would appear... one can put an image in using the marker template but I don't see that option in the listing template... (numbered house icons sounds interesting though...) Matroc (talk) 06:23, 11 September 2014 (UTC)

Simply add the image= field and provide the filename. The picture will be shown in the pop-up window. We have been using this option in other language versions since ages... --Alexander (talk) 09:52, 11 September 2014 (UTC)

The image discussion should probably be separated off from this one, but it probably does need to be discussed be too before we start running with it, not least because having a listing image field in the buy/eat/drink/sleep sections would seem to encourage photos of businesses and we don't have any clear consensus to allow a blanket exception to our image policy against photos of businesses.

Back on topic, to answer your question, Shaundd, some examples of what I consider very problematic are

• Wasatch Range - fills the map with icons that largely obscure the city dots, labels, and routes of the map
• Sonora - most cities on the map are labelled, but obscured by the blue icons
• Western Nevada - obscures the city dots and labels that would otherwise be visible, groups some cities with a plus so one has to zoom in to see them anyway (and if one is zooming in anyway, why not just consider the more accurate and well-labeled info that's already on the map?)
• Nine-County Region - of the 20 cities with icons on the map, 13 of them would have a visible label if there weren't an icon blocking it
• Southeast Arizona - uses the automatically displayed destination pointers, some of which block their own labels, and in combination with regular listing icons, some of which are grouped under little pluses meaning that the user has to zoom in 4 steps anyway, just to resolve them
• Kathmandu Valley - also mixes regular listings with destination points, the two types overlapping each other as they try to point out everything from bus stops to individual attractions inside the cities, while also trying to show markers for the cities themselves

Like LtPowers, I don't really think we should be overlapping and blocking the stuff that's already on the map, and to be honest, I'm not very convinced of the need for city markers at all. The info is already on the map, even if you do have to zoom in a bit, and as the articles above show, putting city markers doesn't necessarily save you the need to zoom in to see what's going on anyway. Plus, many of our bottom-level region articles have 15-25 cities linked, and putting all those on the map really obscures a lot. I rather consider city markers to be pretty much redundant, given the high chances of the user having to mess around with the map anyway just to determine exactly what points on the map the comparatively large icons correspond to. One more feeling I have is that while I like the way we use icons in our city maps to supplement the information that's on the map with attractions, etc., using the same approach to superimpose icons on top of the cities that are already on the map at some level tends to disproportionately emphasize the cities aspect of the region, de-emphasizing the contours of the transportation systems, the landscape, the shaded park borders, and the other aspects that should make region maps less point-oriented. I'm also not a fan of the way it turns our one-liner city lists into numbered lists; I think it may give the impression of being a ranking. Texugo (talk) 22:52, 11 September 2014 (UTC)

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

Thanks for the clarification. Sorry I didn't get it right the first time! So wow, those got slipped in more recently than I thought. It appears that User:Thatotherperson is also responsible for a good chunk of the instances of it use, especially region articles across the southwest US. This should have been a more limited experiment brought up for discussion. Texugo (talk) 03:12, 12 September 2014 (UTC)

In the interest of full disclosure, I use "Go" markers in the Buffalo district articles for subway stations, the Greyhound station, the Amtrak station, rental car facilities, and one or two other transportation-related listings, and I also use the "City" argument in inline markers (using Template:Marker) for neighborhoods within each district as described in the "Understand" section. If we decide to disallow these types of markers, I would prefer to have a method of pinpointing these items on a dynamic map other than the undifferentiated "Listing" marker. -- AndreCarrotflower (talk) 03:03, 13 September 2014 (UTC)

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

Well said! --W. Frank^email_talk 09:44, 13 September 2014 (UTC)

I was completely unaware of the first conversation there and think such a change should have had wider exposure and an experimentation period.. The second 'proposak' you linked to was tangential to the discussion and not really addressed or even carried forward to the end of the discussion. We've never had a policy that "every town must be on a map somewhere", and every town is both already on the map at some zoom level and already linked from its own town page.,. I'll stand by every one of my points above... City markers are a very problematic solution to something that is not necessarily a big problem. Texugo (talk) 12:35, 13 September 2014 (UTC)

Where did I say that the built-in labels were sufficient? Also: "a map is a terrible place to choose looks over the presence of more information" could not possibly be more wrong. A bad-looking map is worse than no map at all. Powers ^(talk) 19:00, 13 September 2014 (UTC)

I think that, perhaps unwittingly, you may have crystallised a fundamental difference between different world outlooks. Some of us feel that the perfect should not necessarily be the enemy of the possible and the practical. This camp vehemently disagrees that a "bad-looking map is worse than no map at all". Now don't get me wrong, a well drawn map is a thing of beauty - but it also should be of practical use. Let's strive to make dynamic maps less ugly - but not at the expense of utility or having them at all. --W. Frank^email_talk 19:12, 13 September 2014 (UTC)

I agree with you that a bad-looking map is better than none, but only as long as it's clearer than no map. A map which is unreadable or more confusing than just reading directions might be worse than none. Ikan Kekek (talk) 19:26, 13 September 2014 (UTC)

I think a map would have to be *very* unclear before it’s worse than no map at all, and IMO, none of the examples cited above are worse than no map. I agree the city markers are problematic — they obscure information in the base map, the yellow pluses mean you have to zoom in, they’re not pretty and I don’t like the number lists — but to not have some kind of marker means our readers have to find destinations on their own. Is Little Town in the upper left, maybe the middle, or perhaps the bottom right? Nope, let’s zoom in another level and repeat. Still nothing, let’s zoom in again. Oh wait, now I’m so zoomed in I’m not sure I’ve covered the whole region. Sigh. Like many of these map discussions there’s an element of personal preference, but having no city markers seems to have a high potential for a poor user experience.

The background details on the OSM maps are nice, but at the end of the day, we write guides to destinations and people come to our site (I hope!) primarily to read those guides. If there is one thing I think our bottom level region maps should do, they should make it easy to locate those destinations we write about. Hopefully the dynamic maps can continue to evolve and improve (or, even better, people develop a sudden infatuation for Inkscape and produce bucket loads of beautiful static maps :-) ), but in the meantime I think superimposing city markers is a lesser evil than obscuring some of the background OSM detail.

I noticed some of the maps had listing markers and city markers on the same map. I thought we weren't supposed to have listings on regions pages? I fully support moving those markers off the region maps. -Shaundd (talk) 23:04, 13 September 2014 (UTC)

LtPowers, I may have confused your comments with Texugo's. I thought it was you who said the map at Sonora already had labels for most cities.
Thatotherperson^talkcontribs 02:53, 17 September 2014 (UTC)

No, my only comment prior to yours was to indicate that a good map should never have overlapping labels. Powers ^(talk) 17:10, 17 September 2014 (UTC)

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

Good points.

But an "inferior" dynamic map is still usually better than no map at all.

It's a sad fact that we have a limited number of editors able to draw good static maps. --W. Frank^email_talk 20:27, 14 September 2014 (UTC)

I disagree regarding there not being any use for dynamic maps on region articles – some regions are very sparsely populated, with attractions often many miles from the closest 'city', which may have absolutely nothing of interest and no facilities for travelers, thus not warranting an article. One such example is Dhofar, another is Southeast Arizona. Also after having traveled to some places where no maps are available anywhere, I do think a 'bad' map is better than no map at all. –StellarD (talk) 18:58, 15 September 2014 (UTC)

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

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

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

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

That is certainly not what I thought this conversation was about. I am perfectly happy to have dynamic maps in regions articles, especially when they have a mapmask to outline the region in question. But I think treating region maps they way we treat city maps is extraordinarily clumsy at best. Putting up to 40 point-based icons on the map for things that are not actually the same size, type or importance, covering up the more sensibly-scaled and labeled way that a dynamic map handles the same information - it's just a waste and a serious detraction from what a region map is supposed to be: an overview. The dynamic map uses different sized points and fonts to represent cities of different sizes and importances and doesn't try to squeeze every single destination on there with big identical shapes. A region article is supposed to give an overview of the region, leave the gritty details like addresses and phone numbers to the city articles; we don't insist that the city list should give the pronunciation or website or tourist center for every city listed — when a reader needs that info, they click through to the city. Similarly, a region map map should also give an overview — showing a handful of the cities, showing the major transportation routes, etc., not trying to include the geo detail of everything we have an article for. The solution for someone not seeing the destination they are looking for on the map is very simple - go to the article and look at the map there. There is absolutely no reason to crowd our region maps with blocky icons that obscure stuff when the gritty details should be left to the city articles. Texugo (talk) 21:53, 15 September 2014 (UTC)

My intention was not to hijack the discussion and send it into a different direction. Some of the points that have been made touch on a larger issue that has been festering in my mind for some time. As for your concerns regarding dynamic maps in region articles, Texugo, I agree with you, but I see that as more a matter of listings policy than of map policy. Any items other than City markers that clutter up a dynamic map in a region article are reflective of listings in the body of the article that shouldn't be there. That would be a policy violation whether or not the article had a dynamic map. -- AndreCarrotflower (talk) 22:09, 15 September 2014 (UTC)

Three of the regions with dynamic maps are Scottish islands that have no cities (Tiree and Islay) or only one city (North Uist). I don't see any of these having more city listings soon. Islands naturally form a region that can be much smaller than we would normally use, and we have not been consistent about whether to call these cities or regions. AlasdairW (talk) 23:15, 15 September 2014 (UTC)

AndreCarrotflower, but the city markers are themselves clutter, and if we were to start "ensuring that every destination article appears on a region map somewhere" as has been suggested, there will be quite a lot of maps with 25-40 city/other destination icons blocking much of the most important parts of their respective maps.

AlasdairW, all three of those island articles should be using a city template and not a region one, since that is the prevailing manner of dealing with standalone island articles. I have changed to the first two to cities, and marked the third one for merging with its one city — an island 20 miles across with 2000 people and a smattering of attractions can easily be covered in one single island-as-city article. Texugo (talk) 23:36, 15 September 2014 (UTC)

Texugo, I fail to understand how city markers are "clutter" on dynamic maps while dots with place names next to them are fine on static maps. As for bottom-level regions, if they contain 25 to 40 cities that's a pretty good indicator that they need to be subdivided. Also, parenthetically, I think we need to rethink the policy that says all destinations within a bottom level region need to be included on their "cities" subsection. It strikes me as pointless and inherently in conflict with our "Wikivoyage is not the Yellow Pages" non-goal. -- AndreCarrotflower (talk) 00:41, 16 September 2014 (UTC)

They are clutter because they exist in addition to the dots and labels that are already on the map. They are clutter because they jostle with each other unpredictably over the top of roads and contours and labels that would be better shown. They are clutter because they show the tiniest village the same size as the largest city when the underlying dynamic map underneath handles that information in a much more sophisticated manner. On a static map, or even on the dynamic map without icons, the dots and labels are arranged so that they don't interfere with one another, and not so many are shown at a given zoom level that it becomes unnecessarily distracting.

And it's not the right thread to discuss it, but not listing destinations in the bottom level region is not a good idea at all - that would just make it where a person investigating a given region cannot be sure they've found all our coverage unless they scour every article looking for sideways links to articles that have been left out of the hierarchy. Texugo (talk) 02:33, 16 September 2014 (UTC)

Would it be possible to develop a different kind of feature for each city listing which would, without reloading the whole page, re-center/re-zoom the mapframe to the given city? I think it would pretty easy in html, but I don't know about making it work here. Texugo (talk) 02:38, 16 September 2014 (UTC)

Texugo, six months ago you argued against the use of locator maps on this site by saying the following: "...city articles get a map for getting around within the city, region articles show maps for getting around within the region; any maps showing wider placement within the surrounding region belong in the next level up in the hierarchy...". That exact philosophy is the reason it's important to have comprehensive maps with every destination on them in lowest-level region articles. Otherwise we're pushing regional information, like the placement of cities within a region, into the city articles. I don't see how we can say that the lowest-level region articles are overviews when the articles below them intentionally leave large coverage gaps between the populated places with hotel accommodations. If we write the lowest-level region articles as overviews and push all detail into the city articles, then we're essentially trying to divide up the whole globe as a set of cities and their vicinities...at which point the cities become the new lowest-level regions. What is so terrible about the lowest-level region articles resembling city articles and the overviews being written as higher regions?
Thatotherperson^talkcontribs 02:53, 17 September 2014 (UTC)

That is taking me far out of context there. I was talking about static locator maps in that conversation, and I will still argue that we do not need those in every region article or every city article, etc. And dynamic maps even further eliminate any need for that kind of thing, allowing that information to be checked at the roll of a scroll bar. And in any case, I did not and would not insist that we should attempt to try to cram all the destinations for each bottom-level region onto a single map. But seriously, I do not see how anyone could think sticking 25+ icons on a map produces an advantageously usable result. You still can't glean information from that map without interacting with it anyway, and to even get an idea of how the cities are laid out, you have to either click on every icon or or cross-reference every one of them with the city list to tell what's next to what. That does not remotely constitute any advantage worthy of blocking the otherwise clearly legible information that is already on the map. As for the rest of what you've just posted, it sounds like you are proposing a fundamental change to the existing policy of discouraging listings from region articles or something, which would require a whole other discussion for us to address. Texugo (talk) 03:13, 17 September 2014 (UTC)

I don't see how I took your comments out of context. I know you were talking about static locator maps, but that discussion and this one both invoke the same basic question: if a reader wants to use Wikivoyage to learn the location of a destination, where should they look? If it's the region articles, then we need city markers. If it's the destination articles, then we either need a scrollable dynamic map on every one or we need a way to make the geo tag function noticeable to the average reader.
Thatotherperson^talkcontribs 04:40, 19 September 2014 (UTC)

But files on Wiki Commons can indeed be protected from unauthorized edits. This is the case for e.g. many featured pictures. -- Horst-schlaemma (talk) 11:51, 17 September 2014 (UTC)

Numbered icons on article page not matching numbered icons on a map!

Swept in from the pub

Insure that listings of each type have both a latitude and longitude or both arguments are blank.

Everything will appear to be numbered correctly on an an article page (naturally the entry missing the long= argument

will not be numbered). However, here is the kicker: numbered icons after that entry missing the long= will

be increased by 1 on the map... For example: entry 5 on article page will be 6 on a map etc.

Example: - click on the icon numbered 5 for Gokoku-ji.. Hope that helps! Cheers! Matroc (talk) 02:57, 13 September 2014 (UTC)

To verify the coordinates of new listings please click the button 'map center <==> all markers' after saving. POI with incomplete coordinate pairs will be visible and may be corrected. - For further testing, you can use this script [31] . -- Joachim Mey2008 (talk) 07:17, 14 September 2014 (UTC)

Thank you! - hopefully this will assist anyone having this issue and send them in the direction of correcting a listings latitude and longitude information... Matroc (talk) 07:55, 14 September 2014 (UTC)

I think we should remove coordinates of POIs missing either latitude or longitude. Anyone disagree?

To start doing this, just open the latest CSV at http://datahub.io/dataset/listings/resource/15f9e529-22e3-4862-9a0a-ff77692c789d open it in LibreOffice or Excel, sort by latitude with sub-sort on longitude, and you will find them. I actually just did this sorting and saved the erroneous coordinates (and their article/POI name) here: http://datahub.io/dataset/fixes/resource/b8294c35-4829-45b0-aea5-39f2dde958a9 There are 103 to fix. Cheers :-) Nicolas1981 (talk) 07:06, 18 September 2014 (UTC)

Have downloaded the list and will update coordinates if possible, otherwise clean them up at my leisure. Matroc (talk) 23:22, 18 September 2014 (UTC)

Done - These have beeen taken care of! - Matroc (talk) 00:38, 20 September 2014 (UTC)

Does that mean that the lot of the stuff at User:Nicolas1981/Syntax checks can be deleted from the list? Nurg (talk) 04:11, 20 September 2014 (UTC)

I do not believe so as this is a slightly different issue, so No - Best to get Nicolas1981 to answer that question... - Cheers! Matroc (talk) 03:09, 21 September 2014 (UTC)

Legend on left hand side of maps no longer visible?

Swept in from the pub

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

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

Map Coordinates

Swept in from the pub

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

Coordinates are entered as strict decimal values not minutes and seconds. The number after the decimal point is not minutes and seconds but the decimal fraction of a whole degree. You will need to convert the number or use a tool that give the value just in degrees. --Traveler100 (talk) 05:56, 5 October 2014 (UTC)

You can use this conversion tool: http://www.fcc.gov/mb/audio/bickel/DDDMMSS-decimal.html --Andrewssi2 (talk) 08:34, 6 October 2014 (UTC)

Or go to the Wikipedia article for the place (usually our article will have link in the sidebar) and click on the co-ordinates shown on the upper right. That gets you to a page where second line is, e.g. for Xiamen, "24.479836, 118.089419". Copy that into your geo tag, changing the comma to "|". Pashley (talk) 13:12, 6 October 2014 (UTC)

Not a great example, unfortunately, since those coordinates (even the DMS coords on the Wikipedia article) are far too precise. Powers ^(talk) 20:33, 6 October 2014 (UTC)

I use this tool: www.geoplaner.com. Try it, maybe you like it. --Bernello (talk) 20:47, 8 October 2014 (UTC)

But what if an average user wants to modify the "price=" in a sleep listing and sees the empty "lat=" and "long=". In "Google Earth" he had already stored a marker to his hotel, so he copies the lat and long data in degrees, minutes, seconds format from Google Earth to wikivoyage, and sees the unexpected result. How does he know what he did do wrong? I think it is not correct how this is handled by the template. --FredTC (talk) 10:56, 9 October 2014 (UTC)

It'd be nice if the template would recognize the format automatically. This may mean some tricky coding, but it is already done at Wikipedia (format deduced from number of parameters). The conversion is quite easy, even by hand (or by pasting into a calculator), but still unnecessarily cumbersome – especially while on the road. Any thing non-numeric should give a clear warning. --LPfi (talk) 13:40, 9 October 2014 (UTC)

Coordinates all messed up

Swept in from the pub

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

You have not done anything wrong, known problem with the geo data, bug has been logged. BTW, impressive amount of data added in short time to the article, nice job. --Traveler100 (talk) 12:05, 31 October 2014 (UTC)

The simplest way to solve this problem is to remove the #iferror statement. If there is really an error you will find the page in a maintenance category defined in MediaWiki:Geodata-broken-tags-category and you can check it. --RolandUnger (talk) 12:40, 31 October 2014 (UTC)

Thank you all! --Iopensa (talk) 13:05, 31 October 2014 (UTC)

For the records, messed up coordinates when search has problems should not happen anymore: according to bugzilla:72559 GeoData will not be disabled completely anymore if CirrusSearch is having problems. --AKlapper (WMF) (talk) 09:22, 3 November 2014 (UTC)

Map thumbnails not showing properly

Swept in from the pub

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

yes since yesterday. --Traveler100 (talk) 05:42, 1 December 2014 (UTC)

Oh, that's too bad. Ikan Kekek (talk) 05:51, 1 December 2014 (UTC)

I can't see the map embedded on the article page, just the numbers and plus signs as you described. Is this the same issue? --Andrewssi2 (talk) 07:36, 1 December 2014 (UTC)

I don't know what "tiles.wmflabs.org" is, but that's hanging on my browser when the map loads and apparently preventing the map background from displaying. -- Ryan • (talk) • 07:50, 1 December 2014 (UTC)

OSM-Mapnik tiles are loaded from the WMF-Labs-Server. This server is faulty at the time. Wikipedia also has no access. The PoiMap2 scripts were not changed. -- Mey2008 (talk) 19:28, 1 December 2014 (UTC)

I would add that we are obliged to use the unsteady tiles.wmflabs.org server because of privacy issues. There is no solution on our side. --Alexander (talk) 21:20, 1 December 2014 (UTC)

Consulates on maps?

Swept in from the pub

Do we want to put markers for consulates on maps?

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

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

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

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

One or two would be fine on the main map but 110 would be very annoying. A separate map would be a good idea, maybe in the case of locations with more than 100 a sub-page which would then have its own map. --Traveler100 (talk) 05:21, 3 December 2014 (UTC)

I think travellers looking for a consulate are looking just for one of them and only when wanting to go there. A map with all consulates is not necessary if you can get one with just the one you are interested in. I think this works with editing previews (just click the number, even if it does not yet show on the general map). Can it be made to work also generally? Otherwise a subpage is probably a good solution. For printed guides this is a bit clumsy. I would prefer to have my consulate on the general map. --LPfi (talk) 12:43, 3 December 2014 (UTC)

You don't need a special listing type, just the standard 'List' template. Top level articles for large cities won't generally have dynamic maps however.

I think a dedicated static map for consulates/embassies sections may be feasible. It would take more work than I'd be prepared to do though. --Andrewssi2 (talk) 10:36, 4 December 2014 (UTC)

Many capitals of minor countries, or secondary cities of major countries, have consulates and don't have sub-articles.

LPfi's idea is interesting, showing "my consulate" would require to enter my nationality(ies) into Wikivoyage, though. And actually when I travel I sometimes visit the consulate of the neighbouring country, to get a visa.

I think the ideal would be to not show them on maps, but still have the latitude/longitude in the listing, so that when clicked they show the clicked consulate. That would require some development though. That would not be visible on paper. Nicolas1981 (talk) 12:57, 5 December 2014 (UTC)

It's unlikely that a capital of a minor country would receive a consulate. Usually, a capital of a Commonwealth dominion rates a High Commission from fellow members of the great Britannic Empire, while any other foreign capital gets an embassy. A country normally establishes both embassy and consulate in the same foreign capital only if their diplomatic presence doesn't quite fit into one building, causing visa issuance, trade promotion or other consular activities to be split from the main embassy. K7L (talk) 19:35, 5 December 2014 (UTC)

I'm not sure what is being proposed. Is it just for articles that have no sub-articles? That would be a messy approach.

Also anyone needing a consulate/embassy is possibly in an emergency of some sort and should refer to the web site of their country's foreign department rather than WV. Embassies and consulates move and close all the time and the lists that we have in WV are probably not accurate. We should still list them, but not tightly integrate them into the WV experience.--Andrewssi2 (talk) 09:44, 6 December 2014 (UTC)

I think WV will be used more and more offline. A traveler in an emergency might have nothing but WV on paper, Kiwix, or saved webpages, although I would use an OpenStreetMap client. But I think a more general filtering option would be great. For example to produce maps and paper copies without hotels (if I already booked my hotels), only midrange restaurant (if that is what I can afford), only embassies and consulates for certain countries (between my wife and I we have a few options), etc. Elgaard (talk) 00:03, 8 December 2014 (UTC)

K7L: I said "consulates" but I meant "consulates+embassies", sorry for being unclear. So, yes, many city articles have no sub-pages and have a list of consulates/embassies. Karachi and Quito are a good examples. Nicolas1981 (talk) 05:23, 8 December 2014 (UTC)

Andrewssi2: I beg to differ: We should provide travellers with an up-to-date and convenient way to find their embassy/consulate or the embassy/consulate of the next countries in their trip. It is a common use case of a travel guide. Printed guides are not ashamed of listing them, even though they become out-of-date faster than us. Nicolas1981 (talk) 05:23, 8 December 2014 (UTC)

I have found the official databases for all embassies in Washington, D.C., and all US/Canada/Australia embassies around the world, so expect to have at least those up-to-date as soon as I write a script :-) Now if we could find such data for all countries other that would be great... Nicolas1981 (talk) 09:16, 8 December 2014 (UTC)

I did not say we shouldn't list embassies. I said "We should still list them, but not tightly integrate them into the WV experience". I still hold that position.

Even if you can find quality data for all embassies of all countries around the world (which I doubt), you still need to explain how it would be presented? London has something in the order of 150 listings for embassies, which is impractical for one map. Andrewssi2 (talk) 11:11, 8 December 2014 (UTC)

It's not only impractical, it's guaranteed to be 99% clutter: for any given traveller there is pretty much a predetermined absolute maximum of exactly two useful listings of this type, with only one in the vast majority of cases. This would automatically mean, in the above case, that 149 map icons would be no more than utterly useless clutter making the map hard to read. I don't know if it would be practical, but Nicolas1981 had the right idea above, about making it so you can see it on a map only if you click on it, etc. But showing them all on the maps is out of the question; in many cases they'd practically outnumber and obfuscate the Eat/Drink/Sleep listings, placing very disproportionate emphasis on a whole class of listings all but one or two of which could serve no possible purpose for a given individual traveler. Texugo (talk) 21:20, 8 December 2014 (UTC)

We could work on the layer system of the map control in order that the user has to specifically request to display the embassies, although 150 embassy dots on the map won't be that much help.

I also still need to understand how these listings would work on cities with sub articles. Would it require an additional dynamic map at the top level? What if an accepted static map already exists? Andrewssi2 (talk) 22:53, 8 December 2014 (UTC)

Andrewssi2's idea is ideal, a layers control would mean that only people who want to see consulates see them. Roma probably has nearly as many consulates as London, and a map of them is very readable: http://overpass-turbo.eu/?template=key-value&key=amenity&value=embassy (unzoom a bit and press "Run") That example map would be very usable if it had numbers. Consulates tend to be rather large buildings in the city center, which means that overlap is rather rare. Anyway, for now, how about we 1) Create a new listing type called "consulate", or any better word that encompasses embassies too 2) Filter out them so that they DON'T appear on dynamic maps. Cheers!Nicolas1981 (talk) 08:43, 9 December 2014 (UTC)

Interesting challenge... a name meaning both consulate and embassy. I wonder if consular_section would work? Typically when a traveller visits an embassy, they are not going to the office of the ambassador for diplomatic business (unless they are Julien Assange) but rather visit the Consular Section which is contained within the embassy and deals with things such as visas. Probably confusing to most people though. --Andrewssi2 (talk) 10:57, 9 December 2014 (UTC)

The experts have spoken: legation is a word that apparently encompasses embassies, consulates and similar. I suggest implementing this new listing type if there is no opposition? It will make dynamic maps lighter, as many have them shown as unclassified listings. The appropriate template will need to be created. I guess the listing editor would need to be updated, even though it is not urgent. Nicolas1981 (talk) 12:49, 10 December 2014 (UTC)

I've seen "delegation" used for a fair amount of w:paradiplomacy (such as Ontario's former 'embassy' to Québec, which used to sit just outside the walled city) so I suppose that makes sense. K7L (talk) 17:34, 10 December 2014 (UTC)

Sorry to disagree with the experts at StackExchange :) In earlier times 'Legation' referred to any diplomatic office other than a country's embassy, however in any case it is no longer used. I'm not sure about the term Delegation as well, just because it is not widely used in this context. --Andrewssi2 (talk) 20:20, 10 December 2014 (UTC)

How about "representation"? I will only appear in the listing's wikicode and as an icon in the listing editor I guess. Nicolas1981 (talk) 15:58, 12 December 2014 (UTC)

'Representation' could work.

I was also thinking that a specialized template could also optionally include other nations that an embassy may represent. For Example the Swedish Embassy in North Korea represents the United States, or the Embassy of an EU country should also offer consular services to any other EU country as well. --Andrewssi2 (talk) 18:45, 12 December 2014 (UTC)

Restaurant name showing wrongly in hover message

Swept in from the pub

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

I've noticed the same problem. It seems the hover message isn't configured to display certain characters. -- AndreCarrotflower (talk) 17:23, 3 January 2015 (UTC)

The '+' symbol is used when passing parameters to a page through the URL; it represents a space (since space characters can't be used in URLs). When the parameter is encoded for placing in the URL, spaces are converted to '+' characters, so any '+' characters will get converted back to spaces upon decoding.

The likely cause of this bug is that text like listing names isn't being properly URLencoded before being passed as parameters. Unfortunately, I know only enough to identify the problem, not enough to fix it.

-- Powers ^(talk) 22:15, 3 January 2015 (UTC)

The script poimap2.php for the dynamic map is wrong here. I will try to fix it in the next version. -- Joachim Mey2008 (talk) 17:34, 4 January 2015 (UTC)

A plus sign is also possible in name fields now. 1 Hotel Chip + Dale, 77 Chipmunk St. . -- Joachim Mey2008 (talk) 13:42, 8 January 2015 (UTC)

Static dynamic maps

Swept in from the pub

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

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

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

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

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

If we could figure out some way to generate a map legend to replace the functionality of clicking on a dynamic map's POIs, that would be good too. -- AndreCarrotflower (talk) 16:30, 22 January 2015 (UTC)

"Every time the article is edited" is probably too much, since people will make multiple edits in the space of a few minutes. Maybe we should limit it to once an hour or once a day? WhatamIdoing (talk) 16:33, 22 January 2015 (UTC)

Would it not be possible to analyse the changes made in the edit and generate the map for comparison only when POIs are modified in ways the script used cannot see are irrelevant? Relevant changes would be removal or addition of POIs, change in coordinates or change in listing type. Something else? When moving the POIs the script would probably not be smart enough to see nothing was changed but in trivial cases. Even with a quite simple script we could avoid map generation when the edit e.g. affects only running text. Waiting while somebody is doing extensive changes would of course be good to (as with the suggested timer or more cleverly). --LPfi (talk) 16:42, 22 January 2015 (UTC)

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

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

How does this script handle overlapping icons? Powers ^(talk) 18:13, 22 January 2015 (UTC)

The current script does not handle that. If I can find a way to know whether there is overlap or not, I could easily generate other images at higher zoom levels, but not sure where to put these images so that they appear in print but not to Web users. Any idea how to solve this, or reduce overlay? Nicolas1981 (talk) 04:04, 23 January 2015 (UTC)

It's not only about the overlay, but about choosing zoom level and area that are most suited for a printed map. Creating a template that adds a static map to the print version but not on the web is trivial, isn't it? The printonly CSS class can be used. --Alexander (talk) 07:41, 23 January 2015 (UTC)

Another question. What happens when such a static map is created and then the article subsequently receives many new/updated listings? Most editors won't notice the existence of this 'out of date' static map (since the picture will be similar) but end users will be impacted. Andrewssi2 (talk) 20:43, 22 January 2015 (UTC)

The "staticmap=" parameter of the Mapframes are often out-of-date. One of the goals of the present script is to fix this problem, by re-generating the image when needed. Nicolas1981 (talk) 04:04, 23 January 2015 (UTC)

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

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

Dynamic map server down

Swept in from the pub

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

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

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

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

Question about map markers

Swept in from the pub

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

Probably discovered a limitation on template. Is still at status experimental and probably needs to be added to the map marker algorithm. --Traveler100 (talk) 19:13, 20 February 2015 (UTC)

For proper automatic numbering is missing "type=do" in the template:event. Or "{{event | type = do | .... }}" must be entered in the source article text. But I'm not an expert on templates. The numbering for the dynamic map I will adjust later. -- Joachim Mey2008 (talk) 06:27, 22 February 2015 (UTC)

Dynamic maps everywhere

Swept in from the pub

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

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

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

You might want to have a look at WV:Dynamic maps Expedition, particularly the "Current stage: PoiMap2 broader deployment" section, which may address the points you've raised. -- Ryan • (talk) • 00:36, 26 February 2015 (UTC)

As long as they are reasonably up-to-date, static maps should not be removed. Feel free to add dynamic maps to articles that you feel would benefit from one :-) Having both a static map and a dynamic map is good I think, it is even better than having only a dynamic map, as they can focus on different scale/areas, for instance a static map for the historic center and a dynamic map for the whole city, including landmarks in the suburbs. Automatically inserting dynamic maps in all articles is an option, and actually it is what the French Wikivoyage has done last year (although they put it in their infobox, while we don't use infoboxes here). For each article with no dynamic map we could generate one and put it in the Get Around section, the map would be useful as it shows the destination's streets layout, even in cases where no POIs have coordinates. Let's wait for everyone's opinion about this :-) Nicolas1981 (talk) 02:10, 26 February 2015 (UTC)

I believe in substituting dynamic maps for static ones when the dynamic map is obviously more easily readable only. Ikan Kekek (talk) 03:35, 26 February 2015 (UTC)

I don't think it should be out of question to replace static maps with dynamic ones once they become outdated to a certain degree. On the contrary, I would regard that as an inevitable concession to the reality that our community simply doesn't have enough members experienced with static mapmaking to handle the level of upkeep required by all the Wikivoyage articles that have them. -- AndreCarrotflower (talk) 04:17, 26 February 2015 (UTC)

I also believe a move towards the acceptance of Dynamic Maps is the pragmatic way forward for this site to engage a broader set of contributors. At the same time I do understand the position of those Static Map people who have put in a lot of effort crafting those static maps and would feel slighted if those same maps are dumped as soon as they become ever so slightly outdated. Andrewssi2 (talk) 04:20, 26 February 2015 (UTC)

I think there's a clear difference between a sightly outdated static map and a hopelessly outdated one, and the threshold a static map has to cross before it's justifiable to start talking about replacing it with a dynamic map is certainly debatable. But as to your point about the hard work of static mapmakers, to cater to whose who cry foul about their maps being replaced would run afoul of a fundamental wiki principle regarding ownership of articles. The good of the project has to come first - and in the long run, like it or not, static maps are dinosaurs. -- AndreCarrotflower (talk) 04:28, 26 February 2015 (UTC)

As long as User:Saqib is here and willing to continue with his great map-making, static maps will continue to exist. He can update them, too. Ikan Kekek (talk) 04:30, 26 February 2015 (UTC)

Is he alone up to the task of ensuring that all the static maps on Wikivoyage are kept up to date, though? -- AndreCarrotflower (talk) 04:32, 26 February 2015 (UTC)

I don't know. How many of them are there? Ikan Kekek (talk) 04:40, 26 February 2015 (UTC)

Do you mean city/district static maps or region static maps? I imagine there are a few hundred region maps (every country, plus many states and provinces), probably fewer city/district maps. I still draw static region maps and can fix them up if someone points them out. City/district maps, on the other hand, I usually leave to dynamic maps since I feel they're almost always a better option. -Shaundd (talk) 05:25, 26 February 2015 (UTC)

Also User:LtPowers makes static maps. Even I do it to some extent, but like Shaundd I always use dynamic maps for pointing out attractions in cities and city districts but static maps for regions and city districtification. ϒpsilon (talk) 05:37, 26 February 2015 (UTC)

(This has been discussed already before.) Anyways for the record, I'm in strong favour of static maps for regions and big cities (districtification). I know still there're plenty of regions/big cities articles out there without a static map, but it is because either the article is very outline so there's really no need of a map or lack of sources (boundries issues) from which a map can be traced. For instance, Athens missing a districtification map because I couldn't able to find a source from which I can trace the map. For cities/districts, offcourse dynamic maps are better as of now giving that we have lack of map making team. In-fact, Karachi using a dynamic map. With that being said, I'm always available to help out with maps if I get request. --Saqib (talk) 09:28, 26 February 2015 (UTC)

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

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

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

Okay, I would say we should have static maps for star articles atleast, even if they're districts. Star articles should have both (dynamic as well static maps). WHY? There're plenty of reasons. And I'm more happy to update the maps of star level articles and we should create a project page somewhere to list the star articles that need map update. I'm happy to work on them. --Saqib (talk) 13:28, 26 February 2015 (UTC)

If there are plenty of reasons, please offer them. I should think a dynamic map would be rather redundant on, say, Walt Disney World/Epcot. So long as our dynamic maps are horribly jumbled collections of plus signs and numbers obscuring street names and POI labels, locked into a north-up orientation, and lacking the flexibility to include things like insets and legends, static maps remain essential.

I once again have to strenuously object to the completely unfair characterization of maps as things that only "a much smaller number of editors" are "capable of updating". Our map paradigm was designed under the principle that anyone can edit them, just like our articles are. Just like nearly everyone is capable of updating articles, nearly anyone should be capable of updating maps.

To address the original point of the thread, I would point out that we can never hope to duplicate the functionality of Google Maps. We shouldn't even try. What we could do, if it would be useful, is place a "vicinity" map in the Go Next section that shows the relationship of the destination to nearby destinations mentioned in that section.

-- Powers ^(talk) 01:03, 27 February 2015 (UTC)

Replace the words "capable of updating" with "interested in learning how to update" and/or "interested in putting forth the effort to update when the same thing can be done on a dynamic map in a fraction of the time", and the essence of what I said remains the same. No matter how much effort we go to in scolding people for not being interested in learning the ways of static maps, the fact remains that our community is made up of volunteers who are under no obligation to do or learn anything - and there aren't very many of us to begin with. Given that, some concessions to reality are in order. -- AndreCarrotflower (talk) 01:15, 27 February 2015 (UTC)

With respect to the point about a "vicinity map", the dynamic maps already do that - click on the third icon ("POIs <-> destinations") and you'll get a map that shows all articles in the immediate area, and you can click on any marker to view that article. -- Ryan • (talk) • 01:37, 27 February 2015 (UTC)

This should definitely be more prominent! Have been looking for something like this for a while Magedq (talk) 04:19, 27 February 2015 (UTC)

I tested this out. When I click that icon, all I see are a mass of unlabeled blue markers. I can hover over some of them to see what city they refer to, but that's tedious. And others are so close together that they do not show up as individual markers. A hand-crafted map would be much more readable and usable. Powers ^(talk) 16:43, 28 February 2015 (UTC)

The zoom / scroll functions and the direct jump to each neighboring article, you forgot to mention. - How can you do something like this with static maps? -- Joachim Mey2008 (talk) 19:11, 28 February 2015 (UTC)

While dynamic maps are obviously a sore subject for a few people, for the vast majority of users the dynamic maps seem to be a highlight of the move to Wikivoyage. Mey2008, I don't think you and the others who maintain this functionality get thanked nearly enough, so many, many thanks for the work you do on this feature - today we have over 1500 articles with maps that would likely not otherwise have them, which is a massive usability win for our site. -- Ryan • (talk) • 19:30, 28 February 2015 (UTC)

Direct jumps can be implemented with imagemaps, if deemed necessary -- but keep in mind that the text list would appear in the article right next to the map. I'm afraid I don't see how zooming and scrolling serve to solve the problems I pointed out. A well-designed static map can tell the user at a glance what it would take these dynamic maps several seconds or minutes of scrolling zooming and hovering to find out. Powers ^(talk) 18:35, 1 March 2015 (UTC)

An imagemap is no alternative. First you need to check all neighboring destinations whether an article already exists. A monotonous and tedious task. Then you have to manually detect hundreds of pixel coordinates and dozens of polygons. This lasts many hours. A single mistake makes the whole map unusable and caused extensive search. - To create a dynamic map is only required {{mapframe|zoom=auto}}. That's all. The only (logical) precondition is that some listings with coordinates should be available. - Try this once on my test page [32] and you will be amazed. -- Joachim Mey2008 (talk) 06:47, 2 March 2015 (UTC)

I didn't say it'd be easy. Much that's worthwhile isn't. But I'm also not convinced that the links are a vital part of this puzzle given the caveats I mentioned above. Powers ^(talk) 02:37, 3 March 2015 (UTC)

---

I'd say nearly all articles should have a dynamic map; that just needs geo co-ords added. Just doing the city gives a map, then if there are co-ords in listings, it improves. Co-ords can be added even by someone like me who has approximately the same ability with graphics as the average turnip and is not much interested in learning more. For example, I added a lot to Suzhou and Dumaguete.

Then some should have a static map added. Of course a good static map can be better than the dynamic ones if someone has the time & skill.

I think there are some open problems with dynamic maps. One is that many people do not set zoom= when they insert co-ords; this can give a map of an island or region that shows far less than the whole thing, or a city map that shows only the center. Another problem, I think, is that the map icon, off in a corner of the screen, may not be noticed by readers; I'd like to replace it with MAP. Pashley (talk) 01:53, 27 February 2015 (UTC)

Agreed about noticibility. I consider myself a regular user, and always wanted there to be maps, but never knew that button existed. I'd say that the map should even be displayed by default, with a button to expand to full screen. Magedq (talk) 04:19, 27 February 2015 (UTC)

I agree that the map icon is not noticable. Even when I have told friends about a page here and that there is a map, unless I point at the icon on their screen new users don't recognise it. Changing it to "MAP" and / or adding it to the left menu would be good. AlasdairW (talk) 15:33, 27 February 2015 (UTC)

About maps

The Amana Colonies are on the northeastern edge of Iowa County in Iowa.

The Amana Colonies are in east central Iowa.

Major highways near the Amana Colonies in Iowa

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

For me browsing this page, the US map is the most useful because I have no clue where Iowa is, so I want to be able to place villages on a map I know. But I definitely am not the normal/expected(?) user for this page. Would it be someone who regularly drives through the area? Then maybe one with roads/highways would be most useful. This is why dynamic maps make so much more sense to me, especially if it can be simple to jump between layers and get to the info that you're specifically looking for. Magedq (talk) 05:13, 1 March 2015 (UTC)

You definitely should not give a map of the entire US, showing where the entire state of Iowa is, in an article about the Amana Colonies. I think the locator map, showing the whole county, is modestly useful, but I wouldn't include that, either. What's really needed is a road map, showing how to get there. So I ultimately agree with Magedq about a dynamic map for the larger area, in addition to maps of each village — unless you'd prefer to make a clear static map, showing the placement of the different villages and roads between them. Ikan Kekek (talk) 05:59, 1 March 2015 (UTC)

I've added a third option: the state of Iowa, with the major highways marked (US 6 in red, all the interstates in blue). I'm thinking that you would need to add a dot that shows the location of the Amana Colonies. (It's a little west of where the red line and one of the blue lines intersect in the right side of the map.) Also, the highways ought to be labeled, if you want to use them as driving directions. I'm not sure how helpful this would be to someone who doesn't know where Iowa is, though. Even if you've narrowed it down to "one of the square states in the middle", that leaves a lot of room for error. WhatamIdoing (talk) 19:59, 2 March 2015 (UTC)

I don't like it because I really don't get any useful information from it. But the main point that I'd like to make is that this site operates on breadcrumbs, so if someone doesn't know where Iowa is, they can go up the breadcrumb trail to look at the Iowa article, and if that doesn't help, the regional article for the Midwest or the USA article. We don't need to and shouldn't show a map of the entire country, the entire state and the entire county in every city article. Ikan Kekek (talk) 20:18, 2 March 2015 (UTC)

I would find a good locator map useful, but I think that they probably take far too much work to create. It would be better to spend the time creating a static map for Eastern Iowa. The location of Amana Colonies can probably be covered effectively with a sentence: "The Amana Colonies are about 25 miles northwest of Iowa City, 20 miles southwest of Cedar Rapids, 100 miles East of Des Moines and 250 miles west of Chicago." This should let readers have a reasonable idea of where the place is, Get in can then provide the details of road numbers, bus times etc. AlasdairW (talk) 12:21, 7 March 2015 (UTC)

Availability map server

Swept in from the pub

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

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

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

Labs is having problems recently: https://lists.wikimedia.org/pipermail/labs-l/2015-February/003429.html Nicolas1981 (talk) 08:51, 27 February 2015 (UTC)

• We have indeed; sorry for the inconvenience. Over the past two weeks we suffered a hardware failure followed by a mysterious failure of the host where the virtual machines were moved to. All told, parts of labs had some six hours of outage over the past couple of weeks. We're hard at work increasing our redundancy. MPelletier (WMF) (talk) 21:19, 1 March 2015 (UTC)

Map Server is evidently down again. Matroc (talk) 03:23, 31 March 2015 (UTC)

It should be better now. A long-planned improvement (to improve stability and availability, ironically) had some temporary problems. WhatamIdoing (talk) 06:12, 1 April 2015 (UTC)

Maps on Firefox

Swept in from the pub

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

Yes this happens to me a lot when I use Firefox, but it's OK with Chrome. Antiv31 (talk) 09:04, 20 March 2015 (UTC)

Please close all WV tabs / windows. Important! Then clear the browser cache. Data structure has changed in the last version. -- Joachim Mey2008 (talk) 10:14, 20 March 2015 (UTC)

That fixed it, thanks. --Traveler100 (talk) 11:06, 20 March 2015 (UTC)

Worked for me too. Antiv31 (talk) 01:43, 21 March 2015 (UTC)

Create an exhibition city map

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

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

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

The WV map provides only this representation. The markers are clickable and linked with the WV articles. But the article status is not evaluated. - Joachim Mey2008 (talk) 12:44, 29 March 2015 (UTC)

Thanks Joachim ! --Andrewssi2 (talk) 23:51, 29 March 2015 (UTC)

Dynamic maps not showing

Swept in from the pub

I get this error with any dynamic map:

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

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

Only administrators @Zhuyifei1999:, @Torty3:, and @Atsirlin: can restart the service. Programs were not changed, and run the same version without any error on the WV.eV-server[33]. - Joachim Mey2008 (talk) 08:06, 31 March 2015 (UTC)

I can't even log in to tools.wmflabs.org at the moment, so we can't do anything. Please, ask WMF why the tools server is so unreliable. --Alexander (talk) 08:15, 31 March 2015 (UTC)

I temporarily changed the server address to WV-eV-server. Full Screen maps are functional again. -- Joachim Mey2008 (talk) 08:38, 31 March 2015 (UTC)

Done Restarted --Zhuyifei1999 (talk) 08:53, 31 March 2015 (UTC)

I think that this is related to w:en:Wikipedia:Village pump (technical)#Labs is going to be slow. That team is aiming for 99.5% uptime, and they still have a chance at it (for the year, but probably not for the quarter that ended a few hours ago). WhatamIdoing (talk) 06:23, 1 April 2015 (UTC)

wmflabs not responding - Matroc (talk) 04:47, 2 April 2015 (UTC)

Further failure of WMFLabs servers since 2:40 (UTC). Reason: 504 Gateway time-out. Also Wikipedia's dynamic maps are affected. -- Joachim Mey2008 (talk) 05:02, 2 April 2015 (UTC)

Thank you Joachim for the information - Matroc (talk) 05:12, 2 April 2015 (UTC)

It seems that everything is working again. -- Joachim Mey2008 (talk) 05:22, 2 April 2015 (UTC)

Looks like a hardware problem. There were problems two days in a row. See this incident report if you want the gory details. WhatamIdoing (talk) 20:16, 2 April 2015 (UTC)

Stability of map server

Swept in from the pub

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

Or whether we should do something about the stability of the server, or moving to another. I missed most of the discussions on that - what's the status? Meanwhile, everybody willing can start making the missing hundreds of static maps, should be lotsa fun! PrinceGloria (talk) 21:33, 13 April 2015 (UTC)

Yeah, it's not very practical, but at least those relatively few articles with static maps will have visible maps while the dynamic map server is on the fritz. Ikan Kekek (talk) 21:39, 13 April 2015 (UTC)

Sorry if I ask a stupid question, but... What's wrong with dynamic maps? Hobbitschuster (talk) 21:42, 13 April 2015 (UTC)

They're fine if they're visible. When the map server is on the fritz, they can't be viewed at all. Ikan Kekek (talk) 21:46, 13 April 2015 (UTC)

How so? "Nginx error" is a fine, historic city and well worth a visit. K7L (talk) 21:48, 13 April 2015 (UTC)

"Nginx" - awesome city with stylized gardens on the coast, best food just outside of Tokyo - Matroc (talk) 21:52, 13 April 2015 (UTC)

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

Dynamic Maps are a long standing issue. Although we have some great volunteers who make great efforts, the map server is basically still an experiment and would never be used for a commercial business.

So the problem is... how to move it from the experimental phase? AFAIK there is no other place we could host it.

I actually think a good solution would be to get rid of the map server completely and replace it with a Javascript control that would call OpenStreetMaps directly. This would also have (significant) technical challenges, but it would remove the dependancy on WMF labs... Andrewssi2 (talk) 03:05, 14 April 2015 (UTC)

Has WMF ever been asked for an alternative solution, e.g. hosting on a different server? Whatever holds e.g. the general Wikivoyage stuff seems to act up very rarely. PrinceGloria (talk) 05:00, 14 April 2015 (UTC)

Is does act up rarely.. enough for myself (for example) not to be too bothered. However if we do see significantly increased readership (one of our general aims) then that will have the effect of knocking the map server over more frequently. Andrewssi2 (talk) 05:03, 14 April 2015 (UTC)

PrinceGloria, I don't have to change anything in my browser to see the maps, and most other people don't have to do it either. Which browser do you use? Have you checked that it calls tools.wmflabs.org and not other servers (that are not trusted indeed)? --Alexander (talk) 07:10, 14 April 2015 (UTC)

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

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

Two maps in one article

Swept in from the pub

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

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

You can only have one dynamic map visible on a page. It is possible to have a formatted link to other maps, see example on the Rheinburgenweg page. Alternatively create static maps. On the coordinates of stadiums I would think they are listed as articles on English Wikipedia. --Traveler100 (talk) 14:27, 17 May 2015 (UTC)

They are, but only three of them offer the coordinates or at least I couldn't find them in the other six... Hobbitschuster (talk) 14:43, 17 May 2015 (UTC)

Are you looking in the upper right corner above the infobox? I just checked w:TD Place Stadium and w:Tim Hortons Field and they have coordinates there. You can also check on Wikidata (ex: d:Q7008048). Powers ^(talk) 15:50, 17 May 2015 (UTC)

It's done. Thanks. I would almost think that our article on American football is fast approaching guide territory. However, the coverage of Canada and minor leagues is still insufficient... Hobbitschuster (talk) 16:26, 18 May 2015 (UTC)

Hobbitschuster, Traveler100, to show more than one dynamic map in one single page, MediaWiki:Gadget-MapFrame.js, must be patched like the it:voy one. --Andyrom75 (talk) 13:17, 21 May 2015 (UTC)

I don't know about the technical details, how is this done and what would be (possible) downsides? Hobbitschuster (talk) 22:06, 21 May 2015 (UTC)

Hobbitschuster To allow two maps an admin must patch the above script, and I don't forsee any downside on doing that. --Andyrom75 (talk) 23:01, 23 May 2015 (UTC)

Mapnik broken on tools.wmflabs.org

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

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

NEW APP! Wikivoyage offline on your Android

Swept in from the pub

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

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

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

Do the dynamic maps also work in offline mode? If so then that would be a nice feature. --Andrewssi2 (talk) 07:07, 11 June 2015 (UTC)

Yeah offline dynamic maps would be awesome, unfortunately the Kiwix engine does not support that yet. At least we should embed a "frozen" version of the dynamic maps. For now, the best is to generate a GPX file for the area using http://maps.wikivoyage-ev.org/w/gpxmap.php?lang=en before leaving home. Syced (talk) 07:57, 11 June 2015 (UTC)

Ah, so basically it just holds static maps (images) if they exist?

Actually given that we have the geo-coordinates of listings, perhaps we can just leverage the mobile Google Apps... --Andrewssi2 (talk) 09:44, 11 June 2015 (UTC)

Clicking on a listing opens your favorite maps app. But showing all listings on a single map requires either implementing a GPX algorithm in Kiwix, or using "frozen" maps. Syced (talk) 06:08, 16 June 2015 (UTC)

Dynamic to static maps within Kiwix

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

Reading the bug report, it doesn't say that it will render Dynamic maps into Static maps. It just says that it will use Static maps if the 'staticmap' attribute is used. AFAIK this attribute is not used very much. --Andrewssi2 (talk) 23:40, 13 June 2015 (UTC)

I was emailed by the lead of Kiwix who said he fixed it and the dynamic maps should be there as static in the July edition. Travel Doc James (talk · contribs · email) 10:20, 14 June 2015 (UTC)

If correct then that would be very interesting. The same technique could generate Static maps for our print view as well. --Andrewssi2 (talk) 00:01, 15 June 2015 (UTC)

Andrewssi2 is correct, we have to create/maintain staticmap attributes on our side. Kiwix will include a static map only when there is such a staticmap attribute. I wrote the DoraStone script for this purpose, but unfortunately a bug on my machine prevents me from using it. Anyone willing to become the project leader for that script? Thanks! Syced (talk) 07:30, 15 June 2015 (UTC)

Looking at the underlying code this gives maps in Kiwix {{Mapframe|35.66262|139.73060|zoom=16|height=540|width=520|staticmap=POI-Roppongi.png}} This does not {{Mapframe|49.513611|-115.768611|zoom=12}}

We need a bot to create and add the static maps. Travel Doc James (talk · contribs · email) 19:51, 11 July 2015 (UTC)

This also raises another question for existing static maps which is going to be contentious. Once all the static maps are generated then there will be no way to determine whether the static map was hand crafted or automatically generated with the technique above.

This is problematic because I would assume we would run the bot every month to regenerate all maps from their dynamic counterparts, regardless of whether the original was handcrafted...

It would effectively mean the end of hand crafted static maps. Andrewssi2 (talk) 23:45, 11 July 2015 (UTC)

So, if something like Adirondacks#Towns and villages links both a static and a dynamic map for the same region (dynamic maps don't cope with dividing a region very well), won't any script think the hand-drawn map is just another random image which can safely be ignored, and not part of the {{mapframe}}? K7L (talk) 03:59, 12 July 2015 (UTC)

Yes this would only pertain to "mapframe"

I assume that this one is hand drawn [35]?

We just need a way to stipulate which mapes are hand drawn and which are automatically created and simply give preference to the hand drawn ones.

This could be done by adding a new parameter to mapframe like "staticmapauto" which works like staticmap but only if staticmap is not filled in. That is were we would place the auto generated static map links Travel Doc James (talk · contribs · email) 07:28, 12 July 2015 (UTC)

This discussion seems rather important to be hidden in this sub-discussion. I have raised a new discussion here: Wikivoyage_talk:Dynamic_maps_Expedition#Future_of_static_maps_with_autogeneration.3F Andrewssi2 (talk) 02:26, 13 July 2015 (UTC)

Future of static maps with autogeneration?

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

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

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

It'll be cool to get more maps, but I still think there's a place for well-designed static maps, particularly at the region level. A snapshot of the dynamic map of a region is better than no map, but it'll be worse than a good static map in most cases (e.g., no subregions, not all transportation routes will be visible). Having the ability to turn auto generation on or off seems like a good idea although it will be quite manual to configure it for static maps we want to keep. -Shaundd (talk) 05:29, 13 July 2015 (UTC)

BTW - just to be clear, I don't think a dynamic map/mapframe should be replacing the existing colour-coded region maps yet since it can't display subregions. And if we go down the route of auto-generating and someone draws a region static map, I think it should supercede the dynamic map and auto generated map. Apologies if my thoughts are a little all over the place, it's late!. -Shaundd (talk) 05:51, 13 July 2015 (UTC)

I think the suggestion is to ONLY use snapshots of dynamic maps if a handmade static map is NOT available. Travel Doc James (talk · contribs · email) 20:39, 13 July 2015 (UTC)

It's suggested, but I also got the impression Andrewssi2 wanted a wider discussion. Regardless, after re-reading the pub discussion, I'm confused. What actions are being proposed and how is it going to work? -Shaundd (talk) 04:30, 14 July 2015 (UTC)

The current 'status quo' (as far as I understand it) is:

1. if an article has no static map image, then a dynamic map may be used
2. if an article has a sufficiently outdated static map image, then a replacement dynamic map may be considered
3. if an article has a dynamic map, then a static map can be added to the 'staticmap' attribute for printing purposes

This is already rather unclear. On top of this we are proposing extra logic to dictate when 'static maps generated from dynamic maps' can be used.

I don't have an answer to this, I'm simply highlighting a confusing approach to maps generally. Andrewssi2 (talk) 05:56, 14 July 2015 (UTC)

Maps - tools lab is down

Swept in from the pub

• see Details here. Thought everyone should know this and hopefully they will not have any difficulty restoring systems etc. -- Matroc (talk) 21:56, 18 June 2015 (UTC)

It was down all day yesterday but thankfully it's now partially back. The Mapnik layer still doesn't load. ϒpsilon (talk) 08:12, 19 June 2015 (UTC)

And once again no maps. ϒpsilon (talk) 14:26, 19 June 2015 (UTC)

I have changed the server address to WV-ev.org. Now the full-screen maps works. -- Joachim Mey2008 (talk) 19:25, 19 June 2015 (UTC)

Thank you Joachim! - Matroc (talk) 20:38, 19 June 2015 (UTC)

Vielen Dank! I'm doing some work on the districts of Seoul and the absence of the map functionality has been really annoying. ϒpsilon (talk) 20:44, 19 June 2015 (UTC)

I have temporarily changed the template mapframe. Please check spelling. - Template will be reset when WMF tiles server is back online. -- Joachim Mey2008 (talk) 04:42, 20 June 2015 (UTC)

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

The tiles server is also running again. I have reset the temporarily modified templates. --- Joachim Mey2008 (talk) 11:25, 22 June 2015 (UTC)

https://tools.wmflabs.org/wikivoyage/w/poimap2.php?lat=43.96&lon=-74.33&zoom=8&layer=OB&lang=en&name=Adirondacks gives me "504 Gateway Time-out nginx/1.4.6 (Ubuntu)" and the {{mapframe}}s are also timing out after a very long delay. K7L (talk) 17:17, 22 June 2015 (UTC)

Seems to be working OK now. Syced (talk) 02:51, 23 June 2015 (UTC)

Unfortunately, still lacks zoom level 17 for the colored Mapnik layer. Some other Mapnik zoom levels have partially gaps. Well, wait and see. -- Joachim Mey2008 (talk) 14:55, 24 June 2015 (UTC)

@Atsirlin try running "php unzip.php" on tool labs in case the map scripts needs an update. (I think you have the access if wikitech:User:Atsirlin is the same user as you.) If that fails, since I don't monitor that tool so often, would you give me a ping? --Zhuyifei1999 (talk) 14:35, 1 July 2015 (UTC)

Zhuyifei1999, I have access, but the problem is not on our side. The Wikivoyage tool runs smoothly, but it fails to get Mapnik tiles from some other repository on tools.wmflabs.org. And I don't even understand where this repository is, and who may be responsible. So annoying... --Alexander (talk) 17:03, 1 July 2015 (UTC)

Checking the page source and Mey's comment below shows tiles.wmflabs.org as the source, but the host is undocumented. Searched "tiles" instead and found wikitech:Nova_Resource:Maps. cURL'ed all the instances and found maps-tiles3 gives the same output as tiles.wmflabs.org. So very likely the admins on wikitech:Nova Resource:Maps are who to find. --Zhuyifei1999 (talk) 03:53, 3 July 2015 (UTC)

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

The Wikivoyage scripts are restored properly. The problem is the map tiles server. This applies to all users, even Wikipedia. It lacks all the tiles to the zoom levels 3, 6, and 17. This only applies the https addresses: e.g. https://tiles.wmflabs.org/osm/17/x/y.png. But even in other zoom levels are missing several tiles. -- Joachim Mey2008 (talk) 05:12, 25 June 2015 (UTC)

WMFLabs provides no more map tiles since June 26. I have therefore provisionally replaced the three layers "Mapnik", "Mapnik b&w" and "Hill shading" by similar external provided layers. -- Joachim Mey2008 (talk) 15:35, 6 July 2015 (UTC)

WMFLabs layers are back again. -- Joachim Mey2008 (talk) 17:56, 16 July 2015 (UTC)

poimap2.php is 404?

Swept in from the pub

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

Might have something to do with a new tile server in process? server address is different (not tools.wmflabs.org) = Matroc (talk) 04:00, 27 July 2015 (UTC)

Looks like it is being corrected as my markers are now working correctly. - Matroc (talk) 04:10, 27 July 2015 (UTC)

The server address 'http://maps.wikivoyage-ev.org' has failed due to problems in the files system. I have changed the address back to '//tools.wmflabs.org/wikivoyage'. -- Joachim Mey2008 (talk) 04:11, 27 July 2015 (UTC)

Dynamic maps

Swept in from the pub

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

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

This is extremely annoying. At the moment, we do not include any tiles from mapquest automatically. We only call them if the user decides to do so by switching the tiles manually, which is perfectly in line with the privacy policy because the tiles section contains clear information on which tiles are from the WMF-controlled servers, and which are not.

However, the tile server on tools.wmflabs.org is extremely unreliable, and most problems with the dynamic maps are caused by overloads and down-times of this server that is, unfortunately, beyond our control. WMF should establish a reliable and complete tile server before making any complaints or forcing us to switch off certain tiles that we do need for making our travel guides useful. --Alexander (talk) 13:46, 20 July 2015 (UTC)

Previously (ie yesterday) when I went to Cranbrook it automatically pulled tiles from mapquest without me selecting it. Now I need to select mapquest before it will load from their. That seems a reasonable compromise to me User:Atsirlin and hopefully enough for those involved with maintaining privacy. Travel Doc James (talk · contribs · email) 15:48, 21 July 2015 (UTC)

Hi Alexander, could you show me the usual process for enabling tiles from mapquest? Is this an option in {{Mapframe}}? Thanks! Stephen LaPorte (WMF) (talk) 16:56, 22 July 2015 (UTC)

Go to a page with a map, for instance Amsterdam/Binnenstad#Get in. At the upper-right corner of the map, there's an icon with a stack of layers, which brings up a menu. From that menu, various tiles can be manually chosen by the user. K7L (talk) 17:05, 22 July 2015 (UTC)

Thanks! Stephen LaPorte (WMF) (talk) 17:53, 22 July 2015 (UTC)

@Atsirlin:, I agree 100% - this is very annoying indeed, and I hope the new OSM-based tile server, hosted in WMF production cluster, will be available within a few weeks - Max and I are working on it every day. --Yurik (talk) 23:17, 22 July 2015 (UTC)

On a side note, apparently this issue has been discussed on meta before. --Yurik (talk) 23:17, 22 July 2015 (UTC)

Yes, we have discussed it, and I thought that our current solution (tiles from external server not loading automatically) is fine with everyone. Nice to know that someone is working on the new tile server. Thanks for the effort that you put into it, and I look forward to seeing it operational! --Alexander (talk) 11:24, 23 July 2015 (UTC)

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

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

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

Yurik, that's great news, but I think that I did not get the point. Do you want us to use maps.wikimedia.org instead of labs from now on? I believe we can do it (of course, with Joachim's consent), provided that you are available for resolving bugs and problems. --Alexander (talk) 17:21, 27 August 2015 (UTC)

@Atsirlin:, yes, that's the idea, but there is one "but": - user:MaxSem and I have been working on the new service for about 4 months now, and we think it is ready for real trials. Wikivoyage is a perfect place to be its first user, but I will not be online for the next week (taking my first vacation in a year and disconnecting from the grid), so I will not be able to assist with resolving bugs until I come back September 8th. It would be awesome if the community could evaluate the new service and report any issues found to Maps discussion page or in the phabricator, but I think we should wait one week until I come back to actually switch all of the map templates to it. What do you think? --Yurik (talk) 04:36, 28 August 2015 (UTC)

I agree. Moreover, it takes a few days before map scripts (which are also sitting on tools.wmflabs) are updated. Joachim, what is your opinion? --Alexander (talk) 07:20, 28 August 2015 (UTC)

First of all, the access from *.wikivoyage-ev.org to maps.wikimedia.org must be made possible. Otherwise, I can not test anything. -- Joachim Mey2008 (talk) 17:30, 28 August 2015 (UTC)

@Mey2008:, I just noticed this, sorry for not doing it earlier. Phabricator is a much better way to get this solved quickly - it gets tracked and processed properly. I created a patch to fix this, could you clarify who owns the domain? (People asked for it in the comments). Thanks!

@Mey2008:, update - the patch has been merged, you should be able to use it now. --Yurik (talk) 17:04, 18 September 2015 (UTC)

Thanks for the additional release of access. - The owner of the domain is the state-registered and non-profit association "Wikivoyage e.V."* under German law. The association is officially recognized as a charitable organization and exempt from all taxes and fees. *The addition "e.V." means "eingetragener Verein" (registered association). -- Joachim Mey2008 (talk) 04:40, 19 September 2015 (UTC)

Geo URI's on Web version

Swept in from the pub

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

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

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

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

Alternatively, you can download all POIs as GPX file (maximum of 25 articles grouped together) [37]. You can import this file into OsmAnd. All search and routing functions are possible with this GPX data. - Joachim Mey2008 (talk) 05:16, 13 August 2015 (UTC)

I have exactly the same use case. I also use the trick mentioned by Joachim, but indeed I support showing geo URIs if the browser is a mobile browser. Do templates have the ability to know whether it is a mobile browser or not? Syced (talk) 08:47, 13 August 2015 (UTC)

Announcing the launch of Maps

Swept in from the pub

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

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

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

How can you help?

• Adapt your labs tool to use this service - for example, use Leaflet js library and point it to maps.wikimedia.org
• File bugs in Phabricator
• Provide us feedback to help guide future features
• Improve our map style
• Improve our data extraction

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

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

In depth

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

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

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

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

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

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

Yay :-) If there is no immediate blocking bug, I think we should start using it right away and see how it scales, to solve problems as fast as possible? I guess Joachim is the person who can make the change? Syced (talk) 03:25, 18 September 2015 (UTC)

There are a lot of quality bugs (like clipped labels), but no blocking bugs. Go for it :) --Yurik (talk) 04:02, 18 September 2015 (UTC)

Given recent issues around the change of Banner template, please isolate any changes on a low traffic article for evaluation first :) Andrewssi2 (talk) 04:18, 18 September 2015 (UTC)

Yurik, as far as I remember, Joachim asked to allow access from wikivoyage-ev.org. This is needed for testing. Otherwise, you can't expect us to switch to the new service. --Alexander (talk) 07:27, 18 September 2015 (UTC)

@Atsirlin:, thanks, I just saw it yesterday. Phabricator is a much better way to file such requests - that's how we prioritize work. The patch is done and waiting for the ops approval. --Yurik (talk) 16:29, 18 September 2015 (UTC)

PS. The patch has merged, should work now. --Yurik (talk) 17:05, 18 September 2015 (UTC)

Yurik, alright, we will use Phabricator in the future. At this point, we need a discussion and not a simple patch, though. What is your opinion about the issue raised in this thread? Can one add more detail to your maps? Can one perhaps configure a special map style for Wikivoyage (at least on a longer run), or is it completely unfeasible? --Alexander (talk) 07:02, 19 September 2015 (UTC)

I've wrote a script for the comparison of the Wikimedia map with Mapnik. There is missing a lot of information that are of interest for tourists: stops for trains and trams and the like. Names for city parks, squares and the like. Please compares itself [38]. -- Joachim Mey2008 (talk) 11:03, 18 September 2015 (UTC)

Yes, you are right. On the other hand, the new map goes in the direction of the original concept that we had back in WT times: a simple map where only POIs relevant to the travel guide (and those described in the travel guide) are shown. It may be an option to have this "simple" map embedded in Wikivoyage articles, while a more detailed map will be, of course, available as an alternative and also for offline use with OsmAnd. I do find the current version of Mapnik a bit "overcrowded" with different signs and labels.

Altogether, I would not mind to go for the simpler map from maps.wikimedia, provided that it is stable and accessible at any time. Other layers, including the detailed version of Mapnik, should be, of course, available too, and users may switch to them if they want. --Alexander (talk) 12:00, 18 September 2015 (UTC)

Congratulations to the WMF Maps team. I find the new maps to be visually much nicer, clearer and less daunting. While we don't yet have a test page to go off, I'd imagine our listing POIs will be a lot clearer on the map and not get lost in the surrounding noise. However, I do agree that simply too much info has been removed. That includes pretty much all public transit info (station names and locations, tram and bus stops, etc), at least for Melbourne. That sort of information is just non-negotiable on a travel guide map; parking, supermarkets, places of worship, etc are less important, and could be viewable by changing the layer to a more complex one. So I would like to see a test page, but I cannot support a wider implementation until a reasonable amount of public transport info is included. James A ▪ talk 13:42, 18 September 2015 (UTC)

Thanks for raising important points! Our original intent was to build a vector tile platform - which has mostly been a success. Now is when we start thinking of what and how to draw on it. All the data, such as POI, etc, are in our database, and usually it is fairly easy to add extra features to the map. Yet, we need to have a very clear understanding of who needs what -- OSM standard map was designed mostly for the map editors, who needed to see all available data so they can see what is missing or incorrect. On the other hand, various map sites tend to show only some of that info that is relevant to their use cases. Wikivoyage is a map consumer, so we should be very specific on what data each type of article should show.

With mapnik/mod_tile approach, each tile generation was a very expensive process - it used 10-20 SQL queries for each tile to get all the needed data, convert it into an image, and cache that image. Vector tiles give us the ability to get all the needed data and cache it as data, not image. This means that the actual image gets generated in milliseconds, and we can decided at the last moment what data to include (labels languages/POIs/...) and what style to draw it in (road colors/width/icons/etc). On one hand, we want to keep caching "hit-rate" high, and only have a small number of different styles. On the other, it is very quick to add a new one once we have an agreement of what is needed.

Please take a look at Improving our map style to see what styling tools are available (similar to editing CSS in a visual tool). --Yurik (talk) 14:08, 20 September 2015 (UTC)

P.S. There is always an alternative path - multiple layers. WMF maps would provide the base layer, plus it would be overlayed with additional data from either Wikivoyage pages that contain KML data, or some database that resides on the wmflabs instance. WikiMiniAtlas uses both approaches. Since all the heavy lifting to generate the base map will be done by WMF maps, the labs service should be able to handle the load of extra data without problems. This route will also give the community much greater control over what and how is displayed, and allow for much more rapid changes. --Yurik (talk) 00:39, 21 September 2015 (UTC)

Yurik, thanks for your response. Regarding additional layers generated on wmflabs, I am not sure that we can extend this beyond our current position, namely, the POIs taken from Wikivoyage articles. After all, it is not easy to handle huge databases in a wiki format, and it would be strange to have our own storage of, e.g., public transport information when this information is more up-to-date in other sources. I think that we should rather go in the direction of slightly customizing your maps to our needs. One problem here is that none of us (except for, perhaps, Joachim) understands the OSM structure and will be able to contribute to the css-like styles that you mentioned. I understand how they are written, but I have no idea which extra things to write. Therefore, the main feedback from Wikivoyage users (including myself) is something that you have already seen in this thread: we would like to have information about public transport displayed on the map. It would be great if any of you guys could implement this for us. Then we may have other wishes, but, hopefully, they won't require too much effort from your side.

At this point, it seems to be crucial to include public transport and, when we have no other outstanding objections, implement the new maps site-wide in order to collect additional feedback. JamesA, Joachim, what do you think?

Joachim, can we have something like poimap3.php handling the new maps (in the beginning), so that we could easily switch between the old and new versions on-wiki? --Alexander (talk) 08:09, 21 September 2015 (UTC)

That sounds reasonable to me, Alexander. The only necessity I can think of for now would be public transport data. That is, train stations and names, tram stops and bus stops. Road data is already displayed, so not sure why this was overlooked. Indeed, Google Maps strikes a good balance in terms of how much data it displays I think, POIs aside. Then I'd be interested in seeing a few test articles, followed by a wider implementation for testing purposes. James A ▪ talk 09:59, 21 September 2015 (UTC)

We should think carefully about whether this new Wikimedia map is already in a usable state. Please compare: left Mapquest, Mapnik, and right new Wikimedia map [39] or [40] or [41] or [42]. You can zoom and drag the left map for your own examples. Clicking creates a corresponding link in the address bar. -- Joachim Mey2008 (talk)

The scary rectangle over Braunschweig is its airport's airspace. There are two problems about this: it shouldn't have been mapped in the first place and we shouldn't have displayed it in any case. I fixed the first part on OSM side, by nuking both airspaces in existence. The second part is done with this commit, we will try to regenerate the affected area soonish. MaxSem (talk) 22:52, 21 September 2015 (UTC)

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

Joachim, I played a bit with the comparison. One major problem that I found is the lack of green spaces. I would not say that the greenery is absent completely, some parks are displayed of the map, but many of the smaller parks or green spaces like boulevards are missing. This makes the new maps rather dull in appearance and less friendly for users. Will you or Yurik know which features should be added?

Another thing is the yellow-orange-colored areas such as parking lots. Those may be also worth adding. --Alexander (talk) 06:12, 22 September 2015 (UTC)

Tracked at phab:T113479. Feel free to comment or add new tasks to Phabricator - i might miss requests in the discussions. --Yurik (talk) 14:54, 23 September 2015 (UTC)

The map update from OSM (phab:T110262 and phab:T108459) is at the top of our priorities que, will get done soon, right after we resolve phab:T113008 (displaying disputed boarders). I think we could get the transportation POIs done quickly (subways, bus, train, ships), while other POIs might take a bit longer. Max would know better about the OSM's POI data. --Yurik (talk) 21:13, 21 September 2015 (UTC)

Added phab:T113310 -- creating Points of Interest, including transportation POIs. Please comment on the task. --Yurik (talk) 23:19, 21 September 2015 (UTC)

Yurik, thanks for providing the links. It's much easier this way because Phabricator is scary for most of the regular editors=) Please, also check my reply to Mey2008 above. I hope that you can re-phrase it in a more meaningful language. --Alexander (talk) 06:12, 22 September 2015 (UTC)

Alexander, I have added the new base layer "Wikimedia" and an overlay "Traffic" with stops (+ name) and lines (+ numbers) for testing purposes.[44]. Apart from the lack of car parks the Wikimedia map now not urgently needs to be extended, I mean. -- Joachim Mey2008 (talk) 10:37, 22 September 2015 (UTC)

Thanks, Joachim. Will it be available on tools.wmflabs.org in the next days, or is it planned for the Wikivoyage server only? --Alexander (talk) 13:15, 23 September 2015 (UTC)

. After the next update on Monday "poimap2test.php" will also be available on tools.wmflabs.org. -- Joachim Mey2008 (talk) 04:32, 26 September 2015 (UTC)

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

Hi Yurik , would you be able to explain in layman terms what you are proposing with this migration? Are you replacing the existing maps control? Will you be able to use it on a few experimental pages in the first place? Andrewssi2 (talk) 23:52, 12 October 2015 (UTC)

@Andrewssi2:, re transportation POIs - the majority of the transportation POI work is done, and once the community is happy with the result (see city links above), we will update the main servers to show it on all maps that come from the maps.wikimedia.org. @MaxSem: thinks that we might need to hide POI's labels in some lower zoom levels to make it less cluttered, but that shouldn't take long, so please evaluate and let us know.
 Regarding the second portion of my message (completely unrelated to POIs): at this point, there is a large number of labs-based maps, such as the great one implemented by @Mey2008: on tools server (used by Wikivoyage), WikiMiniAtlas by @Dschwen:, and many others. Yet, because they are not on the WMF production servers, they do not scale well to be included on all articles for all users. Additionally, they all share a lot of similar functionality. So my proposal is for the tech community to agree on one common maps framework for all wikis to use, something that will provide common mapping functionality such as showing static and dynamic maps, but also allow community to add additional content and functionality specific to the project/language. Each community should not reinvent the wheel if it was done for another community, it should only add what is missing in the existing implementation. And WMF with community's help will implement the maps basics that everyone can work with, and that will scale to handle all the traffic. Also, this will NOT replace the existing map controls from the beginning - instead it will allow a few articles to be tested with it, and once everything is good, the community will be able to migrate at its own pace. Also, the new system will allow the Visual Editor map insertion -- see demo. See also technical architecture at phab:T115290. --Yurik (talk) 01:22, 14 October 2015 (UTC)

Sounds good Yurik . I would suggest creating a new discussion in the pub to announce this when you have a deployment plan ready. --Andrewssi2 (talk) 01:58, 14 October 2015 (UTC)

I'm quite interested to see where this goes. If the maps can someday do what is displayed in this image from the Phabricator link above, it would go a long way in enabling dynamic region maps. Including KML data also looks interesting. I draw static maps based off of shape files, but I think I could export them (or at least some features) as KML files, too. -Shaundd (talk) 04:31, 14 October 2015 (UTC)

Re: transport POIs, it's a welcome improvement, but still fairly patchy. Just checking Melbourne, tram stops and tram lines are completely absent, although train stations/lines and bus stops have been added (they're hit and miss, but that's an OSM data issue). Ferries are also absent.

I also agree with Andrew that any implementation into Wikivoyage itself must be done slowly and progressively on a few articles at a time, to test for bugs and other issues. While the new banner extension which was recently implemented is welcome, the implementation was very poor, with dozens of issues and bugs causing and continuing to cause sitewide issues and I'm disappointed it was not implemented more carefully. We do not want to see the same mistakes repeated with Wikimedia Maps. James A ▪ talk 08:42, 14 October 2015 (UTC)

Not to sidetrack this thread, but in fairness to User:Sumit.iitp the initial banner rollout was done on a small number of articles, went through several feedback cycles, and overall went quite smoothly. It has mainly been the many surprise changes to the extension since then that have resulted in sitewide issues. -- Ryan • (talk) • 21:51, 14 October 2015 (UTC)

In the real world, if something changes in the underlying system then is actually quite common in IT for end users to blame those associated with that change when something goes wrong. I feel that there should be better transparency and formal process in new changes so that we can avoid exactly that perception.

I raise this now precisely because I don't want to see those people who are spending time and doing awesome work in improving the technical implementation of the site getting wrongly blamed for new problems just because they were associated with (for example) a new map system.

It would help if we could have a dedicated page on WV for announcing and discussing technical changes, rather than using the pub which I believe invariably causes confusion to most. A request to change the CSS file should not (for example) be posted here because it just looks bad when something goes wrong afterwards (rightly or wrongly). Just my 2 cents. Andrewssi2 (talk) 00:25, 15 October 2015 (UTC)

You know, an ideal system would involve things like CSS changes being handled like real code, rather than like changing words on an article. The person proposing the change ought to be able to submit a suggested "edit" (a patch) that isn't live until other knowledgeable people have reviewed it and approved it. Unfortunately, there's no way to have a "two-key system" in MediaWiki right now. WhatamIdoing (talk) 20:52, 15 October 2015 (UTC)

Yurik, summarizing the relevant part of this thread, it would be nice to have more transport POIs per JamesA's suggestion above. Once these new POIs appear on maps.wikimedia.org, we can switch a few pages to the new maps. Then we will ask for a broader feedback that, again, will most likely concern the content of the maps and not their implementation. This whole process will go much faster if our current map server has another long downtime, so that everyone understands what real benefit the new map server has... --Alexander (talk) 07:35, 15 October 2015 (UTC)

So, should I make the lab servers crash again to promote maps? :)))) Anyway, Max will see what he can change with POIs, and I will regenerate the data the moment he is done. In any case, once POIs are "good enough" for a certain region, we could try adding them to the articles of that region to have a wider visibility/discussion. Lastly, what page is the best for the tech discussion on WV? Thanks! --Yurik (talk) 18:10, 15 October 2015 (UTC)

I think that Pub is the best place for this, and in fact it is the only page that everyone reads. --Alexander (talk) 19:21, 15 October 2015 (UTC)

Alexander - I'm not suggesting you stop announcing these things on the pub, but I am suggesting that the technical detail should go into a separate discussion page.

WhatamIdoing - You are right that we can not have a good technical process, such as a GIT pull request. We could however create a formal page for these changes to be announced and discussed, something like Wikivoyage:Script_nominations . If there is support I can go ahead and progress this. Andrewssi2 (talk) 21:56, 15 October 2015 (UTC)

Can you clarify what is being proposed? If the goal is to "approve" services used by Wikivoyage that are managed elsewhere (such as the banner extension), a local page won't make any difference since those tools are going to get deployed whether or not we approve them, and it is up to us to track them and stop using them if they become problematic. If the goal is simply to have a place to discuss things like the banner or maps outside of the pub, would a separate page be the best way to handle that, or would it be better to just suggest moving discussions to Wikivoyage talk:Banners or Wikivoyage talk:Dynamic maps Expedition if things get too detailed? -- Ryan • (talk) • 22:15, 15 October 2015 (UTC)

Not 'approve' but 'formalize'. I believe the way technical changes are proposed (the above being a good example) is too ad-hoc for comfort. Announcing a change on the pub and pointing to Wikivoyage talk:Banners or Wikivoyage talk:Dynamic maps Expedition would help a great deal, although if this is too hard for people to practice then a separate page would help as a focus point. I don't buy the fact that we have to have everything on the pub because "it is the only page that everyone reads".

I maintain that having too much technical discussion on the pub is inappropriate and causes confusion, and therefore I was only trying to help by suggesting a better way of doing things. If there is no support for this position then fine, I won't persue it any more and let things run as they are. Andrewssi2 (talk) 20:46, 18 October 2015 (UTC)

Individual engagement grant for Wikimedia Maps rendering

Swept in from the pub

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

Dear Wikivoyage, please support this proposal - Paul is an expert in the field, and has already helped us with many mapping issues. If he gets a grant, we will be able to substantially improve the quality of our maps.

P.S. @Atsirlin: @JamesA: Transportation POIs are now part of the map (here), and should finish generating in the next day or two. --Yurik (talk) 14:09, 29 October 2015 (UTC)

Blockers and non-blockers

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

I acknowledge this may take time, and I don't want to hold up the entire process. If you guys wanted to seek consensus to test on one or two articles, I wouldn't oppose that. But it's still not ready for site-wide deployment. James A ▪ talk 00:14, 30 October 2015 (UTC)

@JamesA:, thx for the feeback, and you are right! The raster style is well polished, but cannot move forward - there is no map in Melbourne article because servers will melt :) Kartotherian is not as polished, but it can improve much better. But the only way WMF will allocate more resources to Maps, is if Maps are used more than the current 3.5K users/day, 100K tiles/day. (see stats). Plus, if many users don't like something, there is a higher chance one of them will volunteer to fix it. So we could try to get it all perfect before using it on high-usage pages, or we could offer the non-perfect service with the expectation of a much more rapid fixes. Regardless, any help is welcome to try to make it better :) --Yurik (talk) 01:59, 30 October 2015 (UTC)

I'd prefer you guys start implementing on a few pages, and go from there, rather than us sit here and nit-pick all day! The map itself seems to work, with a few minor bugs in regards to labels. I'd suggest you guys go ahead and create a new topic below in the pub proposing implementation on 10 pages or so as an initial test :) James A ▪ talk 08:30, 30 October 2015 (UTC)

Yurik, I started a discussion in Russian Wikivoyage where it may be easier to reach consensus instead of doing 10 pages (and testing what?). Since I guess that you read Russian, you are welcome to join.

Here I will try to organize deployment on a few pages in the beginning on next week, unless you or someone else will do it earlier. But mind my previous comment: the consensus for the new maps will be immediate when the current map server stops working again. On the other hand, you may spend ages trying to address every comment of ever user here. --Alexander (talk) 08:38, 30 October 2015 (UTC)

All we need for now is for Joachim (please and thanks!) to replace the current poimap2.php, with the poimap2test.php as it is functionally the same except for the additional layer. Discussion about where the Wikimedia layer is to be used, or when it can replace the Mapnik layer as default, can be discussed separately - instead this will just act as another option in {{Mapframe}}, eg. the relief maps and Mapquest Open previously, though Module:Layers needs to be checked for restrictions. I also think there is still a little bit of misunderstanding about what the Wikimedia map server can do for now, because any stoppage of the current map server in Tools Labs will occur regardless of whether the new Wikimedia layer is being used. In future plans as said, hopefully it can be moved wholesale to the Wikimedia map server, though I'm not sure how they'll handle external developers. -- torty3 (talk) 11:29, 30 October 2015 (UTC)

I agree. poimap2test.php can be and should be merged into poimap2.php (Joachim, Danke im Voraus!), and new Wikimedia maps will appear as a non-default layer in every article. However, this does not answer Yurik's question. They need more usage and more traffic, and this won't come unless their layer is used as default. --Alexander (talk) 13:13, 30 October 2015 (UTC)

Poimap2 now has a new layer "Wikimedia" (layer=W). Therefore, "B&W" layer is no longer present. "Mapnik" layer is further default. Update runs on Monday if no other opinions. -- Joachim Mey2008 (talk) 07:18, 1 November 2015 (UTC)

I applaud the work done, and I'm looking forward to where it will go and to using it. However, I agree with JamesA that it's not ready for wide implementation just yet. @Yurik, is this assumption that WMF will only allow progress on your maps work when it's already widely implemented an actual management decision? Or is it just your expectation? I'd be surprised, considering the experiences with VisualEditor and Mediaviewer. Surely if we, as a community, confirm our interest and commitment to this project it can first be properly developed before we implement it site-wide? JuliasTravels (talk) 15:09, 1 November 2015 (UTC)

I don't work with that team, so I don't know any specifics. Speaking generally, most of the teams will start talking about their quarterly goals (for January through March 2016) later this month. The teams won't be deciding "Maps or no maps?". They'll be deciding "Maps (which is barely getting used) or this other thing (which might have a bigger effect)?".

If you want more development on Maps, then your goal will be to convince them that Maps is a better use of their time than any alternative project. This is generally done by deploying it now (or soon), or by agreeing that you will accept it as soon as it reaches a specific, defined level. This second option requires producing a complete list of actionable blockers, and agreeing that the community will prevent the goalposts from shifting. Making a list of non-blocking requests is also very helpful, because it helps people differentiate between things that are useful or desirable, and things that are absolutely necessary for the product to be functional. (Also, it increases the chance of getting what you want.)

The line between "blocker" and "non-blocker" can be drawn wherever you want. However, you should remember that getting continued work on a project like this is a negotiation between you and the devs (and indirectly, with the rest of their department, which might want them to stop work on Maps and instead focus on something else), so the higher the "price" you put on your agreement, the less likely you are to make a deal in the end. WhatamIdoing (talk) 23:31, 3 November 2015 (UTC)

Yes, absolutely! --Alexander (talk) 00:59, 4 November 2015 (UTC)

Well said WhatamIdoing, thanks! Highly recommend it to everyone. JuliasTravels, unlike Visual Editor, the maps has been done by two engineers with the blessing of our immediate managers. Now our managers need to convince their higher ups that maps project should be invested in. Our numbers is what everyone will look at at the end of the day. This quoter is dedicated to working with the community, see what feedback we get, what should be improved. Also, I am working on [[mw:Extension:Kartographer <maps> tag]] to bring some of the amazing work poimap2 has done to production, suggestions are welcome. --Yurik (talk) 19:44, 4 November 2015 (UTC)

New map layer added for Wikimedia/Kartotherian

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

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

I would suggest you guys start a new discussion at the bottom of this page. This recent discussion here in this thread hasn't engaged a very large cross-section of the community, probably because it's not very visible. Otherwise, I suspect there may be a lot of unhappy people post-implementation. We had a lot of bugs after the banner extension went live, and continue to have a lot of bugs. I know a lot of people worked hard on that project, but such rushed implementations are simply not ideal. I certainly support a wider implementation, but not on a huge scale which could have significant effects on thousands of our articles. James A ▪ talk 13:07, 6 November 2015 (UTC)

What means "wider, but not on a huge scale"?

I also think that constant references to the pagebanner extension are absolutely irrelevant here because we do not discuss any functionality available on site. We discuss changing one tile server to another tile server, while the functionality of poimap2.php and {{Mapframe}} will stay exactly the same as before. Neither the template nor the poimap2.php script are going to fail when they take the data from another tile server. --Alexander (talk) 13:42, 6 November 2015 (UTC)

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

• I have just made this switch at the article on Istanbul's Old City, to check it out. I noticed losing all the street and attraction's names, and most urban transport routes, which I think it's not cool. Ibaman (talk) 14:36, 6 November 2015 (UTC)

Street names are there when appropriate zoom level is used. The lack of other features has been explained above. --Alexander (talk) 14:49, 6 November 2015 (UTC)

Ibaman, are you talking about Istanbul Old City? I just tried the layer switcher, and noticed that it still showed most of the street names. What exactly did you miss when you switch? Also, by attractions, do you mean POIs generated by poimap2? Or something that is part of the map itself? In any case, please see the comment by WhatamIdoing above - community needs to be very specific on goals and blockers so that we can move forward. There is no unicorn, but we can certainly work towards perfection. --Yurik (talk) 22:58, 6 November 2015 (UTC)

Issues: Roads under bridges

Tracked in Phabricator ^(?)
Task T117313

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

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

Issues: Transport POIs

Tracked in Phabricator ^(?)
Task T113310

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

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

Issues: One-way roads

Tracked in Phabricator ^(?)
Task T113913

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

Issues: Map sync time with OSM

Tracked in Phabricator ^(?)
Task T110262

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

How often is the data recollected from OSM? -- torty3 (talk) 10:30, 11 November 2015 (UTC)

Once implemented, it will be done multiple times per day. MaxSem is working on it right now. --Yurik (WMF) (talk) 01:05, 12 November 2015 (UTC)

Issues: Language

Tracked in Phabricator ^(?)
Task T112948

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

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

Consensus to change default map layer to Wikimedia/Kartotherian

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

I give my support to changing the default layer to the new Wikimedia Maps, although only under the condition that it will be continually improved in the near-future. Every time I use it, I note more and more problems, such as a lack of distinction between roads at different levels in the hierarchy (in some cases, gravel roads are marked the same as 4-lane highways). However, I understand that we cannot continually stall the process and also desire some progress. I note that those guides which were apparently changed to the Wikimedia default above (such as Salzburg) still appear as Mapquest Open for me (indeed, all my maps are Mapquest Open, Mapnik is never the default). James A ▪ talk 11:23, 11 November 2015 (UTC)

Tracked in Phabricator ^(?)
Task T111884

Without more definite support, I would perhaps suggest the Maps team (@Yurik:) improve some of the map rendering:

1. Give train stations and ferry terminals labels at zoom level 16.
2. Make train stations and ferry terminals more prominent icons than bus stops at zoom levels higher than 16.
3. Remove bus stop labels? (this is iffy)

Once that's done, we will switch right away to using the Wikimedia layer as default, although if more people chime in, an immediate switch could occur too.

Apparently gravel roads being marked the same as highways is a debate of style, see phab:T111884. -- torty3 (talk) 14:30, 17 November 2015 (UTC)

Comment. I'll defer to torty3 on issues related to maps and will support a change if recommended, but could someone summarize what is being proposed, and why? As I understand it:

1. We want a map service that is fully supported by Wikimedia, and this proposal will switch to a service that will eventually get that level of support.
2. At the present time that service isn't as good as the existing maps (see the bugs and feedback above).
3. There is a belief that only by increasing usage of this new service will it be given the needed attention to improve.

Is that correct? Again, I'm happy to do what the people who support our maps infrastructure want to do, but if wider support is being requested then it would be nice to better understand what is being asked. -- Ryan • (talk) • 15:34, 17 November 2015 (UTC)

Yes, it's a fair summary. Technically, the new map service is already supported by WMF because its developers are WMF employees. --Alexander (talk) 16:46, 17 November 2015 (UTC)

Support per the discussion above. --Alexander (talk) 16:46, 17 November 2015 (UTC)

Seems like a leap of faith in many ways, but all efforts to move towards a stable map tool are very much appreciated. Support Andrewssi2 (talk) 22:10, 17 November 2015 (UTC)

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

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

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

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

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

While I agree with your statement, I don't agree with that action at all, which would be a de facto non-change given that the vast majority of articles would have zooms higher than 13 (at least for cities). I'm even a little pessimistic about the volume of traffic the developers expect to measure before such a hobbling, let alone after. Just to note for posterity, currently 2279 cities have mapframes and 21571 articles have a link to the map. It is possible, but also with added complications eg. conflicts with other Wikivoyages

To add one more point to Ryan's succinct summary: that definite blockers that prevent action (transport POIs was one) be set otherwise. I think the discussion has been constructive though, in gathering a list of concerns/non-blocking items from the community that should assist developers in deciding the priority for tasks, and also a sample of map style design philosophy for low, medium and high zoom levels (still more work to be done here). @Yurik: One more refined request for map labelling too after a bit more checking, for airports, train stations and ferry terminals to be labelled at zoom levels 15 and below.

Nonetheless, I'm going to plunge forward and make the change, it's easily reversible after all and individual pages can be set to Mapnik. -- torty3 (talk) 13:13, 21 November 2015 (UTC)

@Torty3:, this is the first level (z14) that shows transportation POIs, including ferries. We have been thinking about hiding everything at z14 (phab:T117154). Is that what you are asking? Or are we missing some transportation POIs at z15 somewhere? --Yurik (WMF) (talk) 00:29, 22 November 2015 (UTC)

P.S. Thanks for switching!

I think that may be a good move, or perhaps the size of the icons could be reduced also? The transportation POIs are all there, but I was trying to distinguish between icons and labels. Labels only show up at z17 right now. Train stations and airports are usually good landmarks, so the label names would help at z15 and z16 (after checking through most city and city district articles are using those levels), although that is at your discretion. Also in my opinion bus stop labels are never shown on most maps, and ideally POIs at z17 and z18 would look something like POIs at z16 in terms of icon size difference. -- torty3 (talk) 03:57, 22 November 2015 (UTC)

Crossing the 180th meridian causes problems

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

Map layer option in User preferences?

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