Hi guys my name is Jon Robson and I work for the Wikimedia Foundation. I've been watching from the sidelines and I'm keen for the Foundation to support you better... At the Zurich hackathon we have created an extension that adds a map namespace with an editing interface and embed support via the map tag. https://github.com/jdlrobson/WikiMaps

Currently it supports GeoJSON but in theory could support other data formats.

I wondered if someone would be interested in playing with it and reporting back if it is useful for the Wikivoyage usecase. If not I would love to hear why and how it could be improved... The foundation is planning on forming a map team and I'm keen as a personal project to consolidate all our uses of maps.. Jdlrobson (talk) 17:33, 10 May 2014 (UTC)[reply]

If we discourage obtaining coordinates through Google Maps interfaces, shouldn't we just delete that section? --Peter ^Talk 00:47, 2 August 2013 (UTC)[reply]

That would seem logical.

This is all completely new to me, so simpler might be better on a How to page for old dogs like me trying to learn new tricks.--W. Frank^e-mail_talk 13:01, 3 August 2013 (UTC)[reply]

Later: I've been trying to find some restaurant co-ordinates in Nelson and found the Google, "what's here" technique very useful for places I can't find easily with the other techniques, so I now suggest keeping this section. The other "green flask" technique seems to have been disabled. --W. Frank^e-mail_talk 13:44, 3 August 2013 (UTC)[reply]

It's more about licensing issues rather than ease of finding the coordinates sadly, so I think removal of the section is warranted. Please state in the Nelson talk page that you found them using Google. -- torty3 (talk) 13:12, 5 August 2013 (UTC)[reply]

I'm sorry, but what licensing issues? Google cannot copyright coordinates. LtPowers (talk) 14:19, 2 September 2013 (UTC)[reply]

They own the assignment of their content (tiles, POIs, etc.) to specific coordinates. --Peter ^Talk 04:19, 4 September 2013 (UTC)[reply]

I've never heard that interpretation before. They own the images, but they can't copyright the fact that "the coordinates of this location are x,y". LtPowers (talk) 14:35, 4 September 2013 (UTC)[reply]

It's actually impossible to define one pair of precise coordinates as the definitive location of a building. Choosing coordinates to represent a POI is subjective work. --Peter ^Talk 21:58, 4 September 2013 (UTC)[reply]

Well now we're conflating two different things. The assignment of map tiles to specific coordinates is definitely not subjective, so choosing our own coordinates for a building on a Google map should be fine, right? We're not copying the specific coordinates Google chose for that particular POI dot. (As an aside, subjectivity is not sufficient for copyrightability; it actually has to be a creative work. Unless you can argue there's an element of non-trivial creativity involved in choosing a particular set of coordinates for a particular POI, it's still not copyrightable.) LtPowers (talk) 13:16, 5 September 2013 (UTC)[reply]

I've checked with a friend of mine and he tells me that, for common law countries, LtPowers is broadly correct in his analysis (but notes that the bar for creativity has been set very low in most jurisdictions). I also need to point out that I don't (and didn't) use the Google co-ordinates at all in Wikivoyage (which is why I haven't credited them on any WV article discussion page). I use Google's facilities to IDENTIFY the building (the streetview photographs can assist greatly in this regard) and then identify the corresponding building on Open Street Map before using their co-ords. --W. Frank^email_talk 15:26, 5 September 2013 (UTC)[reply]

It's not just about whether Google owns copyrights on the coordinates, but that those coordinates have been derived from commercial satellite map providers and requires an interpretation of those underlying licenses. Hence the assignment of map tiles to specific coordinates is actually somewhat subjective, or at least based on commercial sources. Wikimedia as a whole is at one end, collecting a bunch of coords without too much regards to the source, so it's not a go-to-court issue, but OSM staunchly refuses to import coordinates from Wikipedia on the basis that they are possibly taken from Google Maps, and would rather build such data from ground surveys. For practical purposes here, we are covering a lot of the same ground as OSM (except from different angles - WV knows the POIs but not the locations, OSM has the locations but not necessarily the POIs), and it seems a waste to duplicate efforts.

There's just a really huge potential to build an entire copyleft ecosystem of Wikivoyage combined with OSM here, though sometimes I think it really should just be left to profit-making companies like Google (then I think of TripAdvisor and Yelp). -- torty3 (talk) 12:28, 7 September 2013 (UTC)[reply]

Even if what you say about the derivation of the coordinates is technically a problem, I can't see it having any practical effect. For any given set of coordinates attached to a listing, there's no way to tell what source they came from unless the editor puts it in the edit summary. That, to me, is indication enough that this is, at best, a de minimis issue, and more likely a case of complete non-copyrightability. It's like copyrighting the phone book; you can copyright the presentation, but not the phone number listings themselves. LtPowers (talk) 18:31, 7 September 2013 (UTC)[reply]

Which is why Google Maps coordinates are only discouraged and I think it is just good practice that OSM is used as the primary geolocater. -- torty3 (talk) 23:48, 10 September 2013 (UTC)[reply]

PS. I'm alright with leaving the guide as-is actually, after this discussion. -- torty3 (talk) 00:17, 11 September 2013 (UTC)[reply]

Well, to be honest, I'm not sure I trust OSM coordinates. =) LtPowers (talk) 02:33, 11 September 2013 (UTC)[reply]

There are two issues here:

• In most countries with an IPR based economy, there are statutory database rights, as well as copyright. Database rights apply to collections of data even when there is no element of creativity. All maps are databases, in this respect. Reproducing significant parts of a database is a protected act. The nature of OSM is such that if it allowed Google maps as a source of coordinates, it would end up doing exactly that.
• Google have explicit terms of service that forbid it, and would probably try to argue that you form an agreement with them, when you use their services.

(Additionally, a lot of POI locations on Google Maps are wrong, typically because they are supplied by advertising agents based on zip codes, rather than based on either a surveyed location, or the position relative to other features.)

-- 81.187.250.222 16:14, 2 April 2017 (UTC)[reply]

Using Google lat & long indirectly? I've noticed a lot of places (bar, cafe, restaurant own web sites, their domain) will embed a Google Map (e.g. on their "Find Us" page) with a link to a larger map. Often that link URL will include the lat and log very clearly/obviously in the URL. I would have thought that as the link is part of the establishment web site, the coordinates would also be from the establishment so, would I be right in thinking that it would be acceptable to take the coordinates from the "Larger map" URL ? PsamatheM (talk) 22:26, 22 May 2017 (UTC)[reply]

Please forgive my ignorance, but is there a way (short of actually editing the current template - which I don't feel qualified to do) to make the POI icons that appear on the map a little bit smaller and less obtrusive? Personally, I'd like to have the blue box in the article text about 25% smaller and on the map 35% smaller. Is there an undocumented switch or parameter I can use to achieve this, please?

I've experimented with {{Poi|1|sleep|-41.27561|173.28499|Accents on the Park}} to produce:

{{Poi|1|sleep|-41.27561|173.28499|Accents on the Park}}

-41.27561173.284991 Accents on the Park, 335 Trafalgar Sq, ☏ +64 3 548-4335. Check-in: 14:30, check-out: 10:00. Beautifully decorated, clean, safe and friendly hostel, with one of the best locations in the city of Nelson. Internet, lounge, kitchen, laundry, helpful staff and an adjoining bar that makes fantastic burgers. $27-33 per person, shared dorm. 

and then {Mapframe|-41.2709|173.2839|zoom=15|height=470|width=470|layer=M}}

but the resulting icons on the map seem a bit overwhelmingly large and overly obtrusive, don't they? --W. Frank^e-mail_talk 13:01, 3 August 2013 (UTC)[reply]

A lot depends on the scale of the map, the distance between roads, and the density of icons to be displayed. As it stands right now, the icon looks fine to me, right at the top end of acceptable size given the other parameters. LtPowers (talk) 23:04, 3 August 2013 (UTC)[reply]

The discussion about icons can be found here, and would be better continued there. I find the map icon to be just nice for me, any smaller and I can't read it. Currently the Poi template hasn't been adjusted, so please don't add it to articles yet. It will probably be reserved for in-line points of interest, compared to indented {{listing}}. I'm open to adjusting the one in the article (see above link). Is there a reason you prefer the Mapnik layer for Nelson? Default has it at Mapquest Open. -- torty3 (talk) 13:11, 5 August 2013 (UTC)[reply]

If I may answer your last question first and answer the other points later, Torty3?

I haven't checked what it's like in other areas, but for the central part of Nelson, NZ, "Mapquest Open" is grossly inferior. Leaving aside my subjective preferences of hue and road width sizing, etc, consider just four of the MAJOR landmarks "Mapquest Open" omits:

1) Nelson's rugby ground and cycle track (which hosted Rugby World Cup games) at the northern end of Trafalgar St, opposite Wainui St.

2) Nelson's main indoor performance venue, the Trafalgar Centre (due west of Nelson's missing rugby ground and cycle track) is not named.

3) Nelson's main kid's soccer and kite-flying venue, Neale Park is not named.

4) "Trafalgar Square" is prominently named (but a depiction of the famous Cawthron or Church Steps is missing) as if it were a real square (rather than a hill) - in reality, it is a little known truncated street name (for Trafalgar Sq West and Trafalgar Sq East which are two very short streets that run North-South of either side of Piki Mai) ! Crucially, Nelson's Christ Church Cathedral (which stands at the top of Piki Mai or Church Hill and is ridiculously labelled as "Trafalgar Square") is missing even when enlarging this inferior "Mapquest Open" map layer two, three, even four notches to maximum! --W. Frank^e-mail_talk 22:15, 5 August 2013 (UTC)[reply]

Thanks for the comparison. Some of the issues you mention are because OSM Mapnik is more flexible in what they show, i.e. undocumented parameters are sometimes shown, and it's worth correcting them directly in OSM. Also interesting to note which items are not labelled in Mapquest Open (sport fields are one of them apparently). -- torty3 (talk) 10:05, 10 August 2013 (UTC)[reply]

The current text says "There's an additional image parameter that can be added to be viewed on the map. Syntax: image=filename"

Is this intended to be an additional parameter to be added to our standard listing template - or somewhere else? If the former, then why is this edit fruitless, please? --W. Frank^e-mail_talk 20:49, 9 August 2013 (UTC)[reply]

Can someone confirm this functionality before it is included in Wikivoyage:Listings? Template:Listing does not currently include an "image" parameter. -- Ryan • (talk) • 00:58, 10 August 2013 (UTC)[reply]

I don't think the functionality is contained in the code of {{listing}} or any similar template like {{sleep}}. However the information that I added with this edit does work - I've now tested it and answered my own question above, although it was difficult to test because my ISP caches the mao - so I assume that {{mapframe}} pulls the information from the attribute... --W. Frank^e-mail_talk 01:20, 10 August 2013 (UTC)[reply]

The external script "PoiMap2" reads the necessary information from the stored articles. After saving, please reload page twice. Once for article text, once for Mapframe. - Please do not use POI with the same coordinates. The icons are placed one above the other. Only the top (last in the article text) remains visible. I had solved the problem with "clustering" and "spiderfy". But some users have asked me to disable it. -- @Frank W.: Thanks for the complement of the descriptions. I have updated it. Every day something new :-) -- Joachim Mey2008 (talk) 05:34, 10 August 2013 (UTC)[reply]

Is spiderfy possible without the clustering? I think the problem was more to do with that. -- torty3 (talk) 10:01, 10 August 2013 (UTC)[reply]

Yes, if there are no votes against. -- Joachim Mey2008 (talk) 10:17, 10 August 2013 (UTC)[reply]

It currently looks like there are several different templates being used for map listings:

• Template:Listing (and all of its variants)
• Template:Listing/sandbox
• [[Template:Poi]]

As the dynamic map capability is being expanded to more articles, can we consolidate this down to a single listing template? To this point it has made sense to keep things separate, but it might be good to get this organized before usage expands into too many articles. Apologies if this is discussed elsewhere, but I haven't followed every thread related to dynamic maps implementation. -- Ryan • (talk) • 05:42, 10 August 2013 (UTC)[reply]

The tl:POI (without automatic numbering) should only be used for inline text . The tl:listing/sandbox no longer required if the automatic numbering of listings with coordinates is activated in a few days. Then only needs the known tl:listing and its variants. -- Joachim Mey2008 (talk) 06:02, 10 August 2013 (UTC)[reply]

Apologies on my part as well, I intended to combine the templates last week, but decided to wait for the conversation in the pub to play out first. I think there is a fairly wide agreement, and in light of the listing editor as well, will start switching them out now. -- torty3 (talk) 09:59, 10 August 2013 (UTC)[reply]

So is Firefox's new reticence toward showing unencrypted content on an encrypted page the reason dynamic maps show up as huge empty boxes for me at the moment? If so, this strikes me as an enormous problem, one which should cause us to stop putting them in articles entirely until it's resolved. LtPowers (talk) 17:24, 29 August 2013 (UTC)[reply]

The Firefox function "block mixed content" is still incomplete, an exception list is missing. However, the following solution is possible:

• Open the advanced configuration: about:config (address bar)
• Search for: k_a
• Set "security.mixed_content.block_active_content" to "false" (double click)

Done. -- Joachim Mey2008 (talk) 04:07, 4 October 2013 (UTC)[reply]

That's helpful on an individual basis, but we cannot expect everyone who visits the site using the HTTPS protocol (especially so now that it's the WMF default) to have taken that action, or even to know that they should. LtPowers (talk) 12:23, 4 October 2013 (UTC)[reply]

True, but I believe this problem is now solved, isn't it? --118.93nzp (talk) 01:35, 25 November 2013 (UTC)[reply]

Is there a way to isolate only one type of icon on the dynamic map like "See" or "Listings" so that we can more clearly show more important sites? Otherwise they get lost in a sea of restaurants, bars, and hotels. Specifically, I want to isolate "Listings" for Ulaanbaatar so I can display a zoomed out map of bus and train stations located far from the center of the city.Altaihunters (talk) 01:15, 25 November 2013 (UTC)[reply]

Great idea! Let's hope the developers consider a switch... --118.93nzp (talk) 01:34, 25 November 2013 (UTC)[reply]

I found {{mapmask}} recently by accident and really like the effect it creates. However, it's marked as experimental and shouldn't be used more than once. I've just added it to a map (London/South Kensington-Chelsea, copying Amsterdam/Binnenstad), which is it's twelfth mainspace instance. I can't find a discussion about this anywhere, either for or against, so can I use this template further? I'm not sure how the consensus process works here. I'd like to do so; it looks as if it would help a lot with city districts, where it makes the borders of the area especially clear. - AdamBMorgan (talk) 00:22, 23 January 2014 (UTC)[reply]

Unless anyone is aware of a downside of that template (performance or something else) then I would very much support removing the "experimental" tag as it looks like a hugely useful feature. -- Ryan • (talk) • 00:40, 23 January 2014 (UTC)[reply]

We can't remove the experimental tag until we have a consensus to do so, and as far as I can tell, the template creator has never started a discussion about it (unless he did it without linking it, which would be odd). It does look useful, but it needs some thorough testing and tryout. (In that vein, I'm fine with leaving its expanded use in place in contravention of the usual experimental requirements.) Powers ^(talk) 00:50, 23 January 2014 (UTC)[reply]

The creator, Joachim is doing some fantastic work around dynamic maps. I get the impression that he would prefer to see this feature fully mature before advertizing widely and moving out of the experimental tag. It seems to have been only a month since it was introduced, although I hope a discussion could start in the near future. Andrewssi2 (talk) 00:58, 23 January 2014 (UTC)[reply]

Yes, I first wanted to test some files. My interim conclusion: Mapmask is suited for simple masks with a few inflexion points. It handles masks with any number of points. But then there are long lists of coordinates in the article source code. But in general, my tests have shown that Mapmask can be used in this form. Mapmask not generate server load. The entire presentation is done by the browser. - A tip: five decimal places are ideal (which is ≈ 1m accuracy). - For masks with many points an external file as GPX template is planned. - Joachim Mey2008 (talk) 06:18, 23 January 2014 (UTC)[reply]

OK. I misunderstood (and, as I said, mostly tried to copy another guide), I'll stick to the blue GPX boundaries for now and hopefully come back to mapmask when its up and running. Thanks, AdamBMorgan (talk) 21:18, 23 January 2014 (UTC)[reply]

The look of the mask I can modify as desired. Gray values​​, borderline, etc. An extra GPX file is not required for this purpose. I have taken the style of static maps for Mapmask. - Joachim Mey2008 (talk) 06:43, 24 January 2014 (UTC)[reply]

This is an especially useful facility for outlining regional borders since we have so few contributors that are able to create static maps. I have a question: you say that five decimal places are ideal, Joachim, but are there any deleterious effects when an unnecessarily high level of accuracy is used (or when the inflexion points are only specified to one or two decimal places - apart from vagueness, of course)? --61.29.8.41 08:39, 24 January 2014 (UTC)[reply]

No, the script handles any number of decimal places. But more than five digits are not required. Less than five decimal places result in an unsightly effect. The mask runs in large zoom levels no longer exactly parallel to roads or other map elements. - Joachim Mey2008 (talk) 09:42, 24 January 2014 (UTC)[reply]

