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

Spiderfy[edit]

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

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

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

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

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

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

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)[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}} [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)[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 [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)[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: [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)[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 [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)[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 [19] or fully dynamic [20]. -- 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]

Version 2014/18[edit]

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

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

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

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

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

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

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

Version 2014/19[edit]

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

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

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

Version 2014/20[edit]

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

Version 2014/21[edit]

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)[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 [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)[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 into individual listings direcly. Andrewssi2 (talk) 04:19, 30 May 2014 (UTC)[reply]

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)

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

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

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

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

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

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

Missing magnification & layer selection[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug report for print version?[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bugzilla[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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