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)Reply

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)Reply

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)Reply

@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)Reply

@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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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, [email protected] 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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

The problem is not the script but the Tools-Server. They are running many applications at . 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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

"Internal Server Error

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

Please contact the server administrator, [email protected] 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)Reply

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)Reply

@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)Reply

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)Reply

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

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Geomap shows decimal places according to the object size. Examples: United States , a building . 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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

These two markers 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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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

I like the existing static region maps pretty well. Here is an example of a dynamic region map . 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)Reply

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: , and .

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

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

(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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

"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)Reply

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)Reply

"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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

I tested extensively on real hardware and could find no errors. Example: Debian 6.0/FF 28/https/not logged in . 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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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 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)Reply

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 in