It's a gorgeous tool, but it could be even more useful if it were able to read coordinates from a separate GPX file and to depict several districts with different colors. The scope of each article is more or less clear from the spread of its listings. But smaller areas within one article would be good to show. --Alexander (talk) 09:54, 24 January 2014 (UTC)[reply]

That there is in its infancy. But it is still too complicated for the average user. It must be made for each district only one track segment [1]. And the points have to be in the correct sequence. Otherwise it is quite colorful, as in the example [2]. In addition, the areas can not colorize the time. - A useful version for area / regional maps will take some time. - Joachim Mey2008 (talk) 10:28, 24 January 2014 (UTC)[reply]

It looks pretty good! And I don't care too much about simplicity. "Average users" can still do a lot of work on adding coordinates for individual listings=)

Can one also make transparent color fillings in addition to colored district borders? --Alexander (talk) 10:59, 24 January 2014 (UTC)[reply]

Transparent color fillings are not a problem. [3]. But I want to create only a mask maps here. This is often used in cities to mark the boundary of an article, even though there are no markers. -- Joachim Mey2008 (talk) 13:17, 24 January 2014 (UTC)[reply]

OK, clear. Consider transparent fillings as my non-urgent feature request then=) --Alexander (talk) 13:31, 24 January 2014 (UTC)[reply]

Yes, that would be nice and they could be quite useful at low zoom levels, although the detail at high zoom levels would probably make the tint difficult to see for most areas. --61.29.8.41 22:47, 24 January 2014 (UTC)[reply]

I have been looking for guidelines around using Dynamic Maps beyond their default values, and can't see any.

I am seeing a few interesting uses of Dynamic Maps, including those sized at 600x600 pixels and centered right in the middle of the article.

Are we OK with this level of flexibility without guidelines? What if two contributors have different views?

Andrewssi2 (talk) 06:35, 13 June 2014 (UTC)[reply]

Often they are a form of a square, but in practice many different sizes are used. Personally I don't think all the maps should have to be the same size either, for example if there is a city stretching from west to east, something like h=400, w=800 works much better. ϒpsilon (talk) 07:15, 13 June 2014 (UTC)[reply]

Yes, that works with static maps to an extent (The image is just smaller until you click on it). Wouldn't 400x800 be pushing a few monitors? --Andrewssi2 (talk) 08:38, 13 June 2014 (UTC)[reply]

When last this came up the results of the discussion were to put the map at the top of "Get around" and to use the default size and position unless the location was of a shape that called for something else - such as a long location that needed a taller map. See Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment. -- Ryan • (talk) • 15:06, 13 June 2014 (UTC)[reply]

Was about to say the same thing. Which means (a) it should not have its size expanded from the default unless there is really no other way to get it to show the area in question, and (b) it should never be centered unless legitimate changes under condition (a) make it impossible not to do so. Personally I'd like to see us try not to center them ever, as it creates a giant chasm in the flow of the article, tends to create a lot of white space, and multiplies the chances for that unpleasant phenomenon of scrolling down an article and then suddenly finding that you are zooming a dynamic map way out instead. Texugo (talk) 15:17, 13 June 2014 (UTC)[reply]

Here's the earlier discussion: Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site?. -- Ryan • (talk) • 15:21, 13 June 2014 (UTC)[reply]

Thanks for the context discussions. The map I am concerned about is Stuttgart. I discussed on the talk page, and the reason to have it so large is to avoid the 'yellow pluses', which I do not beleive is a sufficient reason to create such a large map (and with it force it to be centered)

From the discussions already made above, can we create some conditions where changing the default map size is appropriate? Andrewssi2 (talk) 06:25, 14 June 2014 (UTC)[reply]

Another example is the inner city of Munich: Munich/Altstadt Andrewssi2 (talk) 06:32, 14 June 2014 (UTC)[reply]

I would propose to review the guidelines. From the point of view of readability, a map of remotely legible size creates a very constrained bit of text that is hard to read and, if it contains POIs and listings, is a terrible mess of a layout. Secondly, I believe it is in the best interest of the traveller for us to use the largest zoom size possible. There is no point of just sprinkling some colourful dots and yellow pluses over a small map and calling it a day. It should be a valuable and useful reference.

I have been doing my best of centering the map and making its size as useful as possible considering common (laptop / desktop) screen constraints. Very rarely do I arrive at a size that would even remotely allow for the text to flow around it, so I tend to use aling=none. And I believe I am doing the travellers a favour, even if not following the guideline. My conclusion is thus to review the guideline. PrinceGloria (talk) 07:22, 14 June 2014 (UTC)[reply]

Ouch, sorry, now I see that that aren't any guidelines. I would go by those:

• Make sure all of the POIs are included (we kind say that already). If this requires for the map zoom level to be excessively low to the point that many POIs became clustered into yellow pluses, or if a POI or small number of POIs are outliers requiring for you to stretch or zoom out the map just to include them, consider leaving some outlying POIs out of the map
• Use the highest zoom level you can given the above. The deeper you zoom in, the more detail is included from the map layer, which will help readers in navigation and locating the POIs vs. other features of the locality (streets, squares, bus stops, green areas, water features etc.)
• Use a shape (width / height) that allows you to include as many POIs as possible at a selected zoom level. Do not exceed (let's discuss - I'd say 800 given how Wikivoyage displays in most browser windows on laptops) in width and (let's discuss - I'd say 800 given how Wikivoyage displays in most browser windows on laptops)
• Do not make the map any larger than you absolutely need it to be given the above. If your POIs can fit in a 400x400 map, keep it that size even if one POI gets left out. The next zoom level will probably need 800x800, which is too much.
• If this results in a MapFrame window that is wider than (let's discuss - I'd say 400), center the map (align=none) not to create blocks of text that are too narrow and hard to read.

If we adopt the above, I would suggest to move the default placement of the map to RIGHT ABOVE the Get Around heading rather than below it. PrinceGloria (talk) 07:41, 14 June 2014 (UTC)[reply]

Thanks for your input! Yes the lack of guidelines needs to be discussed.

I do not agree that the cluster of yellow plus icons are actually a problem. They are in fact a solution to a previous issue of POI's overlapping to heavially. I don't beleive they need to be avoided at all.

Also if the width of the map is 800 pixels then that basically changes the convention of Wikivoyage articles significantly (for both static and dynamic maps). I just don't beeive a massive map in the center of the article makes for a clean guide, as well as the reasons stated by Texugo above.

I'm open to hear the opinion of others and be persuaded by change of convention. I do feel however that each article should not be about the viewing preferences of the individual contributor but rather a consistant and agreed experience agreed by everyone. Andrewssi2 (talk) 10:36, 14 June 2014 (UTC)[reply]

Before others chip in, let me present my POV:

First off, I find the dynamic map the paramount and most important feature of each guide. The two most important sense that travel guides cater for are sight and spatial orientation. This makes the dynamic map of paramount importance - it is the cornerstone of each article, the content we provide acquire a new depth of meaning when we can place it on the map and relate to it. We change it from a story we tell to spatial directions one can follow. We make the city or district possible to be imagined and understood in a spatial way.

Secondly, the dynamic map is what sets us apart from many other sites, and to me is the best feature we have. We should make sure everybody takes note, so giving extra prominence to the map, e.g. by making a pronounced break in the article and making it large, is important. Of course one can open the large map in a different window, but not all people will find that useful, and you have to first know that it's there and that it is useful to know you can do it.

Furthermore, the map should be legible and useful as it is placed in the article. Sure we can zoom in and out, click the yellow pluses, open full size in another window etc., but that is something the user will only learn over time, and it is not very useful to have a map that requires a lot of manipulation. After reading the "understand" section and perhaps the "get in" section, one should take a glimpse of the map, get the general idea of the area, locate key points, then scroll further and relate everything they read to the map by means of POI icons and numbers. If the map is not legible and many POIs are displayed as yellow pluses in clusters covering most of the zoomed-out area, this is simply neither legible nor useful.

Lastly, while we are still sorting out the issues with dynamic map printing, I believe that our articles should print WYSIWYG - mostly because it is very hard to edit them with print in mind otherwise. Graphical presentation is as important as content here - a travel guide needs to be easily accessible and make the most of the graphics it uses. It is not just a novel with liberally sprinkled illustrations. Therefore, we should format for a large, legible map that is actually useful in print as well, when the user has no access to zooming and scrolling.

As too 800px, we may agree on a different width, but I believe the centering of the map and not allowing text around it is a boon to readability, especially on smaller and low-res screens. As to the mobile versions, I believe the map should display differently altogether, perhaps as a link or perhaps in a predetermined size. PrinceGloria (talk) 14:52, 14 June 2014 (UTC)[reply]

PS. I have put quite a bit of effort into each article where I placed the dynamic map for it to present the area and the POIs the best way it can and be most useful both as displayed on screen and potentially in print. I'd hate for it to go to waste just to preserve some uniform size and formatting standard. I believe we should be flexible and put the traveller's interest first.

• Mark me down as not being worried about yellow pluses either (at least as long as they're not so very close to each other that they fail to separate out at the highest zoom levels). Personally, regarding map framing I think we should be flexible and judge on a case-by-case basis - if a map is closer to square we should prefer it to be a certain size, but it can be taller if it's also less wide, and vice versa. As to placement, in the articles I write I like to right-justify the map and place it as close as possible to the "Get in" or "Get around" sections. -- AndreCarrotflower (talk) 15:57, 14 June 2014 (UTC)[reply]

OK. So here's some random rambling :) We should have an upper limit for how big the map is allowed to be, but I’d certainly allow maps that are wider than high and maybe also vice versa. I totally agree that it’s a good idea to adjust the width and height so as to include the maximum number of POIs.

Usually I put the map in the center of the page, but often this creates quite large white spaces on both sides of it which isn’t too pleasant to look at. On the other hand, on screens with lower resolution this might not be a problem.

The all POIs visible vs. readability is really a hard problem of the type “you cannot eat the cake and have it at the same time”. Including POIs really far out would mean a low zoom number ie. in the worst case the map is useless for serious navigation as street names and smaller streets are not there. On the other hand if we zoom in too much we would both “loose” a lot of POIs plus the streets around them. Would several small maps centered on major POI concentrations maybe be something to try?

Frankly talking I’d rather have the reader print out the map with the POIs separately from the travel guide itself. Ideally, IMHO, when printing out the guide the guide itself would be printed and after that automatically the map (as it appears in fullscreen mode) of the destination at the size of one page. When getting around at the destination you often only need the map to see where you are right now.

I don’t think the yellow pluses are much of a problem if the alternative is a clutter of two or more overlapping markers, of which probably just the uppermost is readable anyway. About where to put the map: I think it is good where it is, after all the map is for getting around the destination.

Ps. In Karachi#Get_around you can see an example of an 1000px wide map. What do you think? It looks great on a MacBook Pro, but how does it look on screens with smaller resolution? ϒpsilon (talk) 18:32, 14 June 2014 (UTC)[reply]

I think I need to clarify what I mean by yellow pluses - I am not against the feature, I love it actually. I am trying to point out how useless a map covered with yellow pluses, or any other icons, clusters of unbundled POIs etc. is/would be. Take a look at how Stuttgart's map ended up looking when Andrew applied the uniform approach to it: [4] - at zoom level 11, we get an idea that Stuttgart is somewhere between motorways and that there are POIs at all its extremities, but the actual valley the city centre is in is all covered with said "yellow pluses" and you cannot even make out where the railway station is. You just have a general idea that POIs come denser in the centre - d'oh!

Try to zoom out the map for Berlin/Mitte just one level, and you will see the same - streets become barely visible and all you get is an idea that the Mitte has really many POIs. Any aid to spatial orientation is marginal. Trying to locate the Brandenburg Gate and then relating other POIs to it becomes a challenge in a 420x420 window.

I am not sold on the idea of printing out the map separately. First of all, does anybody have an idea on how to have it done automatically? The whole idea here is to have a guide that is easy to use and intuitive and does not require a myriad steps like "open the map in a different window and print with such-and-such settings". Moreover, just as some maps look ok in 420x420, others are tall and others wide, standard printer paper sizes are not always useful for maps - either a lot of useful stuff gets cut off, or we end up with irrelevant swathes of map with only a select area filled with POIs. I believe the work done to format the map in the article should be carried over to print as it is. WYSIWYG is always the best approach.

BTW, printing is just one aspect. The key aspect is usefulness of the online version. Let me repeat myself - sure thing, one can open the map in a separate window, zoom in and out, click pluses and whatnot, but the guide should be intuitive and wholesome and not requiring a lot of operations to be useful. The basic map, before resizing in a separate window, rezooming etc. should be as informative as possible. The examples I started with are not. As is Karachi - what is the point of such a large map, when I can't make out what's happening in the centre, where my sightseeing and getting around would probably be centred around. For the far-away POIs, I do need a general direction and idea how to get there and how long will it take, but I don't need the exact position. Those are the POIs I can look for by zooming out or opening the map in a separate window. A note in the POI listing directions that the POI is out of town / city centre would be enough for me to know how to treat it. PrinceGloria (talk) 19:23, 14 June 2014 (UTC)[reply]

PS. To make sure - what I thought is a given, but I guess I need to argue for, is that it is more important to show the core of the area covered and the spatial relationship between the POIs there, where the traveller may found themselves walking or using other modes of transportation intensively and in short distances. Showing POIs that are farther out, and possibly require special trips from the centre each, is of secondary importance to me - all I need to know for starters is that they aren't close to the others. PrinceGloria (talk) 19:23, 14 June 2014 (UTC)[reply]

Default size and shape, unless the shape of the area featured truly requires a different shape, in which case either the height or width, but not both, can be adjusted to accommodate it, with the width not to exceed 550px for any reason, right justified always. The rest of the adjustment can be done by setting the zoom. And if people don't know how to zoom or drag a map by now, it really isn't our problem. Insisting on a giant map that is fully legible without any manipulation not only puts too much emphasis on the map, it unnecessarily assumes our readers are totally and completely computer illiterate and thus negates many of the benefits afforded us by dynamic maps in the first place. I'm sorry if you think OpenStreetMaps is our most important feature, but it's really not important enough to take precedence over our lively writing, smooth flow, and predictable organization. Texugo (talk) 02:36, 15 June 2014 (UTC)[reply]

It's not a question of whether "our readers are totally and completely computer illiterate", it's a question of whether the guide is easy to use in all formats... not just a desktop PC with an HDTV screen, but all manner of small and awkward portable devices (from smartphones to Nook/Kobo) and even a printed copy. Trying to scroll these maps on a tiny portable device is awkward. K7L (talk) 03:14, 15 June 2014 (UTC)[reply]

Right. And the answer to that conundrum is not "let's dumb it down to the lowest common denominator". It's to recognize that our mobile site and print versions have different needs that need to be attended to separately. Texugo (talk) 03:17, 15 June 2014 (UTC)[reply]

And anyway, from my iPhone, for example, centering and enlarging the map as discussed above doesn't really doesn't make a terribly significant improvement in map usability by any stretch. It's still far too small to be very useful unless I zoom in on the whole page, which I could do equally well with the standard right-aligned map. Prioritizing mobile usability would have us sizing all maps and images at about 1000x1600px or more, which would of course be patently absurd on a non-mobile computer. Texugo (talk) 03:23, 15 June 2014 (UTC)[reply]

I don't want to post a whole bunch of replies so here's my thoughts on everything:

• I agree that we need flexibility on the dimensions and zoom level of dynamic maps so we can frame the destination in the best way possible on a case-by-case basis. We can't insist on giving the site a completely consistent look and feel when the destinations don't have a consistent look and feel. Cities of different shapes and sizes will always require maps of different shapes and sizes.
• When a map has to be significantly wider than it is tall – and thus, has to be center-aligned – I find that it looks a lot better if you put the map at the bottom of the Get Around section than at the top. That way you don't have a big gap between the section title and the first line of the section. Or for articles with long Get Around sections like Stuttgart, maybe we should put the map between the introductory Orientation section and the more detailed information below?
• There's been some talk about capping the width of maps at 800 or, god forbid, 550 pixels. The map at Wendover (Utah/Nevada)#Get around is currently 1000px wide and even when I view it on my phone's tiny screen, it isn't a prohibitive obstacle to navigating the article. It's a little inconvenient, but everything is inconvenient with a low-resolution screen. (And no, I'm not talking about the mobile version of the site; the map is both usable and capable of being scrolled past when viewing the desktop version of the site through my phone's 3-inch screen.)
• Clustering – personally, I liked it better when the icons simply overlapped. You could still see where the big clusters of attractions were and you could still zoom in on them by clicking a button with a plus sign on it. The only difference is that now you have to randomly zoom in on yellow clusters until you find the POI you're looking for instead of being able to see portions of each marker and make an informed guess.
  • Someone mentioned above the possibility of two POIs still being clustered together at the highest zoom level. Do we know of any examples of that happening? It certainly needs to be fixed if the software allows that situation to occur.
• The map at Karachi looks to me like it needs to be either shrunk or zoomed in one level. 90% of the POIs are on about a fifth of the map.

Thatotherperson^talkcontribs 03:47, 15 June 2014 (UTC)[reply]

If two POI's are being clustered together at the highest zoom, then it would suggest that the they have not been given distinct enough geo locations. Not exactly a map bug.

I agree that if the geography of a location demands it, then we should have some flexiblity in the map shape. However back to the example of Stuttgart I really see no reason why the default size and shape are not fit for purpose. (Both the center and outer areas of Stuttgart fit nicely into a square) Andrewssi2 (talk) 04:46, 15 June 2014 (UTC)[reply]

Two POIs could be in the same building or next to each other with very narrow storefronts, so the geo locations would be very similar. If the map only ever shows the plus sign in those situations, I think it’s a problem of the map.

Anyway, my thoughts are:

• Default size - A good idea, but there should be flexibility to suit the geography. I like a width somewhere between 400 and 500px, but that’s based on my experience drawing static maps.
• Width - I think wide, centered maps should be discouraged but not eliminated or capped. I don't mind an 800px wide-but-not-so-tall map if that's what suits the geography. Visually, I don't like 600x600 square maps (or larger) if they're centered in the middle of the page (I think it creates too much white space).
• Zoom level - All POIs shouldn’t need to be included in the frame. If it’s zoomed out to capture all the outliers with a large number of plus signs where most of the listings are located, I don’t think it’s as useful as a more zoomed in map that shows details about the parts of town where the majority of POIs are.

-Shaundd (talk) 06:15, 15 June 2014 (UTC)[reply]

1. Two POIs with the same latlongs are spiderfied at the lowest zoom level, not shown as a yellow plus. The feature works well for me in all cases I experienced. We are not discussing it here, if somebody has issues, I would discuss them in the general Dynamic Maps talk page and I am sure Joachim will take heed.
2. Stuttgart's map is actually square - but it needs to be 600x600 to fit all the POIs. A lower zoom level results in a sea of yellow pluses. We may discuss (in the article's talk page) if we can cut off individual POIs and shave a few pixels from the width or height.
3. 500px is by far not enough in terms of width. Many destinations only fit, with an appropriate zoom level, in much wider windows. Conversely, if we want to flow the text around the map, there is no need for it to be 500px or even 400px if we can cap it at smaller widths.
4. I would advise to cap height though, as most computer screens are 4:3 or 16:9, which means they are wider that taller. In my experience, anything over 600px is taller than "one screen" and the map starts looking oversize and unwieldy. I guess this will never change even with technological progress, as there is a minimal size of legible font etc., so I propose hard-coding the maximum height, but not the width into the regulations.
5. Or actually height as well - but at much wider than 500 or 400 px, somewhere close to 1000 px which is the maximum not to blow up the page in fullscreen viewing.
6. For mobile applications and for viewing on smaller screens I would propose a feature that would simply display a message: "the map is too large to display well: either increase your browser window size or open in a separate window and zoom in and out". I have no idea how to code this feature, but my gut feeling is that it is feasible. At least for mobile applications, where a page opens and views differently.
7. I am all for placing centrally-aligned wide maps someplace else, as the text does not flow around them - I'd put them RIGHT ABOVE the Get Around section. If a map fits into a right-alignable box (400 px wide max IMHO), let's put it BELOW the Get Around section header to allow the text to flow around it.
8. I believe a mangled, narrow box of text that is hard to read and makes reading both it and the map next to it harder for the eye is worse than whitespace. I would only allow right alignment if the map is really small / narrow.

PrinceGloria (talk) 06:41, 15 June 2014 (UTC)[reply]

So that is pretty fundamental.. you are basically saying that dynamic maps need to be extreemly wide ("500px is by far not enough in terms of width.").

Additionally you state that this will be a problem for mobile devices, and suggest that a feature be 'coded' by some unidentified third person that deals with this.

It is great that we are exploring new ways to exploit dynamic maps, however by breaking the Wikivoyage experience for people with small screens / devices it is just a step too far.

We need to stick to the default size until the Wikivoyage platform is able to handle maps for all devices in the manner you are proposing.

For now I would suggest customizing up to 500 pixels width for maps that really require the geographic flexibility. Addiitonally all maps need to be right alligned to be consistent throughout Wikivoyage. Andrewssi2 (talk) 12:37, 15 June 2014 (UTC)[reply]

And to be fair I just took a look at how the Stuttgart page renders on the Windows Phone platform (in desktop mode), and it looks pretty usable in fact. (see right)

Can anyone else test Stuttgart on their maobile device? (My Nokia Lumia is probably at the high end of mobile device resolutions) Andrewssi2 (talk) 12:58, 15 June 2014 (UTC)[reply]

That's the page I was talking about on the iPhone, and the reason I don't find it very usable (in either case) has more to do with the fact that the phones render the numbers/text at an almost illegible size. And upping the mapframe size or centering the map do nothing to remedy that problem, so I think any claim that we need big centered maps for the benefit of mobile users is just bunk. Texugo (talk) 15:52, 15 June 2014 (UTC)[reply]

We need big centered maps for desktop users! For mobile users, we should display them differently - preferably not show at all and tell users to open a dynamic map in a separate window. Which is how they are displayed now (as a link in the mobile version), which I am fine with. If anybody would want to change that, that is when we would need that "unidentified third person". PrinceGloria (talk) 16:09, 15 June 2014 (UTC)[reply]

We most certainly do not need big centered maps for desktop users. That Stuttgart map works perfectly well at default size and alignment, and without the immense white space and huge break in the article flow. This argument that we have to maximize the number of uncollapsed POIs on the screen at the cost of having huge white spaces and a big gap in the article flow is very misguided. The maps are dynamic and manipulable for a reason. Texugo (talk) 16:16, 15 June 2014 (UTC)[reply]

I have added maps to several articles and have found that the shape and size very much depends on the place being mapped. For a few this means a centred landscape map about 800 pixels wide (e.g. Kyoto/North or Southern Upland Way ) and for a few a right aligned map up to 800 pixels high (e.g. Kyoto/Higashiyama). If a place only has a couple of listings on the map, the default right aligned 420 x 420 map is often ok. I don't see any need to be standard about this aspect of a map.

If a map is centred, then it is best to avoid having images which might (at some screen resolutions) appear to the right of it. Any images in the lines immediately above the map should be moved. On narrow screens these images could be covered by the map.

At present the instructions are in two parts with Embed a dynamic map at the top and Adding a map – Mapframe further down. Perhaps these should be merged when the new details are added.

It is probably worth specifically saying to only have one mapframe per page, as I don't think that a second one works.

The instructions say to place the map right underneath the Get around heading. Should Get around be created if it does not currently exist (city districts), and is there a standard place to put a map in itineraries? AlasdairW (talk) 23:01, 15 June 2014 (UTC)[reply]

'Get in' is a fine section to put the map in if 'Get around' does not exist --Andrewssi2 (talk) 00:32, 16 June 2014 (UTC)[reply]

The statement "We need big centered maps for desktop users!" is something that has not been discussed until now, and I don't actually accept it. The market for desktop and even laptop machines is dying by the way, so we really need to think about people using Wikivoyage on tablet and mobile devices in the coming years. The guide to static maps states that "2,000-3,000 pixels is usually reasonable" when creating a map, although crucially these maps are always scaled to an image on the right hand side of the page.

I agree with Texugo in that the Stuttgart map (as well as most other maps) do work perfectly fine at the default size and allignment settings for desktop users. Having too many POI's is actually an opportunity to create more district articles. Andrewssi2 (talk) 00:32, 16 June 2014 (UTC)[reply]

While I know nothing about markets for electronics, I have not noticed a decline in people viewing the web from desktop- and laptop-sized screens. Sure, tablets and smartphones have enabled people to view the web from more places than before, but we do cater to mobile users by way of our mobile version, and tablet users (for tablets like iPad etc. rather than larger mobile phones) for the most part have screens comparable to small laptops. I see no problem with centered maps that are larger than 420x420 resulting therefrom.

Again, if you believe that a sea of yellow pluses at zoom 11 is a good representation of Stuttgart is a good map thereof, I am kinda startled. And I certainly don't think Stuttgart is at a point it needs districts - Berlin/Mitte probably has more POIs and I wouldn't split it either. PrinceGloria (talk) 03:16, 16 June 2014 (UTC)[reply]

Again, you are assuming the user is completely computer illiterate and treating it as a static image that has to show everything from the get-go, rather than a dynamic gadget that should blend in with the article rather than interrupt it, easily capable of showing the user whatever they want to see without dominating the article or screwing up our nice article format. Texugo (talk) 03:23, 16 June 2014 (UTC)[reply]

In reference to PrinceGloria's point about desktop usage, Wikimedia as a whole shows that in July 2012 81.4% of traffic was non-mobile. In July 2013 non-mobile visits were 76.4% of all traffic. Today it has dropped again to only 64% !

I think it is pretty clear that the trend of Wikimedia visitors (and I'm assuming Wikivoyage visitors have a similar pattern) are moving quickly away from desktops and laptops. Andrewssi2 (talk) 04:34, 16 June 2014 (UTC)[reply]

Do we have more visits in total thanks to extra mobile visits though, or less desktop visits though? At any rate, this does not change the point I made - large mobile devices have screens comparable to laptops and desktops. Small devices like regular-sized smartphones should utilize the mobile version - they can render the desktop version, but the size of everything would make it borderline useless. PrinceGloria (talk) 04:38, 16 June 2014 (UTC)[reply]

That info is also on the report. July 213 there were 17,077 million visits to HTML pages from non-mobile clients. Today there is a drop to 15,741 million.

To break it down even further, 'large mobile devices' (assuming you mean tablet) are 6.38% of all requests, whereas 28.2% of all requests are for the smaller devices such as smartphones which mostly would not have wide resolution screens comparable to desktops. Since this segment will grow even more, esspecially in emerging markets, I don't think that this can be dismissed. Andrewssi2 (talk) 04:52, 16 June 2014 (UTC)[reply]

It can not. This is why we have en.m.wikivoyage.org to cover those. PrinceGloria (talk) 05:02, 16 June 2014 (UTC)[reply]

But that doesn't change the need to keep a consistant map structure on the main page that all devices can use. Andrewssi2 (talk) 13:50, 22 June 2014 (UTC)[reply]

Conclusion?[edit]

The discussion has basically not really resolved anything or even made any substantial compromises other than 'I want full screen width maps'.

Is it acceptable to allow dynamic maps to be sized to an individual contributors personal viewing preferences?

I would continued to advocate no. We should allow freedom to extend the dynamic map width up to 500 pixels if required by local geographic considerations. In all cases the map must be right justified. Andrewssi2 (talk) 13:50, 22 June 2014 (UTC)[reply]

What do we do with the map aspect ratio of pure east-west itinerary (such as Trans-Canada Highway)? It's not very tall, but it's 8000km wide. K7L (talk) 14:09, 22 June 2014 (UTC)[reply]

And the Trans-Siberian Railway which BTW will be put on the Ftt pedestal in two months. ϒpsilon (talk) 14:15, 22 June 2014 (UTC)[reply]

A quick look shows that those maps are 600 pixels and 620 pixels respectively.

I'm fine for alternative suggestions for a pixels limit that works for most outlying scenarios (again, if a custom dimension is required by the geography covered).

A quick test User:Andrewssi2/Scratch suggests that a map of 500 pixels is acceptable on a 1024 pixel width screen and a map of 700 pixels is about acceptable of a 1280 pixel width screen (Only the first map renders, however we can see how the text fits to the left in each pixel version) --Andrewssi2 (talk) 14:37, 22 June 2014 (UTC)[reply]

I'll reiterate my support for default size unless absolutely necessary, right aligned in all cases. My suggested limit was 550px. Texugo (talk) 16:08, 22 June 2014 (UTC)[reply]

I absolutely disagree - the map size should be appropriate for the area depicted and editors should use their own judgement. Sometimes 400x400 is OK, sometimes 1000x600 would be justified. Right-alignment should depend on the width of the map - I could agree 500px is the maximum width at which right-alignment should be used. PrinceGloria (talk) 18:12, 22 June 2014 (UTC)[reply]

Indeed, as long as we have itinerary which runs pure north-south or pure east-west, no "one size fits all" policy will do anything useful. K7L (talk) 20:02, 22 June 2014 (UTC)[reply]

I agree with Texugo - maps where the default size doesn't work are the exception rather than the rule. If the area is oddly shaped, use a different size and note the reason in the edit summary, but aside from those uncommon cases let's request that people always use the default size and alignment so that every map addition doesn't become a subjective exercise dependent on the preferences of whoever happens to be editing the article. -- Ryan • (talk) • 20:56, 22 June 2014 (UTC)[reply]

I try never to exceed 800 pixels. 1000 pixels, when you add to it the left sidebar and other UI accouterments, could very well be too wide for some screens. Powers ^(talk) 21:25, 22 June 2014 (UTC)[reply]

800 pixel is a reasonable limit for the width. I think that a lot of articles benefit from a custom shape. It is important that the maps of city districts roughly match the shape of the district. Otherwise readers may not realise that they should be looking in another article for details of something that appears on the map. I know that mapmask is the real answer to this, but it is a lot of work to create one. AlasdairW (talk) 22:07, 22 June 2014 (UTC)[reply]

So can we agree that the default size should be used, except on an exception basis agreed on the article's discussion page?

For example, the Siberian train route between Berlin and Beijing would be an obvious exception. A map of a square city center should not be an exception ? Andrewssi2 (talk) 23:52, 22 June 2014 (UTC)[reply]

I don't want to codify that you have to start a talk page discussion before you can set the map size at anything other than 420×420px. Too many talk pages on this site have one or zero watchers.
Thatotherperson^talkcontribs 00:37, 23 June 2014 (UTC)[reply]

I still vehemently oppose any policy that says maps should always be right-aligned. Some maps need to be long and narrow. Others have brought up itineraries already, and we can't ignore the fact that we're on the cusp of dynamic maps becoming usable at all levels of the geographical hierarchy. They are already usable for lowest-level regions, and will be usable for mid/high-level regions and countries once we can draw color-coded shadings. What are the maps at Aleutian Islands and Tennessee going to look like if we insist on using square-ish map frames? Do we want our map of Tennessee to show most of Kentucky and half of three other states for the sake of being square? We absolutely need the flexibility to use long, narrow maps in some situations, and when the long direction is east-west, we need to allow center-alignment.

I do agree that we don't want 800×800px maps dominating the screen – considering there's a link for a separate full-screen version – but a center-aligned 800×400px map that doesn't take up much vertical space is a different issue altogether. What if we set a width limit of 550 or so pixels for right-aligned maps only and then recommend that if a map needs to be significantly wider than it is tall, like that map of the Trans-Canada Highway, it should be turned into a stripe map: center-aligned, widened to about 800 pixels, shortened height-wise if possible, and placed either at the bottom of the 'Get in/around' section or after the opening paragraph of it (to limit the awkwardness of the whitespace on the sides). That way we can set the shape of the map however we need it, up to a little more than twice as wide as tall, while limiting awkward displays on as many screen resolutions as possible. (I changed my screen resolution setting to 1024 pixels and an 800 pixel-wide map doesn't require side-scrolling.)
Thatotherperson^talkcontribs 00:37, 23 June 2014 (UTC)[reply]

We have established that exceptions are required. We have moved beyond 'one size fits all' earlier so there isn't a reason to concern that point. Noone is asking that every single map needs to be square.

I don't mind how the process of an exception is done. If noone comments on the talk page of an article then you have sufficient basis for your exception.

For non-exceptions, I personally just want a standard size to be used and right justified. Any suggestion for the very maximum size of a standard square map would be appreciated. Andrewssi2 (talk) 01:35, 23 June 2014 (UTC)[reply]

Some maps can't even resemble a square though, hence the need to allow center-alignment. My point about the talk pages wasn't that it might be impossible to gain consensus, but rather that you shouldn't have to post a talk page message no one is going to read before making a tweak. As a perfect example, I just went to add a map to Central Utah and found that I needed an extra 50 pixels height to show the whole region at zoom level 8, where 13 out of 15 POIs are shown and only two are stuck in a cluster. You could use the default size at zoom level 7, but there would be massive gray areas and only 4 out of 15 POIs would be visible outside the clusters. This type of common sense tweak shouldn't be written into policy as something that requires talk page approval when so many of the discussions would be decided by just the one person anyway. Also, I'm not sure what you mean by "For non-exceptions, I personally just want a standard size to be used and right justified." That's why we have a default size and alignment coded into the mapframe template. I thought we were having this discussion specifically to decide what exceptions people are allowed to make.
Thatotherperson^talkcontribs 02:17, 23 June 2014 (UTC)[reply]

My previous comment stated "Noone is asking that every single map needs to be square". Sorry, I can't make it any clearer.

The origin of this discussion is for maps such as Berlin/Mitte which do fit into a square, and for which an exception is not obvious apart from the purely personal preference of the contributor. Andrewssi2 (talk) 04:52, 23 June 2014 (UTC)[reply]

Go one zoom level lower on Berlin/Mitte and tell me the map is of any use then. Can we be serious here? PrinceGloria (talk) 04:54, 23 June 2014 (UTC)[reply]

Yes, I think we can be serious. In order to shoot down the hyperbole around the 'sea of yellow plusses' I hereby provide the screenshot to the right.

You might personally prefer a massive map breaking the flow the article, however the screenshot actually does look better and proves clearly that dynamic maps do work fine and actually look better in their standard size for normal city articles. Andrewssi2 (talk) 05:34, 23 June 2014 (UTC)[reply]

How so? I see about as many yellow +'es as actual POI's. K7L (talk) 11:28, 23 June 2014 (UTC)[reply]

I guess then we have an impasse. The point of yellow plusses was to make the map more navigable given a high number of POI's. Do we accept that the reaction every time to avoid these yellow plusses is to place a massive map in the middle of the article and basically break the flow?

Maybe I'm the only one seeing this as a problem, in which case consensus would have to direct me to give up and accept that massive dynamic maps are now a rationale reaction whenever a few yellow pluses bother a contributor. I think the quality of our site is poorer for this. Andrewssi2 (talk) 11:42, 23 June 2014 (UTC)[reply]

(edit conflict - responding to K7L above) Yellow pluses would only be a problem if the map were not dynamic. But the map is perfectly usable at the default size, and if you were going to start checking out the details of street names and/or relative positions, you're almost certainly, in either case, going to end up zooming in further and scrolling around anyway, so there is really no advantage to basing the map size on how closely POIs are clustered and sacrificing article flow in the process. Logically, compared with our static maps, very very few of which we have felt to need to present at a huge size in the center of the screen, having these nice, easily-manipulable dynamic maps should allow for us to have fewer giant blown-up space-hogging centered maps, not more. Texugo (talk) 11:48, 23 June 2014 (UTC)[reply]

Well, Andrewssi2, you're obviously not the only one. Texugo (talk) 11:49, 23 June 2014 (UTC)[reply]

Thanks Texugo Andrewssi2 (talk) 12:59, 23 June 2014 (UTC)[reply]

Texugo and Andrew, you see "disturbed flow of text" as a problem, and you two are the main contributors in this discussion. I would say the rest of us doesn't, and we rather see the "sea of yellow pluses" as a problem. I think we are in an impasse, and as such, I would say we will not reach a one-size-fits-all prescribed solution. Let us focus on agreeing what we can agree upon, e.g. the max width of map where right alignment should be used as opposed to centering, and maximum width and height of the MapFrame. PrinceGloria (talk) 13:03, 23 June 2014 (UTC)[reply]

Ryan and AndreCarrotflower have also agreed with us, so I don't think it fair to posit your position as some majority that includes "the rest of us". At any rate, any problem from the so-called "sea of yellow pluses" can be resolved with a mere 1/4-cm movement of the index finger, and as mentioned, once they start looking at the map, most people will already be zooming in and out and scrolling around anyway, no matter what the original map configuration. On the other hand, the chasm across the middle of the article, the interruption in the text flow, and the generation of wasted white space cannot be resolved by the user at all, so any situation where Berlin/Mitte is all it takes to justify interrupting the article with a giant square flanked by white space is completely unacceptable to me. Texugo (talk) 13:18, 23 June 2014 (UTC)[reply]

Also, I'd like to point out that by saying "let us focus on agreeing what we can agree upon", all you're really doing is telling us we should concede the points we don't agree on, with the expectation that lack of consensus means you can do things your way. That seems a bit disingenuous to me. Texugo (talk) 14:48, 23 June 2014 (UTC)[reply]

Actually, a lack of consensus means that the infamous status-quo bias applies. You seem to be fine with that when it suits your purposes (such as with the ongoing deadlock regarding links to Wikipedia) but now it's somehow an issue? K7L (talk) 15:18, 23 June 2014 (UTC)[reply]

On the contrary, status quo would suggest that, sitewide, images of any kind have only very rarely been centered, and those rare cases have always involved panoramas with aspects of about 5:1 or higher, and that no image even approaching the vertical dimensions of one of these maps has been centered in any article. An approach such as PrinceGloria's, which sets a low bar for centering big tall images, allowing them to proliferate across the site, is undoubtedly the novel proposal in this case. Texugo (talk) 15:30, 23 June 2014 (UTC)[reply]

(edit conflict) I think the last time we had any agreement on this subject the decision was to use the default size unless there was a clear reason not to do so - see Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment ("4. Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate."), and the discussion behind that decision - Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site?.

That said, what is the counter-proposal being made in this discussion? To always have map sizing be subjective? With the exception of the argument above about using a larger size to eliminate yellow pluses, the only argument I saw for non-default sizing was in cases where the geography didn't suit a square map, and that should already be allowed given the "unless there is a specific reason for using a different size" caveat in the existing guidance. I think the status quo is actually what the majority of people in this discussion are arguing for, or am I misunderstanding what has been written? And if I am, can someone please summarize? -- Ryan • (talk) • 15:31, 23 June 2014 (UTC)[reply]

My interest here is that I have been formatting maps in the articles I edited quite carefully to make sure: 1) that as many POIs as possible are visible 2) that the default view is actually useful without the user having to zoom in or pan out, or scroll to get a good overview of the area. The dynamic features are just great for further digging into the map, increasing level of detail, or panning out to see how far the POIs described are from larger-scale stuff not in the map as presented, but the map should also be illustrative as it is opened, not just a random window with stuff - otherwise, we might have just as well placed a link to OSM without any MapFrame, or simply told people to go to Google Maps and stop being such wimps.

I do not want the carefully formatted maps to be right-justified and resized to 420x420 just because "this is the standard". I see no benefit in this particular standard for the traveller, it just satisfies the anancastic tendencies in some of us (and I admit we all have them, I guess I exhibited them at other occasions). This is why I oppose standardization of size and shape here - I believe we gain nothing from that (except for avoiding horror vacui). PrinceGloria (talk) 16:21, 23 June 2014 (UTC)[reply]

There are no anachronistic tendencies involved here, so there's no need to bring up that accusation. It is simply that any advantage of your approach — i.e. ensuring that the dynamic functions of dynamic maps are ostensibly unneeded for a cursory overview of the relative arrangement of some unlabeled numbers, even though any further investigation will undoubtedly require using those dynamic features anyway — is marginal in comparison with the drawbacks in layout consistency, flow continuity, and economy of space. The only advantage of your approach is that it saves the user a fraction of a scroll of the mouse in a situation where they will probably be scrolling the mouse anyway, and that is not worth throwing our consistency and good layout sense out the window for. Texugo (talk) 17:19, 23 June 2014 (UTC)[reply]

Let me address these:

1. Layout consistency - given the number of different devices and browser a reader may use to browse our content, and the possible settings etc., there is no achievable layout consistency. I don't think having maps 420x420 will change much - for some viewers, a 420x420 map will fill the entire screen, for others it will be 1/3 of page width.

2. Flow continuity - I believe placing the maps between sections does not hamper flow continuity even if they are centered.

2.1 We are also not writing a novel - my assumption is that most readers will not be reading our entire guides as a continuous work of literary art, but rather using it as a reference, accessing the sections they need and reading whatever they find interesting. Unless we break a continuous paragraph of text with a map with blanks on the sides (which I believe we shouldn't, see above), I see no harm done.

3. Economy of space - this is an online guide, space comes for free. And when it comes to printing our guides, guides where it makes sense to make the maps go over 420x420, like Berlin/Mitte, would print on over a dozen pages anyway. Devoting one page to a map does not seem a problem to me - if anything, I hate print guides which have too small maps. I'd rather do away with unnecessary verbosity in a guide, but one is useless to me without a proper map.

PrinceGloria (talk) 18:03, 23 June 2014 (UTC)[reply]

PS. Anancastic, or anankastic, not anachronistic. Just to make sure - used in a jocular way, not implying anything personal.

You are conflating inconsistency of source with inconsistency between devices, but currently pages viewed on a single device are relatively consistent with one another. Your proposal would be adding a second layer of inconsistency. You can also say that stopping the article, putting a big tall image flanked by white space, and the restarting the article underneath it does not interrupt the flow, but you would be wrong. It is plain poor layout, whether it's a novel, a newspaper, a website, or a travel guide, and increases the amount of scrolling needed to refer back and forth to the actual listings and diminishes any chance of have the map and text relevant to it on the screen at the same time. "Devoting one page to a map does not seem a problem to me" - me neither - it is best viewed as an entire page, just a mere click away, and for anything else a mere roll of the mouse scroll is very much more than simple enough. I don't know why you feel the urgent need to try to approximate the full giant map within the article too. Texugo (talk) 18:26, 23 June 2014 (UTC)[reply]

I am not seeing our articles as consistently laid out - we have a general structure of having a banner at the top and some headings that are typical for a given type of guide, but each guide is different. I have no problems with that, and certainly not with different map sizes. I actually do format my guides with my experience in mind - as I have yet to be able to access somebody else's. And my experience is that a large map in an article helps me, and I like to pause reading the guide and just look at the map without any scrolling to get an idea of the place, rather than resize, rezoom or open in a new window. For individual POIs and such, I just click the icon and jump out to another window/tab to see its precise location. But it is a bit meaningless before I get a good spatial orientation of the area that the "MapFramed" map affords me. The way the map is shaped and framed also gives me an idea of the place's spatial orientation and its limits. This is my experience. Yours, I understand, is different. PrinceGloria (talk) 18:45, 23 June 2014 (UTC)[reply]

PS. To me, a guide that squeezes a map somewhere on the side of the page and tries to make it half the size required has poor layout. With modern DTP techniques, you can have your map as large as you need, in any shape that your page size allows. I like (print) guides, who have no reservations about breaking text with large maps. I don't like (print) guides, who stuff little illegible maps at sides of pages, which are usually useless and I have to consult a different map anyway (not very useful if you're trying to find your way in a city). Finally, I hate guides whose editors think it is great to have text "flow" around a map or article making it fit a narrow column I find hard to read. Again, my personal experience.

Once again, your justifications rely on ignoring all dynamic aspects of the dynamic maps and pretending they are useless unless you make them huge, which is not at all true. While we're repeating ourselves, I'll go ahead and sum it up once again: the entirety of your approach amounts to encouraging drastic, unnecessary, inconsistent layout changes at whim in order to save an insignificant 1/4-cm mouse motion that will in all likelihood be executed regardless. Texugo (talk) 18:56, 23 June 2014 (UTC)[reply]

It seems like there is a fundemental difference of opinion with how the site should be used. PrinceGloria is a passionate advocate for evolving the site and this engagement is to be encouraged.

At the same time, we should recognize that as individual's we do not 'own' individual articles and that we need community buy-in before establishing new practice where there is no article specific reason for an exception. Andrewssi2 (talk) 00:19, 24 June 2014 (UTC)[reply]

You and Texugo are the ones proposing new restrictions, it's up to you to find consensus for these changes. As for "an insignificant 1/4-cm mouse motion", how does one do that on a paper copy? An .ePub? A .pdf? Current policy is that the print version matters and I don't see consensus to change that. K7L (talk) 00:22, 24 June 2014 (UTC)[reply]

Please take a look at any static map, for example Manhattan/Chelsea. You will note that these are smaller and right alligned. If the print version matters then when are they not enlarged and centered in the same way that is now being attempted with Dynamic Maps? Andrewssi2 (talk) 00:32, 24 June 2014 (UTC)[reply]

Yes, I believe it has already been established that maps, whether dynamic or static, big or small, are always better printed out separately. And K7L, you've actually got it exactly backwards. As Ryan pointed out above, the status quo written guidance on the subject says

Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page

and as I pointed out, the status quo practice which has been in place for years has basically been to never center anything but the occasional high-aspect-ratio panorama image. So actually Andrewssi2 and I are simply defending the status quo, and the new idea that requires consensus here is this suggestion that we start sizing and centering maps at the whim of the editor at the time. Texugo (talk) 02:45, 24 June 2014 (UTC)[reply]

I was under the impression that the maps in articles were supposed to be sufficiently high-resolution to be usable if simply printed as part of a page. Please pardon me if you addressed this above, but do you disagree with that? Ikan Kekek (talk) 03:05, 24 June 2014 (UTC)[reply]

I'm not sure that is written down anywhere, and actually I think the idea was slightly different: that such maps should be usable (online) without having to click on them to expand. Either way, it is fairly reasonable guidance for static maps like File:West End map.png. Static maps have, well, static text which cannot be read if the image size is too small - i.e., in the case of static maps, image size affects the resolution. This is not an issue for dynamic maps, which a) only show the POI names when you click on each one, b) automatically size the other text to be legible at the viewed size, and c) do not have their resolution affected by resizing anyway. Texugo (talk) 03:16, 24 June 2014 (UTC)[reply]

Here is Greenwich Village as exactly represented in the Manhattan/Greenwich_Village article. Is this sufficiently high-resolution to be usable if simply printed as part of a page? I would suggest not, and this appears to be the typical presentation format so far.

I think the point is whether the map is sufficiently high resultion enough when opened at full size in another window and then printed. Andrewssi2 (talk) 03:27, 24 June 2014 (UTC)[reply]

it's kind of a moot point anyway, since dynamic maps are not fully usable enough to see which street/block thePOIs are on until you zoom in to about 17, which is not remotely practical as a default zoom level anyway. Texugo (talk) 03:36, 24 June 2014 (UTC)[reply]

(ec)My impression is the same as Ikan's -- maps are supposed to be sufficiently high-resolution to be usable if simply printed as part of a page -- it's certainly been in my mind every time I've drawn a map the last few years. Perhaps it was an ideal to aim for, if rarely achieved. Unfortunately, I don't recall where those discussions took place, it may have been part of the regions map discussions as opposed to city maps.

420px is actually pretty small for a city map. Manhattan/Chelsea, referenced above, is 440px. Most of the maps drawn for Chicago, Washington, D.C., Baltimore, Bangkok and Bali that have an east-west orientation are at least 500px. Many are 600px. They're not all readable on-screen, but it's been standard practice for many years, at least among some map makers, to have static maps in the 500-600px range. Centering maps is very rare though, the only exceptions I found are Baltimore/Inner Harbor and Washington, D.C./National Mall. -Shaundd (talk) 03:38, 24 June 2014 (UTC)[reply]

Take Berlin/Mitte for example. Blowing it up so you can afford to zoom in another notch does eliminate some of the pluses, but there are still some pluses and even for the individual POIs that you can see, you cannot really tell what street, what block, or sometimes even what side of the street they are on, so gains in usability are really minimal. And it would be impossible to frame that map so that it shows everything at a truly usable size, so this usability angle is really kind of pointless. Texugo (talk) 03:45, 24 June 2014 (UTC)[reply]

I am of a very different opinion regarding usability. With the current zoom level in Berlin Mitte, you can make out the street grid, the most important places, the river and such. Sure you can't make out detail such as the side of street the place is on, but this would be impossible unless we zoomed to 17 or 18 - this is now what the map is for. The map is for getting a general idea about the layout of the district or city. For detailed navigation, if required (most POIs can be made out from the other side of the street, so if you are on the "wrong" side, you just cross it), one should use a GPS device or a large print map one can get in a bookstore or from tourist information. That is why we still provide addresses and add directions to POIs. If anything, the only gripe I have with the Berlin/Mitte map is that the name of Unter den Linden won't show, but that's the peculiarity of the map layer we use.

Regarding static maps - their readibility is very much dependent on resolution, but their aesthetic effect on the layout is dependent on screen resolution. In my screen that I am using now, the map of Greenwich Village is too small to conveniently make out the text - I'd rather it was zoomed some 30-40% for the descriptions to be legible. But then if I did so and later changed for a smaller resolution screen, I'd find the map unnecessairly blown up to a huge size, and totally squashing the layout of the article (a 600px wide map provides for a narrow paragraph of text if right-aligned and displayed in a screen that allows only 800px for the article body). Dynamic maps have some of such issues too - this is why I would recommend to center them when they are over 400 or 450, because we NEVER know what device and browser window size the reader will use, and it's better if they are abhorred by some white space then if they can't read a paragraph of text - but they seem to work better with different resolutions than static maps.

Finally, I like to add pictures to both Get in and Get around, especially the latter - those are very useful pics, as they are usually public transportation schematic maps and such. If they clash with the right-aligned map when the screen is resized or if they get pushed towards a different section, it truly does nothing for "article layout". PrinceGloria (talk) 05:27, 24 June 2014 (UTC)[reply]

The thing is, your subjective concept of usability, or anyone else's, is still fully available at default size and alignment with just a minimum of mouse movement. Everything else is just you saying "I prefer big wide maps", which is not an argument.(No, the print version has nothing to do with it, because if you're printing, you need to print out a larger map anyway.) And yes, I am aware that different screens display differently - that has nothing to do with it, as it is a logical fallacy to say "attribute A varies based on X, therefore we should multiply further variations of Y in as well". That just compounds the unpredictability at the user's end even further. To your third point, centering images has never been an acceptable way to deal with an overabundance in any section, and at any rate, if the city is complex enough to require a transport map, surely it should have at least a couple of paragraphs of accompanying text in the Get around section, which should be plenty to keep it from being pushed far into the next section. Texugo (talk) 11:51, 24 June 2014 (UTC)[reply]

Policy conflict?[edit]

We seem to have two slightly different instructions on how to use dynamic maps, depending on the page you read:

1. . Wikivoyage:Dynamic maps Expedition says (as Ryan pointed out above), "Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate."
2. . Wikivoyage:How to use dynamic maps says, "nnn is the width and height in pixels that the embedded map will display at on the page. 470px wide is a good width to ensure that it does not overflow the righthand gutter on small, standard width screen resolutions of 800px. Optional - default is 420px for both height and width."

How to use dynamic maps seems to imply that users are free to use a width other than the default 420px, although it goes nowhere near 600px square maps or centering maps. I'm not trying to stir the pot further here (despite what it looks!), but this would muddy (to me) what the status quo is with respect to map size. At the very least, lets apply whatever final policy wording is determined below to both pages so our policies are consistent. -Shaundd (talk) 03:57, 24 June 2014 (UTC)[reply]

The advice on Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment was added after a lengthy discussion, while the second item in the above list appears to have been added unilaterally without discussion [5] and should thus be changed to match the "Dynamic maps Expedition" advice. -- Ryan • (talk) • 04:47, 24 June 2014 (UTC)[reply]

Ok, I've updated Wikivoyage:How to use dynamic maps to remove the reference to 470px being a good width. I also changed the text regarding default zoom so it says it is 14, which seems to be the current default. -Shaundd (talk) 05:39, 24 June 2014 (UTC)[reply]

Thanks Shaundd, although we should be careful before changing wording yet as there appears to be great vibrancy to this discussion. Andrewssi2 (talk) 05:47, 24 June 2014 (UTC)[reply]

I agree, and I don't usually change things that quickly. In this case though, one item was developed by consensus and the other was added later without discussion -- well meaning, I'm sure, to help explain how to use the dynamic maps -- but it was at odds with the existing policy. So for clarity, I think it's best to align them based on the current standard and then change both pages as needed when this discussion is finished. -Shaundd (talk) 06:05, 24 June 2014 (UTC)[reply]

I do agree what you did, Shaundd, was the only right thing to do - I wonder how these offhand notes came about. I don't agree with having to "update both" though - we are mixing an Expedition, which is a collective workspace for interested Wikivoyagers, with a guideline/policy page. The problem is that many people are unaware that this is the policy page (and we only need to make changes to it). We might use some kind of a signpost to all existing policies (or perhaps there is one that I am not aware of - it needs to be promoted better then), and announce major policy discussions and changes in the Pub (rather than use it to discuss policies and whatnot as we often carelessly did in the past). PrinceGloria (talk) 06:10, 24 June 2014 (UTC)[reply]

It's unfortunate that one or two users seem to want to turn this into a policy page and amend it in such a way as to impose new restrictions on Wikivoyage editors. Most of what we have about dynamic maps is documentation, and even that is a moving target as the ability to display these maps is a capability still very much under development. My concern is that someone will slip an arbitrary restriction into these today ("Dynamic maps may not be used at the region level") based on the current software limits on ability to draw different-coloured regions on a dynamic map, pass it off as a "clarification" instead of new policy so that it slips under the radar, then use it a week, a month, a year or however long from now once a subsequent version of the dynamic map software gets the ability to display multiple coloured regions. Wikivoyage policy is a very inflexible beast (as evidenced by the ongoing deadlock on links to other Wikimedia projects, where we're still hamstrung by policies imported from WT) and it's much easier to create these new, pointless restrictions than to get rid of them once this instruction creep is doing more harm than good. At least Wikipedia marks its project pages with huge templates to indicate what is policy, what is a guideline, what is merely an essay, one person's opinion or a sarcastic joke, and what is Help: documentation. Here, any page can be twisted and used as a policy stick to beat future editors, which is unfortunate and likely unintended. K7L (talk) 14:54, 24 June 2014 (UTC)[reply]

Once again, there is nothing at all here that involves imposing new restrictions — users on WV have never been free to oversize and center images at whim. The rest of your rant is just rather off-topic generalized complaining that doesn't really belong in this discussion. I've mentioned to you elsewhere, your opinion may be "I don't like rules therefore I oppose this rule", but that does not offer any constructive argument that others can engage with. Texugo (talk) 15:07, 24 June 2014 (UTC)[reply]

Au contraire, you have tried to take a documentation page, titled "Project: How to use...", turn it into a policy page and amend it to impose additional restrictions for which there is no clear consensus. The onus is on you to justify this proposal to the rest of us. K7L (talk) 15:13, 24 June 2014 (UTC)[reply]

(edit conflict) I partially disagree with Texugo - guidelines on images are just guidelines and should be ignored if there is a good reason for doing so (and if that reason is stated) - but I think it's still think it's very important to state what our best practices are and apply them in the majority of cases. There have been a few comments that this discussion is an effort to "impose new restrictions" or that we would revert edits of non-default sized maps as being "against the law". Hopefully others are not arguing for such rigidity, but are instead just trying to agree on (and put into writing) some best practices for dynamic maps so that we don't have to have a massive discussion (like this one) when someone simply thinks a bigger or smaller map "looks nice". If there is a reason for using a non-default size then state it and do so, but if it's simply a matter of someone preferring bigger maps or center-aligned maps in all cases, let's come to an agreement on what the common case should be and put it into writing. That process of documenting best practices is very common and even vital on any wiki that has a large community. If I'm misunderstanding the concerns being raised about this particular discussion please clarify, but K7L's concerns about general inflexibility of the community notwithstanding, I don't think that agreeing on some standards is a bad thing. -- Ryan • (talk) • 15:23, 24 June 2014 (UTC)[reply]

The restrictions were already there for various elements such as images and static maps. We are taking the 'how to use' page to make a more flexible policy with regards to dynamic maps. It is overdue.

Rather than making charged statements such as 'the onus!' (this is collaboration after all), perhaps you can can contribute as to what you would like to see in terms of policy? Andrewssi2 (talk) 15:26, 24 June 2014 (UTC)[reply]

I'm not sure that we really disagree much, Ryan. I am certainly not arguing for "no exceptions ever". I am only concerned with having the guidance give us a clear bias in favor of an uninterrupted layout in cases that boil down to no more than someone's simple preference for big honking maps, because in the absence of extenuating factors of shape, etc., no amount of discussion in the world can negotiate a compromise between "centered and huge 'cause I like it that way" and "right-aligned and undominating, as an element of consistency and flow". With static maps so far, we have apparently found the exceptional need to center in exactly 2 cases out of our 26,000 articles — why would new dynamic maps which actually increase viewing possibilities at smaller sizes suddenly result in a situation where we make such exceptions for every third city?

As to K7L's insistence that he gets his way if no consensus is established, I have to reiterate that he is flat wrong. If we have never allowed images to be oversized and centered at whim, then it is no more than a bald attempt to win on a technicality, and quite a stretch at that, for him to claim the right to oversize and center these maps whenever he sees fit simply because policy does not explicitly spell out that the same approach we've taken with other maps, images, and content elements applies to dynamic maps as well. Texugo (talk) 15:43, 24 June 2014 (UTC)[reply]

Policy wording change[edit]

Reading through the discussion, I think these adapted guidelines are agreeable to most people? If you would like to make changes, please copy and paste below, making your edits to the origional text clear.

Suggested adaption for dynamic map guidelines: (Bold are added words by me, strikethrough are removed words by me)

• 1. Only add dynamic maps to articles at the lowest level of the article hierarchy (city or district).
  2. Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page.
  3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
  4. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city or district, in which case the reasoning should be explained in an edit comment or on the article's talk page.
  5. Zoom should be modified as appropriate and show the majority of POI's in the article.
  6. Itineraries may have flexibility to use appropriate dimensions as required to display the subject area. Center allignment is also allowed for large maps in this category.
  7. Do not add more than one dynamic map without discussion on the article talk page.

Andrewssi2 (talk) 00:19, 24 June 2014 (UTC)[reply]

BTW, please leave point 3 "Do not add a dynamic map when a Wikivoyage-style static map is already present." alone. This is not the place to discuss that point. Andrewssi2 (talk) 00:23, 24 June 2014 (UTC)[reply]

I support these suggested clarifications. Texugo (talk) 02:48, 24 June 2014 (UTC)[reply]

I really don't know how #3 came about, I believe our previous discussions actually pointed towards something totally opposite, and I don't know why we shouldn't discuss it. I also don't understand why we should have such a verbose and restrictive policy - are we writing the tax code or guidelines for people enjoying themselves while contributing to the greatest travel guide that evolves with their contributions? Finally, I don't understand why itineraries should be treated any differently than other articles with regards to what is "allowed". PrinceGloria (talk) 05:14, 24 June 2014 (UTC)[reply]

Point 3 is part of existing policy and nothing to do with map dimensions so it won't be discussed. Your distaste for not being able to apply whatever feels best for your own personal preference has been noted already; however feel free to contribute constructively. Do you wish to extend the standard size perhaps? Andrewssi2 (talk) 05:44, 24 June 2014 (UTC)[reply]

I also don't understand why itineraries are being called out or odd-shaped city maps can't be centered. What about:

2. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city, district or itinerary, in which case the reasoning should be explained in an edit comment or on the article's talk page.

4. Center alignments are allowed for maps that have a width of 700px or more. (note - I just pulled that 700px out of a hat as a suggestion. I do think a hard number will help minimize future discussions rather than saying a "large" map).

-Shaundd (talk) 05:56, 24 June 2014 (UTC)[reply]

I am quite surprised to see point 3 here as I remember as discussing removing this kind of rule, but I guess I have to find this discussion. This is the problem with overpolicing everything - we now have so many guidelines and policies that one needs a WikiLawyer to keep track of what has been formally decided and what didn't, and discussions may result in a reasonable consensus which however does not get recorded in all appropriate places and then somebody cries "but it's a against the law!" and we're back to the drawing board.

I do not want a standard size. I want users interested in a given article to be able to determine the best size, layout and placement of the dynamic map in the talk page of a given article, not a prescribed solution that simply won't work. Sure this will lead to me being the only one determining that if I am the only editor of an article, and this is the case with many of us and many articles for now, given the number of contributors. But then this may spark the interest of somebody else appalled by the "white chasms" in the article, then we discuss, then the other user gets to know the destination and gets involved in the article and the article benefits as a whole. Applying blanket policies like "let's disallow XYZ" or "let's format this like that" results in a string of mechanical (manually performed still) edits to a number of articles without any deeper involvement of the user in this article. Had we continued discussing this in the talk page wherever this originated (I have forgotten where it was), I am sure the article would have benefitted greatly. Now we have a featured-guide-size amount of hot air in a policy/guideline talk page many users are even unaware of. I am not sure we are improving Wikivoyage in any way here. PrinceGloria (talk) 06:00, 24 June 2014 (UTC)[reply]

PS. Shaun - I mostly agree with you (though still don't agree with being so specific and restrictive in general), but I would go with 500 px as the limit for right alignment given my experience of viewing Wikivoyage on smaller-res screens. Otherwise, viewing Wikivoyage on 800x600 with text flowing left to the map will be a disaster with maps 500, 550, 600 and such wide.

I recall the discussion around Point 3. I believe the static map people did not want to lose the primacy of their format and therefore this was the compromise that apparently still stands. Andrewssi2 (talk) 06:17, 24 June 2014 (UTC)[reply]

Shaundd , the point is that a city or district never have a reason to be so large as to need to be centered. Itenaries can span continents hence the call out. Andrewssi2 (talk) 06:15, 24 June 2014 (UTC)[reply]

You will need to tell that to cities and districts then, Andrew. I am not sure if they would be open to your policy proposal that tells them to contract and fit into 420x420. Frankly, I believe we are fighting a losing game here - we seem to need to adjust to them, not tell them to adjust to us. PrinceGloria (talk) 06:21, 24 June 2014 (UTC)[reply]

Zoom function. That is all. Andrewssi2 (talk) 07:17, 24 June 2014 (UTC)[reply]

Zoom function does not work in print. It also will not show the entire district that doesn't fit in 420x420 - it will only show you a fragment. Finally, the most important feature of the dynamic map is not that you can zoom it (you can do it with a static map as well), but that POIs will appear on the map dynamically, as they are added / edited by a user requiring just some short instruction. This is why they were developed and why I prefer them over static maps, not because you can move and zoom - you can move and zoom Google Maps as well, but they don't include references to our guides. A map in the article should be informative and clear, and not fit 420x420 just because. If we tell people to zoom and scroll, we may just as well only include a link, not a clumsy problematic MapFrame. PrinceGloria (talk) 07:40, 24 June 2014 (UTC)[reply]

Really sorry to break this to you, but dynamic maps were never designed for printing (Hence the magic interactive elements such as panning, zooming and clicking). As previously noted you can't even cheat all the yellow pluses by ever increasing the map size. It will always be a bad solution. In the meantime you have broken the flow for everyone else for this misguided idea. Andrewssi2 (talk) 08:02, 24 June 2014 (UTC)[reply]

If dynamic maps are not designed for printing, doesn't using them conflict with this site's commitment to printability? Ikan Kekek (talk) 13:51, 24 June 2014 (UTC)[reply]

Just because they are not as useful when printed as-is within the article (even at the larger sizes proposed) as they are when printed separately at a larger size does not mean anything much in that regard. The same is true of the static maps anyway. We may want to have a good, usable print version, but our commitment is not necessarily to always have an unadjusted direct print-out of the on-line version. Texugo (talk) 14:19, 24 June 2014 (UTC)[reply]

Yes, it's often a problem with static maps, too, and I have a problem with that. I've greatly enlarged a lot of static maps for exactly that reason. Ikan Kekek (talk) 14:25, 24 June 2014 (UTC)[reply]

It is true, Dynamic Maps have never actually fitted the goal of having a usable print version. Dynamic Maps are interactive elements and as such will never be ideal for printing because interactive elements (to state the obvious) do not print on paper.

I am a strong supporter of dynamic maps, and mostly for the fact that it lowers the barrier to contributing to WV (i.e. you don't need cartography skills). We do need to accept however that blowing a map up across a large desktop screen is unfortunately just 'lipstick on a pig', and at the cost of the article's readability. Andrewssi2 (talk) 14:57, 24 June 2014 (UTC)[reply]

Any other comments on my proposed policy change at the beginning of this section would be appreciated. Andrewssi2 (talk) 14:57, 24 June 2014 (UTC)[reply]

Earlier I suggested that when printed, the map as a full screen should print as a separate appendix at the end of the guide, at the size of a full page. If you take a random article, click at Printable version in the sidebar and compare them, they are already slightly different (absence of banner, no sidebar, little larger font, URLs spelled out etc.). Would it really be that hard to add a map as based on the dynamic map as specified in the Geo parameter as an additional page? That would solve the problems for users who wish to have their maps printed.

The Mapframe maps are chiefly there to get an overview of the destination, right? And as many have already said, you can zoom and move around. If the map that is embedded in the guide would be intended for general navigation it would both have to cover the whole area of the city stretching maybe 5km in each direction with an appropriate zoom level to distinguish the four sights, main department store, four restaurants, five bars and two hotels that are located around the same three blocks in the very heart of the city - as is very often the case. To really achieve that, the map would have to be absolutely monstrous, so why even try? I don't think it's so hard for readers to understand how to zoom and scroll, online maps have been around for a while.

For the most part I support the revised version of the policy. But, I would suggest that limits to the maps are given as maximum width and maximum height instead of standard size, so that they could be horizontally or vertically narrower if needed. ϒpsilon (talk) 15:33, 24 June 2014 (UTC)[reply]

Regardless of whether the map is printed where it is placed in the text or as a separate appendix, it needs to be formatted properly. Otherwise, we will be printing autoformatted rubbish. 420x420 does not cover all cases. Some maps will be OK at 500x300 at zoom 14. Others at 300x600 at zoom 13. And yet others will only make sense at 800x500 at zoom 15. There is no blanket

I also believe that the fact that the print version looks different from the online version is the fallacy, not feature, of PediaPress. The best solution for easily editable content is always WYSIWYG. I will certainly be addressing this with the PediaPress regarding out banners and such, but only once I establish whether this isn't our own work, i.e. using "noprint" where we shouldn't.

I must also state my "preference for big honking maps" for the very reason. I believe we should provide a good overview of the place, not a link to the map. My print guides, at least the good ones I bought, have had good, carefully edited maps that showed just the area I needed to understand. They did not simply contain the instruction to buy another map. And if they had a separate fold-out map, I considered them impractical - I want my map right there in the guide and formatted the way it allows me to use the guide to get an idea of the place.

To make it clear - the above is regardless of print issues. I want a well-formatted map in a Wikivoyage guide I read that gives me a good overview of the place. Later on, I will zoom in and out, scroll and whatnot. But first, I need a good picture of the place. This is easier in even more than 1/3 of the cases as invoked above with using large, centered maps than 420x420 right-aligned ones.

Having said which, if the policy would only state maximum width and height, rather than prescribe a size (which is prescribed in MapFrame's standard settings anyway), I am a happy camper. I believe this is best decided case-by-case in talk pages. In some articles, right-alignment of a small map will work. In others, it won't. That's what we've got the talk pages for - to discuss. The discussions are sometimes heated, but my experience is that we more often come to constructive conclusions in talk pages, where all what we discuss is creating the best guide for a destination we care for, than in policy pages and such, where we discuss theoretically.

Kind regards, PrinceGloria (talk) 17:38, 24 June 2014 (UTC)[reply]

The "good overview of the place" is right there. The answer, as you've been told many times before, is very very simple: zoom. Others might equally consider a good overview to be a wider zoom level that more clearly shows the main thoroughfares, stripping away the extraneous sidestreets. Luckily zoom works great for them too. And it's is extraordinarily simple. This is not "later on I will zoom in and out" when I get enough energy. This is not even extricating a folded map glued into the back cover of your print guide. It's not hard. You're again just saying that your laziness to roll the mouse scroll over a notch to reach your preferred view outweighs every concern about the layout, flow, and usability of the rest of the article. Texugo (talk) 18:00, 24 June 2014 (UTC)[reply]

(edit conflict) If I may say, the most comfortable solution would actually be something similar to Wikipedia's WikiMiniAtlas that would pop up when you click on the POI icon in a listing. As of now, when I read about something in a listing, I prefer to have the fullscreen map in another tab that I can access with a click rather than having to scroll back and forth to the small embedded map in the Get around section - which in practice is as separate from the See, Do etc. sections as any other separate map. ϒpsilon (talk) 18:12, 24 June 2014 (UTC)[reply]

(edit conflict) It would be brilliant if you could not value my experience and preferences as inferior to yours, and also accuse me of laziness. This discussion is getting quite inappropriately personal.

We have discussed that zoomed out maps gets hard to make out when there is a lot of POIs in them (regardless of whether they are clustered or not - a mass of POIs simply covers the area. Sure we can zoom, but then we can't keep the entire area in the MapFrame window. I believe for most districts and cities it is possible to choose an area the map should cover by default and make a dynamic map out of it - just like people make static maps of cities. And I prefer this approach to a small window you have to zoom in in in order to see anything.

Back on topic of aesthetic preferences - which are naturally subjective. I see absolutely nothing wrong with a centered map, and I dislike paragraphs of text squashed by 420px wide or large maps. I find them hard to read and, if anything, this is what disturbs the flow of text and makes it hard to read for me, as this does not concern separate sections, but actually continually flowing paragraphs of text. Some of them have listings and such, and given that our guides are viewed on different screens, it is sometimes hard to predict which bits of text will be affected. I find this actually aesthetically undesirable and making our guides inferior to read. 200px standard sized (or are they 225px?) thumbnails pose such problems much more rarely, as it is rare that the screen is narrower than 600px - and if it is, it is usually a mobile device displaying a different version of the page. PrinceGloria (talk) 18:20, 24 June 2014 (UTC)[reply]

PS. I quite like Ypsilon's idea, but I still believe we need an in-article map in a very prominent position. And this is still an idea, not sure if we can implement that quickly. We have to sort out the MapFrame and Dynamic Maps as they are.

Call it laziness, call it unwillingness, nothing personal was meant in pointing out that you seem to think avoiding that tiny finger movement to reach your preferred view is more important than any concern over layout or flow. And I'm not at all prioritizing my preferences over yours. I'm saying that your stated usability preferences can easily be accommodated by very simply using zoom and/or the full-screen map, without stomping a canyon across the middle of the article. The opposite case, that of doing things your way yet still being able to in any way accommodate a preference for upholding our traditional values of formatting, flow, and consistency, does not hold true by a long shot. Texugo (talk) 18:38, 24 June 2014 (UTC)[reply]

You seem to have not understood the gist of what I am saying - I want a dynamic map that works like a static map, i.e. there is a picture that is properly formatted for the area in question and depicts it well. This is not because I fear for anybody's fingers that may get tired, it is because zooming in and out and scrolling in a 420x420 finger is not the same as being presented with a picture of the city or district. You can eventually make out the city by exploring the dynamic map by zooming it in and out and scrolling, but this is not the same as being given a clear overview. Again, please accept this as a personal preference which I feel about very strongly - you may not require this, but I find it paramount for a guide to be useful.

And before you cry foul that this is not a dynamic map - to me, the "dynamic" in the dynamic map is about the long term, i.e. that the map evolves with the guide, new POIs are automatically displayed once coordinates are given, the ones modified or removed are also rendered accordingly, and the map tiles are maintained centrally regardless of the state of the article. The fact that the map can be moved, zoomed etc. is only a nice, and obvious, side benefit to the maps being dynamic. The clou of the dynamic maps is the fact that they are automatically updated and easy to modify without specialist knowledge and with minimal effort, which is great for a collaborative project like ours. So this is why I prefer dynamic maps over static maps, even if I call for them to be used to display a ready-to-use static picture in our guides. PrinceGloria (talk) 21:13, 24 June 2014 (UTC)[reply]

Alternate proposal[edit]

I'm not satisfied with the wording changes proposed above. First, why are we scrubbing the option to explain yourself in an edit summary instead of on the talk page? This wasn't even under discussion. Second, itinerary maps are not the only place we need to allow center alignment. I'll refer back to the example I linked above at Wendover; the town is arranged almost entirely on a single eastbound/westbound street. The POI field is more than 2½ times as wide as it is tall, and thus, if it were squeezed into a right-aligned map at a lower zoom level, would leave big empty patches in the upper and lower thirds of the map.

Here is my specific proposal for a wording change:

• Only add dynamic maps to articles at the lowest level lower levels of the article hierarchy: cities, districts, and regions that are not further divided into additional regions. Dynamic maps are not currently usable on articles with sub-regions due to technical limitations.
• Do not add a dynamic map when a Wikivoyage-style static map is already present.
• If the default size does not frame the destination well, try to limit any height or width increases to the minimum amount necessary. Do not set the width above 550px (to preserve the readability of the text to the left of the map on smaller screen resolutions).
  • If a destination is significantly longer east-to-west than it is north-to-south, consider using a center-aligned horizontal map with a width of about 700-800 pixels instead. These maps should have the height reduced as much as possible to limit the break in the article text.
• Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate and show the majority of POI's in the article.
• Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page. For maps that must be center-aligned, it may make more sense to place them at the bottom of the "Get around" section or, if the section is very long, after the first paragraph.
• Do not add more than one dynamic map without discussion on the article talk page.

That first change should be a no-brainer at this point. Check any sub-region of Nevada to see how well dynamic maps now work for lowest-level region articles. The last guideline about not using two dynamic maps on the same article can be deleted because it isn't even possible to add a second map.
Thatotherperson^talkcontribs 01:48, 25 June 2014 (UTC)[reply]

There are some good points here, although the problem is that it appears to still allow for center aligned maps with no clear criteria. I guess the wording could be worked on?

I sort of see your point in Nevada about 'lower' levels rather than lowest, but it won't be obvious from that wording. I'll give it a go.

I didn't think scrubbing the 'edit comment' would be controversial. An edit comment can't be discussed, and if someone wants to change the map later they will have no obvious reference that this was done or even why.

I just tried Wendover at a preview at 550 pixels (your suggestion) and it is perfectly usable. We just need to be clear that a rectangle shaped area is not a carte blanche for dimension sizes Andrewssi2 (talk) 02:53, 25 June 2014 (UTC)[reply]

I had another go integrating some point (but not everything). I removed required for noting changes in eigher edit comment or talk page.

• 1. Only add dynamic maps to articles at the lowest level of the article hierarchy: cities, districts, and regions that are not further divided into additional regions. Dynamic maps are permitted at a regional level in order to illustrate towns and settlements.
  2. Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page.
  3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
  4. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city, district or region. If dimension changes are needed then try to limit any height or width increases to the minimum amount necessary. Do not set the width or height above 550px unless an exception is required by the area's exceptionally wide or high geography.
  5. Zoom should be modified as appropriate and show the majority of POI's in the article.
  6. Itineraries, Travel Topic and Region articles may have flexibility to use appropriate dimensions as required to display the subject area. Center allignment is also allowed for large maps in these categories.
  7. Do not add more than one dynamic map without discussion on the article talk page.

I like the direction we're going here. However, I still don't like the idea of using article type – itinerary, travel topic, region – as a criteria for whether or not a map can be elongated and center-aligned. Maybe we could establish a minimum width-to-height ratio (2:1?) or maximum overall height (400px? 380px?) for horizontal maps to ensure that center-alignment only gets used for appropriately-shaped places. (I'm not sure what you're seeing at Wendover, but if I set the width at 550 and keep the zoom level at 14 it cuts off portions of the central tourist area, and if I set the width at 550 with a zoom level of 13 it leaves about 70-80% of the map as empty gray space.) Also, I notice you deleted the stuff about center-aligned maps being placed somewhere other than the top of the "Get around" section. Any particular reason? I think it looks a lot more awkward if the break in the article text is between a section header and the opening line of that section.
Thatotherperson^talkcontribs 05:38, 25 June 2014 (UTC)[reply]

In terms of article type (and please anyone correct me if I am wrong here) I had the understanding that there was generally more freedom when working on specialized travel topics. For example, Paris and its districts are main destination articles and should generally adhere to a Wikivoyage form (not a ridged structure, but a general form that can be customized but still be familiar to readers), whereas a travel topic such as Eating and drinking in Paris is more experimental in nature, and the contributor has more flexibility to execute their creative vision.

I removed the reference to centered maps in the other sections only in the sense that Ryan's proposed functionality below would make it moot. (i.e. both types of map could co-exist in the 'Ged Around' section) Andrewssi2 (talk) 01:01, 26 June 2014 (UTC)[reply]

Re #2, if we're going to include dynamic region maps in the policy, we should note they are typically placed in the Cities section (assuming they're being placed there because that's where the corresponding icons are). How does this sound:

2. Dynamic maps of cities, districts or parks should usually be added to the top of the "Get around" section. Dynamic maps of regions should usually be added to the top of the "Cities" section.

-Shaundd (talk) 05:11, 26 June 2014 (UTC)[reply]

Good point about specifically mentioning the different placement for regional maps. Andrew, I don't see how the Javascript feature being added makes it any less important to put center-aligned maps lower in the "Get around" section. Expandable maps won't get rid of the break in the article text – in fact, they will make it larger, increasing the benefit we would see from moving center-aligned maps away from the section header.
Thatotherperson^talkcontribs 06:42, 27 June 2014 (UTC)[reply]

Potential compromise[edit]

If I'm understanding correctly, we all agree that there are times when the geography of a location makes the default size problematic, and in such cases the default sizes can be changed to fit the geography. The main point of disagreement is about preferences for larger maps that do not need any manipulation but break up the article flow, vs. smaller maps that do not break the article flow but may need some user manipulation. What about the following possible compromise (subject to verification as to whether it is technically feasible):

1. We adopt the #Policy wording change as proposed by Andrewssi2 for the default case.
2. We add Javascript that provides an option on maps to dynamically expand the map to full article width for those who want it. Similar to the current TOC collapsing logic, once you have expanded a map a cookie will be set on your browser to remember your preference, and future articles will load with the map expanded. Conversely, if you then collapse a map the cookie will be updated so that you then see maps displaying at the default size in the future. Since this functionality is implemented using a cookie, it won't matter whether you are logged-in or not, the preference will be remembered.

Would that address most concerns? Maps can then be large and immediately readable for those who want it, and can be out of the way but available for manipulation for those who would prefer such a solution. If there is interest in this idea I can try to put together some code that would allow the capability. Caveat: I am relatively confident that this functionality can be implemented, but sometimes resizing iframes is problematic so there is a chance it won't work. -- Ryan • (talk) • 21:35, 24 June 2014 (UTC)[reply]

That sounds quite cool and helpful if it's possible (I like larger maps but not the white space centered maps create). A couple of questions off the top of my head are (1) would it expand proportionately or just width-wise (i.e., height remains the same), and (2) would the expanded map use the same zoom setting as the small map? -Shaundd (talk) 21:49, 24 June 2014 (UTC)[reply]

I'm not sure if the zoom level can be modified via Javascript, but will look into it. As to width/height, I was assuming the aspect ratio of the map should stay the same, which would mean expand width AND height proportionally. -- Ryan • (talk) • 22:09, 24 June 2014 (UTC)[reply]

So it sounds like a default square map would likely end up being vertically larger than the screen on a wide-screen device, less so on an old square-ish monitor and not a problem in portrait mode on a mobile/tablet. I wonder if it would be better to expand it width-wise only, or apply a 16:9 ratio (if that's even possible). -Shaundd (talk) 22:29, 24 June 2014 (UTC)[reply]

I get nervous whenever we have the potential for registered users to see the article differently from non-registered users (or from certain other registered users). It makes it hard to ensure the page is aesthetically pleasing. Powers ^(talk) 00:03, 25 June 2014 (UTC)[reply]

It sounds like a good compomise that recognizes that different people want different things from the desktop view.

As an additional bonus, could this be the default setting for the printable mode, even for non-registered users? Andrewssi2 (talk) 00:10, 25 June 2014 (UTC)[reply]

Powers - I wasn't clear enough above. This change would be cookie-based and thus would be no different for an anonymous or registered user, just like the current "collapsed/expanded" preference for the table of contents. -- Ryan • (talk) • 01:29, 25 June 2014 (UTC)[reply]

Our ToCs are in our pagebanners now, so I'm not sure what you mean. Anyway, you were perfectly clear. The problem is that with the option to expand the map we have no way of knowing whether any particular user has done so or not. Powers ^(talk) 12:04, 25 June 2014 (UTC)[reply]

See Culver City#Get around for an example of the expand/collapse functionality - click on the link in the map caption. Apologies for enabling this on a mainspace article, but POIs didn't work when I tried using a userspace page. Per the suggestion above the height is limited to a 16:9 aspect ratio. I haven't yet added the functionality to persist the expanded/collapsed preference but will get to that if there is interest in implementing this functionality. -- Ryan • (talk) • 05:55, 25 June 2014 (UTC)[reply]

When expanded, it's very hard to use the mouse wheel to scroll the article (versus the map). Powers ^(talk) 12:04, 25 June 2014 (UTC)[reply]

It's a bit more difficult to scroll because the map covers much of the screen, but it's not hard. The same principle applies on other websites with these kind of windows, Yahoo's World Cup live game commentary is a current example, so hopefully positioning the mouse on different parts of the screen to scroll the various elements won't be new to most users. I think it's an acceptable trade-off if it helps address the concerns discussed above.

Overall, I really like it. It worked smoothly on my desktop and laptop (Firefox and Chrome). My cell phone (Android) was touch and go. The first couple of times I tried it, it expanded the frame but not the map. But when I repeated it, it worked fine in both Opera and Chrome. I was working off a weak wifi signal so that may also explain why the map was slow to expand. -Shaundd (talk) 21:32, 25 June 2014 (UTC)[reply]

Update - I've tested it on IE 11 and Safari now, and it worked fine. The only thing I've found is that sometimes the map doesn't always fill the expanded frame. I can't pin it down exactly but it seems to relate to how fast the page loads and how quickly I expand the map. If I wait a few seconds (which is probably the more normal usage), the map works fine. -Shaundd (talk) 04:33, 26 June 2014 (UTC)[reply]

I'd say it is very difficult to scroll, since you basically need to place your cursor in the grey Wikivoyage left hand menu bar to avoid the 'pointer catch and zoom' effect.

If the people in the 'large map' camp are fine with that tradeoff then this is a good functional proposal. Andrewssi2 (talk) 01:06, 26 June 2014 (UTC)[reply]

Well, if there's one thing that can be said for this discussion, it seems clear that one person's "difficult" can be another person's "very acceptable". I can't speak for others (hopefully they'll chime in), but I'm quite happy with the tradeoff for a larger map. Thanks for the offer below for added functionality if required. -Shaundd (talk) 04:33, 26 June 2014 (UTC)[reply]

There seems to be lukewarm (at best) support for the dynamically expanding/contracting map proposal so far. Is this option still something worth pursuing? It seems to me like it might be a nice enhancement for those who prefer larger maps by default, and for those who don't there isn't any impact beyond a link in the map caption, but I don't want to spend too much time finishing it if it isn't something people would want to see put into use. -- Ryan • (talk) • 16:13, 28 June 2014 (UTC)[reply]

RL caught up with me and I was unable to participate in this heated discussion as much as before, but I just wanted to indicate that I do support this proposal and find it worth pursuing if you have the capacity to do so. If I may, I would suggest adding zoom, latlong and width/height parametres for both the collapsed and expanded versions to make sure what is displayed is useful and meaningful, and not just a random slice of the map. I also support the notion voiced above that the print version should contain the expanded map by default. PrinceGloria (talk) 17:50, 28 June 2014 (UTC)[reply]

I have similarly been unable to participate in the conversation as before, because I was unexpectedly hospitalized on suspicions of a very serious blood problem. For four days, I was facing a strong likelihood that I would be diagnosed with a life-threatening illness, and was told that that even on the offchance that I was not, I was almost certainly going to have to cancel my 2-week Europe trip and remain in the hospital for some time. Most thankfully, this morning, a completely benign diagnosis was reached, and I was quickly cleared to go have some beer while watching the Brazil game, cleared to travel tomorrow, and sent on my way. Sooo, before I finish my quite interrupted travel preparations and disappear from WV for another couple of weeks, I would just like to take this opportunity to thank Ryan for this suggested compromise and to finally agree 100% with all the points PrinceGloria expressed just above. This sounds like a great idea. I may pop in from time to time during my trip to see how this discussion is going, if I have the time. Texugo (talk) 19:03, 28 June 2014 (UTC)[reply]

I take it your are 100% fine Texugo ? If I understood that correctly then great to hear!

I support the change proposed by Ryan Andrewssi2 (talk) 01:43, 29 June 2014 (UTC)[reply]

Nothing a little over-the-counter medicine and a little time won't fix. Thanks! Texugo (talk) 02:31, 29 June 2014 (UTC)[reply]

The Javascript feature is nice, but you may want to run another test first, this time on a map that has all three links in the caption instead of just one as Culver City had. The only examples I know of right now are Virgin Gorda and Singapore/Chinatown. Once we have a plan for what the map caption will look like with all four links, I'm fine with rolling out expandable maps site-wide.
Thatotherperson^talkcontribs 02:24, 29 June 2014 (UTC)[reply]

Thanks for the responses, it sounds like there is enough interest to continue this work so I'll try to get the preference for collapsed/expanded set in a cookie ASAP. If there are any other maps that have edge cases like what Thatotherperson mentioned let me know so I can make sure the code works with them. As to modifying the zoom level or other parameters when expanding, I'll have to investigate whether or not that is possible - I haven't looked closely at how it is implemented currently. -- Ryan • (talk) • 03:34, 29 June 2014 (UTC)[reply]

Can we talk a little about the expanded size? On my screen when expanded to full width it was more than a screen tall, really dominating my entire browser window. Is there any way to mitigate that? (It also might help with the scrolling issue.) Powers ^(talk) 17:33, 29 June 2014 (UTC)[reply]

Currently the code is set up to expand the map to 100% of the available width. It had been suggested above to allow a maximum width:height ratio of 16:9, so in some cases the height will be reduced to fit within that ratio (so if the original map is 400x400, the expanded map might be 800x450). Would it make sense to also set an absolute maximum width of around 1000px? Is there another number that would work better, or another solution that might be preferred? -- Ryan • (talk) • 19:20, 29 June 2014 (UTC)[reply]

Unfortunately, this is the same problem that plagues the Main Page on wide screens with maximized browser windows. We "fixed" that by putting an upper bound on the banner widths, and I suppose a similar idea might work here, but it's far, far from ideal and is really a bit of a hack. Powers ^(talk) 01:21, 7 July 2014 (UTC)[reply]

I've done the following:

1. The expand/collapse feature is now active on three pages: Culver City#Get around, Virgin Gorda#Charter airlines and Singapore/Chinatown#Museums and galleries.
2. I've added code so that the expand/collapse preference is now saved in a cookie. If you expand a map on one page, the preference to show expanded maps by default is remembered and you will see maps expanded by default on future page loads. If you then collapse a map, you will see maps collapsed by default on future page loads.
3. I've tweaked the CSS for the expand/collapse link to float right when there are multiple links in the caption, such as with Virgin Gorda#Charter airlines. If anyone would rather see different behavior let me know - floating to the right just seemed like an easy option to implement.

I'm not quite sure what to do about Powers' concern with large screen resolutions. The idea of an absolute maximum map width didn't sit well, so would it be better to have three size options instead of just the current "expand/collapse"? Something like "Map size: 100% | 66% | default" (where 100% & 66% are both centered) to handle different browser resolutions? Any other suggestions? -- Ryan • (talk) • 17:13, 13 July 2014 (UTC)[reply]

Looks good! I'm personally happy with a 100% option.

Just a question.. If I click to the expanded map in Singapore, the 'sea of yellow plus icons' doesn't change. Is there something to be said for an additional zoom level change when expanding? Andrewssi2 (talk) 02:35, 14 July 2014 (UTC)[reply]

I'm not sure how to trigger an additional zoom level when expanding the map, particularly since the map is in its own iframe and thus subject to Javascript cross-domain limitations. If someone knows how to trigger a zoom from the parent page let me know and I can test out an implementation, but at least for the moment it's not something I can put in place. -- Ryan • (talk) • 03:37, 14 July 2014 (UTC)[reply]

It seems like the full-width map really duplicates the "full-screen map" link in usefulness. Unless your browser window is taller than it is wide, I'm just not seeing the usefulness of the expansion when we have the full-screen option. Powers ^(talk) 12:10, 14 July 2014 (UTC)[reply]

Since there didn't seem to be support for enabling dynamic map sizing I've removed the Javascript in question from MediaWiki:Common.js. -- Ryan • (talk) • 11:52, 28 August 2014 (UTC)[reply]

The article for nuclear tourism used to have a global view of all the nuclear tourist destination sites. Now it appears stuck at zoom level 2 with only a small part of the world visible.

I guess this happened because of some changes to the map rendering, however is there anyway to fix it so that it can show the whole world again? --Andrewssi2 (talk) 00:05, 23 June 2014 (UTC)[reply]

Thanks for takine a look Joachim! Andrewssi2 (talk) 00:25, 24 June 2014 (UTC)[reply]

In the next version the zoom levels 0 and 1 are published. Then the whole globe can be displayed in a map window. -- Joachim Mey2008 (talk) 04:17, 24 June 2014 (UTC)[reply]

Hi All, I have been writing an itinerary Colombia to Patagonia overland and I plan to put all the places of interest put on the map. The current way I am doing it is to find a city's GPS coordinates and put that into listing format as lat and long. This getting really tedious. So I was wondering is there anyway the mapframe could grab the location information from the pages linked to by the wiki link? —The preceding comment was added by ‎Tigerleapgorge (talk • contribs)

If you mean you're are taking them from Google, Wikipedia or elsewhere and typing them in here, then there's a somewhat easier solution - or this is at least how I do it. Open the article and then the map of the area in a separate tab. Zoom and scroll until you see the place you want to add. Click on the map to open a speech bubble with the coordinates. Double click on the lat= long= row, copy the text and paste it into the coordinate parameters of the listing or marker. Then go back to the map, move on to the next city etc. ϒpsilon (talk) 18:57, 24 June 2014 (UTC)[reply]

Thank you for this tip! It will help things go faster. Still I think if we can have a auto include for links to pages with location info will improve navigation at least of itineraries. I guess I will look at wikifoundation for projects of this type. Tigerleapgorge (talk) 02:15, 25 June 2014 (UTC)[reply]

I'm just asking a question before blowing the dust off my javascript editor.. there may not be much support for this.

A few people have mentioned it is annoying when the dynamic map catches the mouse pointer as part of a scroll and starts zooming.

If the script was changed to require a user click on the map before interaction could begin, would that be regarded as too great a functional impediment? Andrewssi2 (talk) 01:12, 26 June 2014 (UTC)[reply]

I'm fine with the existing script. However, if requiring a user to click on the map before interaction allows this proposal to gain wider acceptance then let's do that. Hopefully more people will try it out and comment in the next day or so.

BTW, does a "click" include panning the map or would the user have to click the map before panning or scrolling? -Shaundd (talk) 03:36, 26 June 2014 (UTC)[reply]

Just to be clear, this idea is not directly related to the above proposals. Even when scrolling against a small map we experience this.

I'm thinking a 'click' would be needed before any action on the map could take place. One problem is that people are already used to the map responding instantly, so this may not be acceptable.

Any other strategies would be interesting to hear as well. Andrewssi2 (talk) 04:09, 26 June 2014 (UTC)[reply]

I too find the random scrolling over a map extremely annoying. Perhaps we can add a lock button on the side? We can either set it to locked by default or up to the article. Tigerleapgorge (talk) 21:41, 27 June 2014 (UTC)[reply]

That might be a good idea! How about if it also had a cookie preference?

It could default to 'unlocked' as the existing experience, however users could click the lock if they wanted and this would be remembered by the browser. Andrewssi2 (talk) 00:34, 28 June 2014 (UTC)[reply]

It seems like this question has become redundant because someone changed the map so that 'zoom whilst mouse scrolling' is disabled. I personally prefer it like this, however I'm also a bit concerned that functional changes are happening without any obvious discussion. Andrewssi2 (talk) 05:12, 2 July 2014 (UTC)[reply]

It appears to enable after a right-click. Perhaps it should enable after *any* click on the map? K7L (talk) 08:03, 2 July 2014 (UTC)[reply]

You are right. One right mouse enables the scroll zoom functionality again. I'd suggest that will not be obvious to new users. Andrewssi2 (talk) 09:03, 2 July 2014 (UTC)[reply]

Yes, it was me. As always, a little hasty (↗). The left-click was already used with "You clicked the map at". - It lacks a help page specifically for visitors. Here only the functions of dynamic maps should be explained. At present, the WV logo (bottom right) is linked to the help page for editors. -- Joachim Mey2008 (talk) 04:51, 3 July 2014 (UTC)[reply]

I'd hesitate to assume the right mouse button to be available; the user might be on a toy device like a tablet or a Mac where there's just a touchscreen or a single button, respectively. As much as a home user should have a desktop PC, these were intended for use while travelling. K7L (talk) 12:42, 3 July 2014 (UTC)[reply]

I just tried the dynamic map out on my Windows Phone 8 device and the zooming work fine. I'm not sure if this was by design, but the problem seems to have been (before the fix) that mouse pointers were 'caught' by the map. On a mobile device there is no pointer to catch. Andrewssi2 (talk) 13:07, 3 July 2014 (UTC)[reply]

A user of a single button mouse should know that you can trigger a right click by [Ctrl] + mouse button. Mobile touch screen devices have no scroll wheel. There usually the method pinch to zoom is used. -- Joachim Mey2008 (talk) 05:04, 4 July 2014 (UTC)[reply]

Also worth mentioning that Macs have had a 'right mouse click' for some time now. Andrewssi2 (talk) 12:31, 4 July 2014 (UTC)[reply]

I think I might rather see the functions reversed; left-click to activate focus (e.g., scrolling ability) and right-click for the special function of seeing the coordinates. Powers ^(talk) 17:26, 4 July 2014 (UTC)[reply]

Good idea. Already tested. If no one has objections, I will modify the script as LtPowers proposed. -- Joachim Mey2008 (talk) 18:16, 4 July 2014 (UTC)[reply]

Runs (details here). -- Joachim Mey2008 (talk) 12:16, 7 July 2014 (UTC)[reply]

I'm seeing problems with GPX traces if multiple Firefox tabs are opened at the same time to different itineraries which have GPX.

For instance, quickly middle-click in Firefox on each of Rideau Canal, Trans-Canada Highway, Yellowhead Highway, Windsor-Quebec corridor. Odds are, one or more will load with either no GPX trace at all or (most often) with the GPX trace for an itinerary from some other tab. For instance, opening them all in the order I've listed gives four blue lines from Windsor to Québec City, even though Windsor is only on one of the four itineraries (hint: it's not the Yellowhead).

The POI's are correct; the GPX is wrong. Bug? K7L (talk) 08:03, 2 July 2014 (UTC)[reply]

Using Safari on a Mac, in three of those I see the correct GPX traces. But in Windsor-Quebec corridor I don't see any GPX traces (right or wrong ones) at all, just the markers from the article. In a fifth tab I've opened Route 1-Ring Road which I know has GPX traces in the Mapframe. The map does first not show up at all, when fiddling with the map type something shows up but the zoom does nothing. Seems like something is broken once again.ϒpsilon (talk) 08:34, 2 July 2014 (UTC)[reply]

I get an empty grey box with the zoom and layer buttons for Route 1-Ring Road. Click anywhere in the box and then (but only then) the map is displayed. K7L (talk) 14:37, 2 July 2014 (UTC)[reply]

1. The GPX function is faulty for some time. I'm trying to repair.
2. Mapframe zoom=auto needs no center point coordinates. It automatically centers (Route 1-Ring Road).

Joachim Mey2008 (talk) 17:37, 2 July 2014 (UTC)[reply]

User:Texugo spent a very productive few hours yesterday resetting the maps although we haven't really moved on with this discussion since July 14. And the discussion ended up in gridlock, with one side arguing for standardization, and the other against.

I believe that the arguments pretty much boil down to aesthetics - one side likes the map to appear standardized, the others like them big. I find this a subjective issue and we probably won't agree on anything here. One thing out of the picture seems to be the usefulness to the traveller - although we may assume the traveller will be able to recenter, resize, rezoom and print out a version of the dynamic map for a given article to their liking, there is value in having pre-sized, pre-centered and pre-zoomed the map. This is

I actually am a user of those pre-formatted maps. Even with the current issues with map-printing, I simply use a print-screen option to get the map as put into the article to accompany a version of the guide with POI numbers. I have done so during my recent trip to Stockholm and found this majorly helpful. I feel that by reverting the work that went into pre-formatting maps, a benefit and useful feature for a traveller was removed. I feel my interests as first and foremost a traveller and Wikivoyage user were compromised in favour of some ill-advised uniformity. I don't think this is the proper order of precedence of values of Wikivoyage.

Therefore, I would kindly ask User:Texugo to revert the blanket changes. We can then discuss case-by-case, and perhaps some of the guides can indeed do just as well with standard-sized maps. But if some users have done something that actually benefits the travellers, I would really hate to see having that removed. If anything, if somebody comes up with something helpful, we may look at revising our policies and guidelines to accomodate and promote that, rather than become entrenched with what we have. Especially at this stage, where the exposure towards actual travellers is still limited and so is the feedback we get. PrinceGloria (talk) 13:48, 8 August 2014 (UTC)[reply]

I will not revert them, no. To discuss case-by-case is fine if you wish, but it will have to start from the position of you explaining in each case why the default is not sufficient, because I can assure you that the default works fine in the very vast majority of cases. And don't start throwing Ttcf around as if that weren't important to me. Having maps at a printable size has never been among our goals, and making it so should really require some consensus. Truth be told, you haven't said anything in this post that you didn't already claim above. The bottom line is that the way you'd like things to be does not jive with our very long-standing tradition of centering only necessarily panoramic images, and until/unless we decide by consensus to overthrow that paradigm and let that be at the whim of whoever is editing at the time, you need to quit insisting. Texugo (talk) 14:01, 8 August 2014 (UTC)[reply]

If ttcf is important to you, then why does centering or non-centering of images come first ahead of the traveller? PrinceGloria (talk) 14:07, 8 August 2014 (UTC)[reply]

The status quo is that we do not create categories as hit lists of articles into which to edit-war changes in map size. The articles should be put back to their original state unless and until there is consensus for mass changes on this scale, which there is not. K7L (talk) 14:17, 8 August 2014 (UTC)[reply]

If you'd like to discuss status quo, my changes, each of them, were a simple change from somebody's idiosyncratic whim to a standard default, supported by a long-standing status quo of never centering images which are not necessarily panoramic unless there is some important reason to, and an overarching tradition of standardizing article presentation wherever possible. Show me where we decided to let people start centering things at will and I'll gladly revert. Texugo (talk) 14:32, 8 August 2014 (UTC)[reply]

Again - if ttcf is important to you, then why does centering or non-centering of images come first ahead of the traveller? PrinceGloria (talk) 14:46, 8 August 2014 (UTC)[reply]

I look at it from a wider perspective, from a prospective of proportion, and it is necessary to do so. It's a sliding scale, and we do have to have limits somewhere. We cull lists that are too long, we format our listings, we standardize our headings and sections, we don't allow montages, we discourage personal itineraries, we disallow most attraction articles, and we do lots of other things which somebody might claim preclude things of more benefit to the traveller. The fact is that a lot of these things are relative and have to be weighted against the overall layout and balance of the article. Yes, zoom 12 shows a bit more than zoom 11, just as zoom 14 shows a bit more than zoom 13 and 800x500 shows more the 750x450 shows more than 725x450 shows more than 675x500 ad inifitum. It's a sliding scale, meaning that it is subjective as to where we draw the line, but we obviously can't simply aim for what shows the most. I draw the line before it interferes conspicuously and disproportionately with the flow, layout, and readability of the rest of the article, and before it starts to violate our general practice of not centering things unnecessarily. You obviously draw the line somewhere else (or not at all). But you don't get to accuse me of not caring about the traveller. Texugo (talk) 15:07, 8 August 2014 (UTC)[reply]

I still don't see why layout issues should take precedence before ttcf. If our layout does not work and hinders providing information that are beneficial to the tourists, we should change the layout. If a map gets too large and starts interrupting the flow of text in the paragraphs, we center it. We split lists if they get too long, but this does not mean we need regional articles if there are more than nine bullets in a list - like the case of Germany proved. I believe ttcf is paramount and making the map just the right size for it to be useful to a traveller at first glance has much value over just providing a standardized map window. Which is why static maps come in all shapes and sizes. PrinceGloria (talk) 16:24, 8 August 2014 (UTC)[reply]

I don't know how to explain any clearer why your ttcf argument is flawed. Your argument says that x+1 is bigger than x, showing more to the traveller, therefore we should use x+1. The full implication of that logic is that we should always make the map as big and a zoomed in as possible, say, covering the whole screen, "for the traveller's sake". If I were arguing for a full-screen-sized image within the article, would you support it? If not, what would your response be when I say it'd be more useful to the traveller? If someone positively insisted on that, claiming ttcf, perhaps you'd feel the same frustration I feel in responding to your ttcf claim. Obviously we don't want a full-screen-sized image within the article (which is why we link to it). So that leaves the question of given that the map is easily manipulable and a full map is a click away, what is a reasonable size for showing the map within the article? Your answer — ignoring the dynamic aspects, the full map a click away, and the fact that it's not intended to be printed as is — appears to be "as huge as I like". My answer is that the default size is perfectly sufficient in the vast majority of cases, given that it is a dynamic widget that still provides all the same functionality. Please drop the ttcf angle.

And if you want to talk about static maps coming in all shapes in sizes, well, yes, that is true to a degree, though much of the shape variation can be attributed to the need in those cases of including a key with list of numbers. But you kind of reinforce my argument here — static maps are not supersized to dominate the screen, and have very rarely been centered, and only in cases where the lay of the land is really really rectangular, a special circumstance I'll certainly allow for dynamic maps too. But not for just any ol' article like you seem to crave. Texugo (talk) 17:17, 8 August 2014 (UTC)[reply]

The map size needs to be chosen so that the map is legible (and yes, the print version matters). A one-size-fits-all approach is not helpful as it makes the guide less usable. K7L (talk) 17:48, 8 August 2014 (UTC)[reply]

Erm. Go back and read the whole page where that has been discussed at length. The dynamic nature of the map means that a) it's legible at any size, and it shows more labels the more you zoom in, b) the number and quality of things you'd prefer to be be labeled initially is subjective, and c) whatever your personally desired level of initial labeling may be, the user can reach it very, very easily anyway. And I do not advocate an across-the-board one-size-fits-all approach. There are clear exceptions where adjustments make sense, but it is exceedingly rare that one can't set up a completely usable map at or near the default size on the right. And no, we have never had the goal of making maps printable from the article screen, never. We had some guidelines about sizing static maps on the page so that their rigidly proportional fonts are legible, but the point was never to make them printable at that size; it was so that people could read them onscreen without leaving the page. But the dynamic maps resize the fonts to whatever zoom level you're at, making all that completely moot. Texugo (talk) 17:57, 8 August 2014 (UTC)[reply]

What K7L said says it all, no more words needed. Everything else is just verbosity trying to cover up a flawed argument. Ttcf trumps it. PrinceGloria (talk) 18:17, 8 August 2014 (UTC)[reply]

I just gave you an explicit reasoning of why your ttcf argument is flawed, with pointed questions. You're choosing to ignore that, ignore my response to K7L, proclaim my argument flawed instead with no reasoned logic at all, and then reproclaim your argument as a trump card? Come on. Proclaiming yourself winner in the middle of such a conversation does not strike me as very mature. Either respond to specific points or leave the conversation. Texugo (talk) 18:31, 8 August 2014 (UTC)[reply]

I am not proclaiming myself as a winner, as we are not searching for a winner but for a way to serve traveller's interests best. I believe we are drowning the argument in verbosity an that K7L summed it up succintly, but since you asked for your questions to be answered, there you go (plus some comments on your statements):

• If I were arguing for a full-screen-sized image within the article, would you support it?

I would agree with any proposal you might raise that would serve the traveller best. I have no prejudice as to their nature, my concern is whether that would be an application of ttcf.

• Obviously we don't want a full-screen-sized image within the article (which is why we link to it).

I don't know if we do or don't - e.g. the banner is pretty much full-screen sized, at least when it comes to width, and it serves us well. We want everything that serves the traveller best, layout issues are of secondary importance. If it would serve the traveller better to completely rework our layout and it would be doable, I would support that wholeheartedly.

• There are clear exceptions where adjustments make sense, but it is exceedingly rare that one can't set up a completely usable map at or near the default size on the right.

On the contrary, my experience shows that most cities and districts don't fit well within a 420x420 box and require a diversion either way to make the map useful - although I agree, only in extreme cases do you need to go "full screen" if the area is very wide and requires large amount of detail to be shown. You can indeed fit ANY area in the 420x420 box, but this doesn't make it useful.

• And no, we have never had the goal of making maps printable from the article screen, never.

Well, as a user as much as an editor, I can now see that we need to include this as a goal, as I find it useful. And I guess I am not alone in finding this useful. The only casualty may be that the map windows won't be the same size and that layouts will require some adjustments, but this should not be a problem and proved pretty easy to accomplish.

• The full implication of that logic is that we should always make the map as big and a zoomed in as possible, say, covering the whole screen, "for the traveller's sake"

Nope - I just believe we should not strive to standardize map sizes across all articles and let map dimensions be adjusted to the area the article is covered. I agree that in some articles the map sizes may have gone out of hand and we could do with less oversized maps, but we don't need a blanket policy to handle that, just a simple edit, and if there is any controversy, some discussion in the talk page. I agree with some of your edits and will not contest them. I am just against a blanket policy and wholesale application thereof everywhere. PrinceGloria (talk) 19:34, 8 August 2014 (UTC)[reply]

Ok look, this is getting really old, so let's compromise a little here. I am willing to be flexible with sizing, since we've never really had a standardized size for static maps in the past. I disagree about the need to mess with the size in most cases, and I still wish you'd think of it as the dynamic widget it is rather than another form of static map, but I can accept flexible sizing as part of the status quo, especially after seeing restraint used in the majority of the things I came across in Category:Maps with non-default size. I insist though, that we continue to refrain from centering except in the rare cases where the unavoidably long rectangular shape of the area truly calls for it. Given all our static maps and every other kind of image we have as precedent, this approach should also be accepted as the status quo.

Of course, any of us can still discuss opening up centering for broader use (in your case) or discouraging unjustified non-default sizing (in mine), and maybe we reach consensus for one of those changes, and maybe not, but it is important that we all understand what the status quo has been up to this point, so we are all on the same page regarding our starting point. Texugo (talk) 20:20, 8 August 2014 (UTC)[reply]

I'd really appreciate if everyone can keep ttcf out of this. It can be argued that any map size and dimension serves the traveller best.

Although it was great that we some vibrancy in our previous discussion on the issue, I personally felt it was worth leaving for a while so that Ryan's experiments with Javascript and cookies could continue as well as leaving everyone time for pause and reflection.

In the interests of consensus building, I would suggest instead of changing map sizes back to their default sizes on mass, this is probably an opportunity to take each major article where it applies and have the discussion about why city X needs a map dimension that is significantly different to the default. Andrewssi2 (talk) 01:13, 9 August 2014 (UTC)[reply]

To be clear, the name given to this thread is misleading. The main point of my edits yesterday was not about size, but rather, to put images which had been unjustifiably centered back to the right, back in line with the long-established status quo on image alignment which no consensus has been reached to deviate from. Maps where only the size was changed have been left untouched and will generally remain so. Texugo (talk) 01:25, 9 August 2014 (UTC)[reply]

And as I said to PrinceGloria at the top of this thread, I'd be glad to see any of those get some discussion on their talk pages if anyone sees a case worthy of exception, but the starting point must be represented by our status quo on not centering images. Status quo always prevails until there is consensus to change it or to make exceptions; that's just how it works here. So any talk about reverting back to the non-standard versions and then discussing each case before it can go back to the status quo is completely backwards. Texugo (talk) 01:39, 9 August 2014 (UTC)[reply]

If this is about size, no, there is no policy imposing a specific size on maps as status quo. You've likely confused maps with images, where there is a guideline (not a policy) to avoid large galleries that take a long time to load on a roaming mobile device or backwater dial-up connection.

If this isn't about size but merely alignment, I trust that you will delete Category:Maps with non-default size‎ now and revert the corresponding edits to {{mapframe}}, a template which is on hundreds of pages and should not be targeted with controversial edits in the absence of consensus to do so? Thank you. K7L (talk) 01:48, 9 August 2014 (UTC)[reply]

In defence of Category:Maps with non-default size‎ , does it have to be regarded as a 'hit list'? Isn't it useful to know that there are 375 articles affected by the sizing discussion (not the alignment discussion) ?

The existence of this category page doesn't automatically mean that any article included requires remediation. Andrewssi2 (talk) 02:05, 9 August 2014 (UTC)[reply]

Exactly. As I've asserted twice already, I am more concerned about alignment and less about size. However, despite K7L's assertion/fear, that maintenance category was created for informational purposes which I'll stand by. And the fact that the template is on hundreds of pages is completely irrelevant given that the change in question is a hidden one which does not change any of those pages, but merely allows us to easily consult useful information which cannot otherwise be consulted. I cannot understand why K7L is so interested in suppressing the availability of that information. Incidentally, my proposal in the pub to change "Articles needing attention" to something more neutral was, in part, an effort to further dispel this assumption that this type of category is a hitlist, but, magically, K7L has opposed that change too. Texugo (talk) 02:10, 9 August 2014 (UTC)[reply]

That looks like a good example of a completely useless activity. As long as there is no good way of exporting maps (and, as far as I know, nobody has been ever working on it), readers should get the best possible piece of a map with the properly adjusted dimensions and zoom level. Most readers will print the page without reading it carefully, and they should get a meaningful image instead of a small useless box on the right-hand side. That said, this approach can be reconsidered (and individual cases fixed by a bot instead of doing it manually) when suitable tools for map export are developed. As long as such tools are not available, removing big maps is similar to removing embedded maps completely. --Alexander (talk) 09:53, 9 August 2014 (UTC)[reply]

I'd ask you to take a step back and rethink that, Alexander, because the question here has absolutely nothing to do with whether you support big maps or not. If it were a change you opposed, it would be a little easier for you to see, but it is nonetheless true: it is absolutely not a useless activity to ensure big sitewide changes happen properly, through consensus. Just because you happen to support a change that started slipping by without consensus does not mean it should be allowed to happen, and doesn't give anybody the right to harangue someone who reverts those changes until consensus is reached. If we get consensus for a new goal of supersizing maps to ensure they're always usable in print form, and if we get consensus to start centering images that are not necessarily panoramic and breaking the articles in half with a big wide space for the map — two things which are undeniably different from the way things have been done in the past — if we do get consensus for those changes, you can bet that I will push strongly for all such articles to consistently have screen-width big maps, and I'll be equally zealous in ensuring that that consensus is carried out. But for the time being, I refuse to let sitewide layout changes that contravene tradition slip by without a consensus for them. And you should too, because next time it might happen to be something you oppose. Consensus first, changes afterward. Texugo (talk) 14:47, 9 August 2014 (UTC)[reply]

FYI, there are several fundamental problems related to the dynamic maps, such as providing meaningful maps in print and pdf versions, maps of huge cities, where all POIs are stored in district articles, making embedded maps compliant with the privacy policy. All these things will likely influence the way how maps are displayed in Wikivoyage articles. Therefore, fiddling around with map sizes and centering is really a useless activity, I am sorry to say that. And I am really willing to see people who will strive to solve the fundamental problems instead of wasting time on reaching consensus regarding the map centering or other issues that are absolutely unimportant. --Alexander (talk) 15:20, 9 August 2014 (UTC)[reply]

Well, sorry, that's just how it's supposed to work. We can either stick to status quo until a consensus changes it, as we are supposed to, or we can let changes run wild and struggle to get them back under control later. I feel that I am completely justified in making sure we do the former, and I definitely do not feel that defending our consensus process from distortion is a waste of time. For what it's worth, I'd also prefer we concentrated on the problems you mentioned, but I'm not willing to let the ground shift under our feet while the discussions have not concluded. If we don't hold the status quo still pending consensus, those discussions are much harder to have. And to be honest, correcting those mere 110 pages to match the norm we've set in our other 26,000 pages over these ten years was not nearly so "massive" or so time-consuming as some are making it out to be. It's nothing compared to the time I've spent recently fixing breadcrumbs or cleaning up the geographical hierarchy, for example. Texugo (talk) 15:40, 9 August 2014 (UTC)[reply]

The status quo is that there is no existing policy forcing maps to be one particular size and no consensus to create one. Your unilateral tampering with {{mapframe}}, a template used on over a thousand destinations, is the sort of "changes run wild" which the status quo bias is intended to prevent. Get consensus or revert, please. K7L (talk) 19:01, 9 August 2014 (UTC)[reply]

How many times must I say it? Size is not my concern and I agree that there is no consensus to standardize map size. But status quo regarding centering is cut and dried: we have no history of centering maps or any other type of image unless they are necessarily panoramic. There is simply no way for you to argue otherwise. Texugo (talk) 19:11, 9 August 2014 (UTC) And as I've already said, the fact that map frame is on hundreds of pages is totally irrelevant since my changes do nothing to any of them. They simply populate categories, behind the scenes, that's all. No harm in the slightest, purely informational, and started in just the same experimental manner as most other maintenance categories. You should really drop it. Texugo (talk) 19:27, 9 August 2014 (UTC)[reply]

No, the category is not purely informational if you're using it as a semi-automated tool to help you remove width, height, layer and other {{mapframe}} parameters from large numbers of articles without consensus. Endlessly reposting the same claims to prevent anyone else from even briefly having the last word on this topic doesn't change that... nor does attempting to rename the parent category "articles requiring attention" in an attempt to whitewash this. You've hit a long list of articles. Let's not pretend otherwise, or try to change the topic to "centring" when your little hit-list category clearly indicates "size" as the target. K7L (talk) 19:42, 9 August 2014 (UTC)[reply]

Texugo, map size was a piece of useful information collected by hand. Even if you don't want to see it in the article, it is useful (I would even say, indispensable) for the print version. But you simply removed it and ruined the work done by others. --Alexander (talk) 20:25, 9 August 2014 (UTC)[reply]

Alexander , if large map sizes are truly indispensable to the print version then frankly the discussion needs to be had to change the default settings for the dynamic map template.

If we can get agreement that Texugo's motivation was to identify and remediate center map alignments then we could actually move on to the secondary question of the size issue. Andrewssi2 (talk) 00:12, 10 August 2014 (UTC)[reply]

Thank you, Andrewssi2. I would challenge anyone to establish that my motivation was anything but to identify and remediate centered map alignments. If you look at the chronology of my edits, I first created Category:Maps with non-default alignment (which K7L seems to have overlooked) and, finding many of them to have no justification for being centered,brought those back in line with the traditional way of inserting maps on the right unless they are necessarily very rectangular. (Yes, the size setting were usually a casualty here, but that is only because sizing a map you intend to center is different from sizing a map you intend to right align, so the size settings don't usually make sense when you put it back on the right.)The items remaining in that category are perfect examples of things that need exception, being of the same type that we have made exceptions for historically, and are certainly not targets. The category remains as an informational means of consulting those examples and ensuring that where alignment has been changed, there is a justification. It was only after all that that I created Category:Maps with non-default size and, not finding it full of things which clearly need correcting, I barely made any edits to mapframes after that point. The categories do not represent hitlists, as the things in there are not necessarily targets, but they may be useful for catching unjustified exceptions in the future, and they do provide information that is useful, especially for the ongoing policy discussions. I'd also like to point out a couple of other things:

• Just because someone has put in work on something which goes against our style does not mean it automatically gets to stay. People put lots of work into making big tables of bus lines or prices or flight connection, long lists of pets store and dentists, etc. etc., and it sucks that they put in all that work in vain, but we delete the stuff nevertheless
• Correcting 110 or so articles to match the style we've always used is not an "en masse" change and does not require consensus, no more than it would be for any kind of MoS edit, because it only corrects things that violate our agreed upon way to do things. Like WOSlinker and others, I very often pick up on a problem and then go through hundreds of articles fixing that problem. Immediately prior to the edits in question I changed about a hundred Go next listings from templates to one-liners. This is not a big deal.
• The bad-faith accusations from K7L are inappropriate and need to stop.

Bottom line, if you are for centering maps, fine, but you have to realize that we do not yet have consensus for them. Instead of attacking someone who is just preserving the status quo — an approach fully sanctioned by our policies — instead of pretending there is already consensus or trying to force the change through without the necessary discussion, your time will be better spent trying to achieve a consensus on our policies and addressing the other problems Alexander pointed out above. I didn't do anything wrong here. And if you accept the principles WV abides by, I didn't even do anything controversial. Texugo (talk) 11:38, 10 August 2014 (UTC)[reply]

I think that we need to update the instructions here. Currently in Embed a dynamic map we have "align is the alignment of the map frame. Optional - default is right aligned (other values are "left" and "none" (center)).". If we want all maps to be right aligned, then we should say so here e.g. "maps should be right aligned". The edits did also change other things like layers, and the shape of maps which I think matters for city districts. AlasdairW (talk) 23:09, 10 August 2014 (UTC)[reply]

I agree, instructions need updating to reflect the fact that centering has always been reserved for unavoidably long rectangular maps. As for layers, most of the pages I changed had no layer assigned. Of the few that did, I thought quite a few were an odd choice either because they were distractingly cluttered with not quite relevant color codings or they showed an elevation map for an area with uninteresting terrain, etc. As layer choices are subjective and not spoken for by the status quo, if you disagree with any of my changes, feel free to reinstate the layer (but not the centering, of course) and/or start a discussion. They are totally negotiable. That goes for sizes too. I tried to make sure the right area was displayed after my change, and I did not always remove the sizing info, but if you know of a case where the result is not showing the intended map area, feel free to fix it and or discuss. I just don't think any of the remaining ones are of the long horizontal type that merits exception with regard to alignment, like Trans-Siberian Railway, and there is no consensus to start centering anything that is not of that type. Texugo (talk) 01:32, 11 August 2014 (UTC)[reply]

"Up