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]
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. Franke-mailtalk13: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'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. --PeterTalk21: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. Frankemailtalk15: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]
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.)
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.284991Accents 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}}
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. Franke-mailtalk22: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]
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. Franke-mailtalk01: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]
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)
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]
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]
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.4108: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=)
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]
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.4122:47, 24 January 2014 (UTC)[reply]
Guidelines for Positioning and Sizing Dynamic Maps[edit]
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?
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]
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]
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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]
Big map on Windows Phone platform
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)
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]
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]
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]
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]
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. Thatotherpersontalkcontribs00: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.) Thatotherpersontalkcontribs00: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. Thatotherpersontalkcontribs02: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]
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]
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]
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]
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.
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]
Greenwich Village Map
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.
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]
We seem to have two slightly different instructions on how to use dynamic maps, depending on the page you read:
. 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."
. 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]
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]
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)
Only add dynamic maps to articles at the lowest level of the article hierarchy (city or district).
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.
Do not add a dynamic map when a Wikivoyage-style static map is already present.
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.
Zoom should be modified as appropriate and show the majority of POI's in the article.
Itinerariesmay have flexibility to use appropriate dimensions as required to display the subject area. Center allignment is also allowed for large maps in this category.
Do not add more than one dynamic map without discussion on the article talk page.
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 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).
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 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]
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]
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.
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]
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 levellower 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. Thatotherpersontalkcontribs01: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.
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.
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.
Do not add a dynamic map when a Wikivoyage-style static map is already present.
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.
Zoom should be modified as appropriate and show the majority of POI's in the article.
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.
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. Thatotherpersontalkcontribs05: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.
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. Thatotherpersontalkcontribs06:42, 27 June 2014 (UTC)[reply]
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):
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.
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]
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.
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!
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. Thatotherpersontalkcontribs02: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 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.
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]
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]
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.
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.
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]
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]
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]
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).
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]
Massive standardization of non-standard map sizes[edit]
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]
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]
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]
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) ?
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]
"Updating the instructions here" would be a change to a status quo which was serving us just fine. I don't see the need for this. K7L (talk) 04:11, 11 August 2014 (UTC)[reply]
In terms of center aligning images and maps I do not believe there is any status quo, either explicit or implicit. I thought center alignment was a fairly obvious 'exception only' case? Andrewssi2 (talk) 05:01, 11 August 2014 (UTC)[reply]
I'm coming into this discussion late and won't be able to participate much until I get my own computer back and running, but my feeling is that (1) I don't care about center-alignment vs. right-alignment on maps any more than I care about it in terms of other images, and therefore am happy to defer to others who have given reasons for caring about this; (2) I strongly believe that maps in articles need to be useful, which means that they need to be at least marginally readable on the page itself. That is a matter of size and clarity, and it's way, way more important to me and to the reader than whether the map is justified right or center, I think. Ikan Kekek (talk) 07:45, 11 August 2014 (UTC)[reply]
Andrewssi2, status quo just means the way we've always done it, which yes — you are correct — has always been "exception only". See below.
K7L, those instructions only represent factual instructions on how the template works, and are not wrong in that respect. Updating them to include how the template should be used, in line with how we've always done it, would represent no change requiring consensus.
Hi Ikan. I'd like to point out that this particular discussion requires no opinion about whether we should start centering maps or not — it only hinges on whether we already have an established consensus to do so. Opinions on whether we should belong in the other threads above this one.
Look, folks, all that is required here is respect for our policy of change-by-consensus and an objective look at the evidence in the form of, well, our whole body of articles. And the only question at hand is are Texugo's edits in line with the way we've always inserted maps? And I would challenge anyone to demonstrate that they are not. Look through as many of our 26,000 pages as you like, find 20 articles where we've centered a map (or any image) that doesn't need to show a long horizontal area. Find 10. Find 5. I rather doubt there is even 1. If you can't establish that we have a history of doing that, then you have to concede that our status quo has always been to right align maps and let the article flow around them. And if you can't show where we reached a consensus to change that, then you have to concede that my edits simply preserve the status quo against a change that has not been agreed upon yet. Anyone who still condemns my edits without evidence to the contrary is actually just maneuvering for their desired change to be allowed to slip by without consensus, which is contrary to the spirit of collaboration. Again, consensus comes first, changes come afterward.
We've always been able to adapt map size, position and aspect ratio to be where it best fits the article. A 420 x 420 px square map of the Trans-Canada Highway makes no sense if it's an east-west line. Conversely, what works for that road won't work for U.S. Highway 1, which runs north-south. Same with cities, Buffalo/West Side is a north-south strip along the Niagara River; Canton (New York) inexplicably runs east-west. What you're proposing isn't a "factual statement" in a help file, but a policy, intended to restrict map size, dimensions and placement. Your recent removal of parameters from {{mapframe}}s in over a hundred articles makes that clear. If you're changing (or attempting to change) policy to further restrict authors, what you are doing is not status quo, so please stop pretending. I am not going to let either your edits or your proposed change to an even more restrictive policy "slip by without consensus", sorry. Please stop changing templates, categories, policies and huge numbers of destination pages like this. K7L (talk) 14:41, 11 August 2014 (UTC)[reply]
You listen frustratingly little. Yes, we have always had exceptions, such as Trans-Siberian Railway. Yes, I agree that Trans-Canada Highway deserves the same exception, and Canton's might be arguable (neither were among the articles I changed). Yes, yes, yes, exceptions for articles where the area shown has such an extreme horizontal disposition. Yes, taller maps for extreme vertical disposition (neither Buffalo/West Side nor U.S. Highway 1 were among my edits either). That's how we've done it in the past, and I propose no change to that. Nor do I propose new limits on sizing or whatever. In fact, I'm not proposing anything at all, except that we continue inserting maps the same way we always have until we have consensus to do it differently. But precedent, status quo, the way we have always done it — it is absolutely, inarguably the case that, barring those exceptions where the area is very horizontal, we do not center, never have. If you disagree, if you think that is not how we've always done it, please show me. Texugo (talk) 14:54, 11 August 2014 (UTC)[reply]
Although I generally don't like to participate in these discussions, I've been following this one and feel now that I must say something. As a relatively new user, I've added many maps to articles and generally use the default settings. When I've decided to use nonstandard sizes or centering (on just a couple of articles), I do so with careful consideration, and I have not found until now any discussion expressly discouraging or forbidding such placement.
It is very frustrating when my carefully placed maps are reverted back to default status with no explanation whatsoever (for example Hajar Mountains v.1 vs. v.2). It is apparently now up to me to raise the issue on the talk page and prepare to argue ad nauseum about why my decision was justified – a painful process for which I have neither time nor the inclination. This sort of rigidity I find frankly stifling. StellarD (talk) 16:09, 11 August 2014 (UTC)[reply]
Hi StellarD. I'm sorry you feel your toes stepped on but as I mentioned above, work done does not in itself legitimize a change for which there is no consensus. Our professed status quo bias means we do it the old way til a new way is agreed upon. Your input would certainly be valuable in a discussion to reach a new consensus to start allowing centering at the free discretion of anyone, but that is not what this conversation is about. If consensus is reached there, the map settings you chose are still in the history and can easily be recovered. Meanwhile, I do not see as how Hajar Mountains is necessarily of the same oblong linear layout as the other exceptions in Category:Maps with non-default alignment, such as nearby Muscat. (Incidentally, it does helpfully illustrate how I didn't just go wiping out all the layer info indiscriminately.) Oh, and I apologize that my edit to that page had no edit comment. A look a my contributions page will show that that was not the case with the (later) edits in question. Texugo (talk) 16:41, 11 August 2014 (UTC)[reply]
User:Texugo, I said above that I don't care about map-centering and that I'm happy to defer to you on that question, and then you replied to me by discussing map-centering. I've started a new thread below that clearly addresses the issue I care about in regard to maps - and it's really the only issue I care about in regard to maps. Ikan Kekek (talk) 18:25, 11 August 2014 (UTC)[reply]
That's not what I meant, haha.. To be clear, the question here is absolutely not "what do you think about centering?" I don't care if you are for or against it, and that question is for another thread. The question here is "why would we allow a broad change like that to go through without consensus". And the answer must be "we won't". Status quo prevails until consensus changes it, and that's all my edits were about. Texugo (talk) 18:42, 11 August 2014 (UTC)[reply]
I do seem to recall a conversation where you made a similar claim. I don't have any idea where you got that from though. My approach comes directly from where our policy says:
In the case that a consensus becomes impossible—those involved have carefully responded to each others' arguments, but remain in disagreement—we stick with the status quo practice. (If there is no status quo practice, a compromise solution may be necessary.) This lends Wikivoyage a strong status quo bias. While sometimes frustrating when you want to make a change, this bias is deliberate because it encourages Wikivoyagers away from endlessly debating intractable issues and towards the purely productive work of adding new content, rather than sparring over existing content.
If your claim is that there "is no status quo practice", by all means, demonstrate that, because from what I have seen over 8 years here across all our articles is that maps always go on the right except for the rare case where the area that needs to be shown happens to be very long horizontally. Texugo (talk) 02:15, 13 August 2014 (UTC)[reply]
Something doesn't magically already become "status quo practice" just because you wish it were so. You're proposing a change, which takes away flexibility which allowed authors to size and position maps as needed for individual destinations. You need to justify why that change is needed, or even wanted. K7L (talk) 04:26, 13 August 2014 (UTC)[reply]
The evidence is all before us, K7L. The status quo is exactly as I described. If I am wrong, show me the evidence that proves we ever centered at whim n the past. I believe you cannot because that is simply not how we've done it in the past. Which means the change being proposed is that we start doing so. And that is where consensus is needed first. Stop repeating simple denials and show us where your approach has ever been considered OK. Texugo (talk) 10:41, 13 August 2014 (UTC)[reply]
The status quo bias applies after a discussion fails to come to a consensus. That doesn't mean that change can't happen without discussion. Sometimes site practice evolves organically, without explicit discussion; then, at some point, someone finally gets around to changing the documentation. Powers(talk)23:43, 13 August 2014 (UTC)[reply]
Nice try, but we've always had maps, we've always had a standard way of inserting maps, we have a history of never centering any kind of image if it can be helped, and the result has always been that we successfully avoid having giant gaps in the flow of our articles when possible. Just because the source of the map image is different doesn't mean we suddenly throw all layout precedent out the window and skip the discussion on whether to start letting people start formatting articles however they want. And we've been having that discussion above, and it has unquestionably failed to come to a consensus thus far, hence my status quo edits. Texugo (talk) 23:55, 13 August 2014 (UTC)[reply]
Unilaterally stripping template parameters out of over a hundred pages is not a "status quo edit", it's quite the opposite. These need to be reverted. K7L (talk) 02:40, 14 August 2014 (UTC)[reply]
My edits changed the only articles, less than half of one percent of all articles, where the new practice of centering had been used, all of which had slipped by in recent months since the advent of dynamic maps. To claim that this tiny fraction constitutes a new status quo just because it crept, without consensus, into a mere 110 or so articles while we were experimenting with {{mapframe}} is completely ridiculous. On the contrary, it is a new practice, obviously a controversial one given the conversations above, and it has not gained any consensus. Thus, every single one of my edits simply restored an as-of-yet unsanctioned change to the way we have always done things (=the status quo) because there is still no consensus for the new way, and that makes them status quo edits that are completely in line with our policies. Whether it's one edit or 200 or whatever is irrelevant if there is no consensus for the change it is correcting. For the millionth freaking time, if you are going to claim that centering any ol' map you want is not a controversial brand new phenomenon, show us the evidence. Texugo (talk) 02:58, 14 August 2014 (UTC)[reply]
Proposition: Maps should all be readable in the relevant articles[edit]
There's a discussion above about centering maps. That's not my issue, and I would like no discussion of it in this thread. Instead, please address the very simple proposition that any map that's in an article should be at least marginally readable within the article, to the extent that's possible. I've read claims that there's never been a consensus behind this straightforward proposition, but my reading of goals suggests to me that this should not be controversial:
Wikivoyage articles should be useful for at least the following contexts [here follow those which seem most relevant]:
Online use by travellers on the road – for example, travellers huddled in a late-night internet café in some dark jungle, who need up-to-date information on lodging, transportation, food, nightlife, and other necessities.
Offline use by travellers on the road – for example, travellers sitting in a train with a subset of Wikivoyage on their mobile device.
Individual article print-outs – for people who want to print, say, a list of museums or karaoke bars and put it in their back pocket for when they need it.
Ad-hoc travel guides – for people who want a small fit-to-purpose travel books that match a particular itinerary.
Now, once we agree that all maps should be large and clear enough to read, we can talk about the practicalities involved, but let's agree on the principle first. I feel that this is long overdue. Ikan Kekek (talk) 18:22, 11 August 2014 (UTC)[reply]
I'd also really consider it highly advisable for maps within articles to be readable in printouts, and would definitely support that policy, too, which I think would clearly go along with the goal of usable individual printouts. Ikan Kekek (talk) 18:28, 11 August 2014 (UTC)[reply]
Maps should be as readable as possible. This is obvious.
As as I side note, I can say that foldable maps (wrapped/unwrapped by a mouse click) is a possible compromise between having a big readable map and keeping the layout of an article. Example is here, click on the small map icon under the first text paragraph. --Alexander (talk) 18:36, 11 August 2014 (UTC)[reply]
"Readable" needs to be defined a little more clearly, or this matter is completely subjective. With dynamic maps the font is always sized to be "legible", no matter the zoom level, so the question with regard to text is left to a rather subjective opinion of how many labels should be initially visible. Street detail works that same way. There is no way for us to show maximum detail for most destinations without going full screen or worse, and certainly no way to ensure that all POIs are visible and not little pluses, so the question always remains of what level of detail is reasonable? For most places, even getting it to where you can read the street names of even a third of the POIs means zooming in beyond the point where we could show the whole area on an in-article map. So what is "readable"? In any case, dynamic maps are never fully usable unless you zoom and scroll around with them. Texugo (talk) 18:54, 11 August 2014 (UTC)[reply]
It's a good solution to have a map which is hidden by default and can be open whenever needed. If the user is online, s/he can zoom and move around absolutely freely on the dynamic map. We could certainly have an "Open a map" link in some prominent place, like in the Russian version.
To repeat some of my earlier thoughts about this, do we really need to have a visible map embedded in the article itself or could we ditch it altogether? As of now we have the map in the Get around section, which means you will need to scroll up and down if you are reading about particular POIs located in See and below. Plus, for the embedded map to be useful as printed it would need to both (1) cover a wide area, say 5km x 5km at least and (2) obviously be zoomed in enough to have (almost) all the streets and POIs visible which would mean that it would have to be so large that it wouldn't fit on anyone's screen. To get a smaller map we would either need to have less zoom or just cover the most central couple of blocks of the city.
For the printable version, wouldn't it be good to have the map as a separate appendix in the printable version (which is what you are going to get when you print it), which would be printed as an extra last page? At the moment you're walking from A to B you need just a map with streets and landmarks and POI(s) you're going to and not the whole guide with its descriptions, which you have presumably already read at the hotel room, café, bus or whatever. ϒpsilon (talk) 19:14, 11 August 2014 (UTC)[reply]
[Edit conflict:] How about "as readable as possible without going past an entire screen, maximum"? I wouldn't support using an entire screen as default but as maximum (unless perhaps we adopt our Russian sister site's solution, which produces a beautiful map that could be hard to print out in certain situations). And recognizing that different computers have different screen sizes, I would suggest an average laptop screen size. Ikan Kekek (talk) 19:16, 11 August 2014 (UTC)[reply]
I'm willing to consider the solution that Alexander and ϒpsilon suggest. It would be problematic for someone with a not-so-smart phone that can't keep more than one window or tab open (or easily open) at the same time, but perhaps we shouldn't concern ourselves too much with people like me who often use obsolescent technology. :-) Ikan Kekek (talk) 19:19, 11 August 2014 (UTC)[reply]
(edit conflict) I fail to see how "as readable as possible" would not always produce full screen maps. I think that wording would make it the de facto default. I think it is better to adopt ϒpsilon's approach in making the full size map a default part of the print version, and not trying to do the impossible with the map in the article, given that it's meant to be zoomed and scrolled by the user anyway. Making it expandable as suggested would be great. Texugo (talk) 19:22, 11 August 2014 (UTC)[reply]
You're right. I'll rephrase: Readable enough for at least 75% of streets and points of interest on the map to be clearly visible for a person of 20/20 eyesight. Also, let's remember that there are still articles with static maps, and those can be better that dynamic maps in certain situations but do need to be readable. Ikan Kekek (talk) 19:27, 11 August 2014 (UTC)[reply]
I don't even think 75% is a meaningful number, especially if there are lots of POIs. What's 75% of this? You can't get 75% of POIs to not be pluses even at full screen, much less show 75% of street names. And that's a small city of 61,000. Texugo (talk) 19:43, 11 August 2014 (UTC)[reply]
Yeah looking at it further, 75% would also result in maxed out maps pretty much every time. A full screen map for Albuquerque doesn't approach 50% of street names shown. Even tiny towns without any POIs - my small hometown of Pampa for example, to show more than about 10% of street names, you have to go to zoom 14, at which point you need the full screen height to fit the whole town. Acapulco doesn't show even 5% of street names at full screen size, and complicating matters, doesn't show even 75% of street names at maximum zoom, since OSM coverage is uneven depending on where in the world you are looking. Texugo (talk) 20:10, 11 August 2014 (UTC)[reply]
Haha... That is not exactly my perspective on it. They don't suck because the user can still see anything they want to see, by the very nature of it being dynamic. If we make full-screen default for the print version, and note that for the user the full screen version is still just a click away, then whatever initially displays in the in-article map window need give no more than a basic overview in a window just reasonably large enough to navigate around in. It's not hard for the user to then manipulate the map — zoom out to see the regional placement, zoom in to see exactly what cross-street their hotel is at — because no matter what size we serve them initially, they'll likely be manipulating the map anyway if they're going to put it to any actual use. It's dynamic, and we need to think of it as a widget, a tool for the user to play with, rather than an element that must be perfectly formatted in advance to show everything the user might possibly need to see, because it's pretty much impossible for us to do that anyway. Texugo (talk) 20:27, 11 August 2014 (UTC)[reply]
Can we agree to make or at least support reasonable edits when they make it possible to improve the readability of the map - whether static or dynamic - within the article itself, or do we have to give up on that idea completely? Ikan Kekek (talk) 20:42, 11 August 2014 (UTC)[reply]
I will put my support behind such efforts provided that - and don't smack me for mentioning it - we keep it on the right, save clear exceptions for extreme horizontal disposition of the area of focus, such as those examples at Category:Maps with non-default alignment. Given that I see the point as giving a general overview and a window big enough to navigate in, that can almost always be accomplished without taking over the whole width of the article. Texugo (talk) 20:50, 11 August 2014 (UTC)[reply]
I agree with Texugo's points above. If the article has to have a wide map, then it has to. If not, then let's use the standard size. Ideally we should have something like WP's WikiMiniAtlas that would appear when clicking on the icons in the listings. ϒpsilon (talk) 20:53, 11 August 2014 (UTC)[reply]
I haven't seen WikiMiniAtlas. If we can link to thumbnails from an atlas sister site, just as link to thumbnails from Commons, why shouldn't we be doing that routinely? Ikan Kekek (talk) 21:02, 11 August 2014 (UTC)[reply]
Go to a WP article with coordinates in the article's upper right corner (articles of places and events often have them). Click on the globe between "Coordinates" and the numbers and a small map opens. I don't have any idea about how to implement it but if it works on WP someone can probably get it to work here too. ϒpsilon (talk) 21:10, 11 August 2014 (UTC)[reply]
meta:WikiMiniAtlas. Interesting idea. To try it out, it looks like we'd need a bit of a js whiz to modify that to use the poi map rather than the one with all the WP article points on it, which is rather over my head. I'm also wondering if calling it once per listing as suggested, up to 150+ times on a single page, would affect load time, etc. Texugo (talk) 21:54, 11 August 2014 (UTC)[reply]
So it's a Java script on Meta, and not a site like Commons where a user can easily search for the name of a place. I don't think I have the expertise to judge it. Ikan Kekek (talk) 22:28, 11 August 2014 (UTC)[reply]
WikiMiniAtlas look very promising. Would be great if a little window could open everytime you click the POI icon without the need to change windows/tabs or scroll the screen. Can it really work that way and display our POIs? PrinceGloria (talk) 10:28, 14 August 2014 (UTC)[reply]
You may use the tools that are mentioned in the template description. First, create a GPX file [6] or export from OpenStreetMap [7](Search for relations is case sensitive). Then simplify the data to make it more compact [8]. At the end convert the data into the Mapmask format [9]. - Joachim Mey2008 (talk) 07:48, 28 December 2014 (UTC)[reply]
Ah, great! I was a bit confused at first.. why am I using a route editor? But going through the whole process it makes more sense.
In the guide is written that the default layer is "Mapquest Open" but the default is "Mapnik (OSM, OpenStreetMap)", because is the only one that do not infringe the user's privacy, so the documentation should be updated, and all the other layers (not marked with the meta-logo) disabled in the Template:Mapframe. Disabled means not shown in the article on page load, but clearly they will remain choosable by the user as is now, so like any external link, there is a clear will to share their IP with a third party.
Because of the map server failure, the "Mapquest Open" has been centrally activated inside the template, but this is (IMHO) an acceptable temporary patch. --Andyrom75 (talk) 14:12, 29 June 2015 (UTC)[reply]
If I use "layer=" with the parameter left blank, it still tries to go to Mapnik, despite it currently being broken. Removing "layer=" entirely seems to show Mapquest. Thousand Islands was showing this issue, if you look at the edit history. K7L (talk) 14:46, 29 June 2015 (UTC)[reply]
K7L, The correct way to use Template:Mapframe should be without the layer parameter. However, I can explain you what has happened in that article. If you force a blank layer parameter through "|layer=|", inside the template the parameter layer "exist" so the existence check is positive and do not assign the default value "O" (Mapquest). After that, when the what has seen inside the Template:PoiMap2 is called assign its own default that is "M" (Mapnik), that currently doesn't work. --Andyrom75 (talk) 15:42, 29 June 2015 (UTC)[reply]
Hi User:Andyrom75 - I suspect you know more about the mapping functionality than most people on English Wikivoyage, so please feel free to make any necessary corrections to the documentation. I made some significant updates to WV:How to use dynamic maps#Adding boundaries and tracks yesterday, so if you happen to notice that I've gotten anything wrong I'd be grateful for any fixes. -- Ryan • (talk) • 15:54, 29 June 2015 (UTC)[reply]
If you are fine, I would temporary patch Template:PoiMap2, disable the "forbidden" layers, change accordingly the manual, and fix the existing articles that are trying to force a layer (time ago I've already patch several articles through the bot). Let me know, --Andyrom75 (talk) 16:48, 29 June 2015 (UTC)[reply]
Ryan, at the end I've made a more sofisticated change into the templates, because there are base parameters and additional parameters, so just "O" would have been not enough. However now there is one single file to modify to change the default base map (M vs. O). --Andyrom75 (talk) 21:09, 29 June 2015 (UTC)[reply]
I'll tell you why I've removed "OG" so you can evaluate how to change the manual.
O: has been removed because is a not suitable layer (temporary in use because of server failure)
G: has been removed because, although is an acceptable layer modifier, when a GPX file exists is loaded automatically without the need of specifing it. See City of London where no G has been specified, but the GPX track is automatically shown.
Thanks. If the layer=G is loaded automatically when a GPX template exists then explicitly adding that is unnecessary. I've updated the instructions. -- Ryan • (talk) • 22:03, 29 June 2015 (UTC)[reply]
Why is the relief map layer parameter removed?[edit]
For mapframes for mountainous destinations (like Chamonix) I often use the relief map layer or "|layer=R" parameter. Now it doesn't seem to function any longer, but the map just shows the default layer. I also notice it has been removed from the list here. Apparently the other parameters do not function either.
If this has been changed due to the privacy issues mentioned in the note below the list, then (1) the parameters should not be listed and (2) it should be stated that any already set parameters will not do anything. Otherwise editors like myself are just going to be confused about why the map isn't working according as promised. ϒpsilon (talk) 10:25, 5 July 2015 (UTC)[reply]
The map scripts were not modified. In all the other language versions, the layers runs correctly. This module [10] caused the restrictions. This also applies to many other articles. For example itineraries with the layers H or C. - Joachim Mey2008 (talk) 14:44, 5 July 2015 (UTC)[reply]
Joachim, I'm very confused after reading all of the above discussions and the documentation.
Please would you tell me what are the layers that are currently working (and can be expected to keep working) in the English language version of Wikivoyage and how to invoke them?
The script "PoiMap2.php" that I wrote was not changed. It runs also in the English version with all the layers [11]. - The filter module [12] was requested by Wikimedia Foundation and was wrote by other users. I myself was strictly against this petty restrictions. -- Joachim Mey2008 (talk) 15:22, 6 September 2015 (UTC)[reply]
Thanks for your quick and helpful response, Joachim. I assume the restriction was imposed for privacy reasons. Are we ever likely to have our own reliable and fast server for maps so the pettifogging restrictions can be removed? BushelCandle (talk) 15:41, 6 September 2015 (UTC)[reply]
Yes, I've noticed there's about a 50% chance of a GPX track actually showing up. Reloading the page and/or checking the GPX box in the menu in the upper right corner of the dynamic map usually helps. ϒpsilon (talk) 16:15, 6 September 2015 (UTC)[reply]
So I have this situation in Udupi, a small town. Most of the restaurants, shops are within the town limits while the See and Do attractions are outside, in the countryside. There is no right level of zoom that can provide the right level of detail to my map. Zoom out and the town looks crowded, zoom in and the map won't show everything within the area. Any suggestions on how this can be handled? How have other cities handled this? Ravikiran (talk) 10:40, 27 October 2015 (UTC)[reply]
Is there enough room in the article for two maps, one of the overall area and another of the centre? That used to be very standard in the days when everyone depended on printed roadmaps. Ikan Kekek (talk) 11:04, 27 October 2015 (UTC)[reply]
Well, I did try that after you mentioned it, but only one map shows up. (See the source under "See/Other attractions") The code doesn't show up at all. — Ravikiran (talk) 11:16, 27 October 2015 (UTC)[reply]
The printed roadmaps didn't have much of a zoom feature :) I'm wondering if we could add an attribute to the map that would add two buttons (changing zoom levels) for 'center view' and 'larger area view', so that it would be obvious to the user that there was more to see. --Andrewssi2 (talk) 10:07, 28 October 2015 (UTC)[reply]
Well, I concede that showing the same map in different levels of zoom is probably not a good use case for why we need multiple dynamic maps, but there are other situations where it is useful. For example, you might want to show two different districts separated from each other in high level of detail. — Ravikiran (talk) 12:18, 28 October 2015 (UTC)[reply]
Sorry to jump into this conversation so late, but there is a possible workaround to provide links to detailed maps. We implemented this in Muscat, after I happened upon the example in the itinerary Rheinburgenweg. I don't know if this method is experimental or if it has gained consensus for wider use, but it did seem to work well for Muscat. –StellarD (talk) 14:51, 28 October 2015 (UTC)[reply]
Actually, if one was only going to draw one map, I'd suggest the zoomed-out view. It's easier to draw (fewer fiddly roads) and less likely to change. Powers(talk)18:02, 30 October 2015 (UTC)[reply]
Have a look at both at the embedded mapframes and the fullscreen dynamic maps in any article. I see just the maps, the POIs and the zoom level indicator. The buttons for zooming in/out, changing the map type etc. don't show up at all. ϒpsilon (talk) 09:50, 3 November 2015 (UTC)[reply]
Hmmm, I can still see them. Any particular article? I assume your issue is linked to the addition of the Wikimedia layer recently. James A ▪ talk10:31, 3 November 2015 (UTC)[reply]
Looks like this is a browser-specific problem. I tried to look at articles in Firefox and Opera now, and the buttons indeed haven't gone anywhere. But in Safari they don't show up . ϒpsilon (talk) 11:00, 3 November 2015 (UTC)[reply]
I have seen it yesterday, too, after I added a mapframe to Slavonice article. I though it was a bit odd, but was too tired to report the problem. I am using Firefox. Today it is ok again. Danapit (talk) 19:49, 3 November 2015 (UTC)[reply]
I'm not getting the buttons when I use Firefox on Mac OS Yosemite. It works fine on Safari though, as well as Windows 10 MS Edge. -Shaundd (talk) 04:51, 4 November 2015 (UTC)[reply]
I just created a MapMask for the Cotswolds from this OpenStreetmap Relation with JSOM. The result looks good but adds almost 200,000 bytes to the article!
I tried to 'simplify way', but the result was broken.
No worries :) I used JOSM to download the boundaries of districts (Relations) from OpenStreetMaps. The example I used above is extremely accurate in proving every curve every few meters in the boundary, but for Wikivoyage I feel less fidelity is required. Andrewssi2 (talk) 20:07, 29 January 2016 (UTC)[reply]
The mapmask in Cotswolds could certainly use some simplification, zooming in the dynamic map reveals that there is a huge number of coordinates. And of course every coordinate means the page grows longer.
One "uncivilized" way to create mapmasks would be to click and copy coordinates from the dynamic map, stuff them into a text editor window on your computer, remove all lat= and long= things and wrap the mapmask tag around everything. This procedure takes several seconds for each coordinate, nobody has the patience to add so many coordinates as Cotswold's mapmask has, therefore the mapmask will be simpler and the article's code will be shorter. Problem solved! ;) ϒpsilon (talk) 20:37, 29 January 2016 (UTC)[reply]
Is anyone considering putting Map Mask data into WikiData?
Obviously the way that each language of Wikivoyage may define a district differently, but I think this should be fine to share 'official' district definitions? Andrewssi2 (talk) 05:53, 31 January 2016 (UTC)[reply]
Is it possible to easily export the city boundary polygon data from sources like OSM and import it easily as Wikivoyage Mapmask boundary polygon ?[edit]
It is very subjective about how 'easy' this is to do. City boundaries are defined as 'Relation' objects in OSM, and they are definitely easy to download. The problem is then one of quality and complexity. If it is a simple boundary then you can do some minimal editing in JOSM and export as a GPX file, which will create a nice polygon for our map. If it is a complex boundary then you may be spending a lot of time trying to clean it up in JOSM, and our conversion tool may anyway get confused and not create a clean boundary. I have given up on creating a few boundaries due to various problems.
So most of the time you will create a nice boundary definition within 5 minutes (easy), and in a significant minority of cases it will take so long as to be not worth your while. --Andrewssi2 (talk) 01:30, 12 February 2016 (UTC)[reply]
Wrh2 and Andrewssi2, thanks for the tips. The instructions on Wikivoyage:How to use dynamic maps#Adding boundaries and tracks aren't helpful (I followed the instructions step by step and it didn't work). After tinkering with the JOSM software for a couple of hours, and after watching a really helpful YouTube video that explains EXACTLY how to use JOSM for downloading OSM data and saving it as a GPX file, I finally understood the necessary process to create Mapmask boundary polygons for Wikivoyage articles about cities. As a result, I tried creating and adding Mapmask boundary polygons to all of the articles about the major cities in Israel.
JOSM is not capable of downloading a section which includes the entire boundries of big cities, because it has to download all information in that layer - after failing to download the data, JOSM did state though that this is possible by downloading that data directly from the OSM website (haven't tried it yet so I don't know yet how difficult it would be). The Mapmask boundary polygons I didn't manage to download because of this issue are - Petah Tikva, Rehovot, Ramat Gan, Netanya, Beer Sheva, Rishon LeZion, and Haifa. (Wrh2 and Andrewssi2 - if possible, please try to create Mapmask boundary polygons for one of those city articles, just to prove that it is possible).
As Andrewssi2 indicated above, When using both JOSM and the Wikivoyage Mapmask conversion tool, it isn't always capable of converting the polygon correctly - Andrewssi2 stated that this only happens when the boundary polygon is too complex, but as of now I am not really convinced what causes the conversion to fail. The Mapmask boundary polygons which the Wikivoyage Mapmask conversion tool failed to import because of this BUG are Herzliya and Eilat. (Wrh2 and Andrewssi2 - if possible, please try to create Mapmask boundary polygons for one of those city articles, just to prove that it is possible). ויקיג'אנקי (talk) 02:09, 13 February 2016 (UTC)[reply]
Hi ויקיג'אנקי , I was able to create a MapMask that I believe is correct for Petah_Tikva. Can you check and verify?
I used this relation, removed some of the 'blue dots', and then used the "Combine several ways into one" button to simplify the outline.
I think the problem with JSOM is that it is tool a tool intended to create new content for OSM, and not really intended to extract and simplifying existing content. That makes it a bit unwieldy.
Interesting. Andrewssi2, I will try the method you mentioned as well and see if I can replicate it with Petah_Tikva. Please try the one for Eilat as well (the bug with the conversion tool, which seems to happen every singe time with Eilat's Mapmask boundary polygon, bothers me much more). ויקיג'אנקי (talk) 04:03, 13 February 2016 (UTC)[reply]
ויקיג'אנקי I used your relation above. Can you have another look?
If you download this Relation and click the 'Validation' button, you will notice there is a 'Polygon Incomplete Error'. This will result in a corrupt boundary. If you click the error it will take you to the point where the boundary is incomplete. You can simply 'connect' the missing points with the 'Draw Nodes' button. Does this help? --Andrewssi2 (talk) 06:14, 13 February 2016 (UTC)[reply]
Andrewssi2, I fixed the 'Polygon Incomplete Error' using the 'Validation' button, neverthelss, it still isn't capable of producing the polygon when I use the GFX in the conversion tool (polygon appears "broken"). ויקיג'אנקי (talk) 06:38, 13 February 2016 (UTC)[reply]
Try deleting the 'blue dots' around the red boundary. Did you also "select all" and click the "Combine several ways into one" button? (As you can tell, this is a rather difficult tool to use when the data in OSM is not so clean) Andrewssi2 (talk) 10:02, 13 February 2016 (UTC)[reply]
Andrewssi2, you mean the "Combine Way" button - yes I have tried that and it doesn't always work (although many times it is necessary because the different ways aren't combined into one polygon). I have found a workaround way though ! in order to make it work in those instances in which the imported polygon "breaks" no matter what, the foolproof solution is to (1) first display the imported city polygon, then (2) display on top of that the "Bing Aerial Imagery" (under "Imagery") and then (3) create a new layer in which you create a NEW polygon by tracing exactly the imported polygon's path (and afterwords save this layer, when only it is displayed, as a GPX file, which you convert to mapmask using the GPX track to mapmask tool). This works every-single-time, and isn't too hard to do. ויקיג'אנקי (talk) 18:33, 13 February 2016 (UTC)[reply]
I recently added the nightclub Tulisuudelma to "Drink/Nightclubs" and the event Winter Carnival to "Do" in the article Vantaa and Northern Helsinki. I added the exact same coordinates to both, as the event actually happens in the nightclub, but the nightclub hosts other events too, and also functions as a general drinking and partying establishment. As a result, the map shows the orange "+" sign no matter how much I zoom in. How should this be handled? JIP (talk) 21:41, 24 January 2016 (UTC)[reply]
This is a common problem for locations that span multiple categories (eat/drink/do etc). You can try and get two sets of coordinates at the extreme sides of the location in question and see if that looks better. Andrewssi2 (talk) 21:51, 24 January 2016 (UTC)[reply]
Since the listing in Do says "at the nightclub Tulisuudelma (see section Nightclubs below)", I would probably just delete the co-ords from the listing in Do. Nurg (talk) 06:01, 25 January 2016 (UTC)[reply]
I find the solutions suggested by Andrewssi2 and Nurg a bit... well, they are workarounds. If you assume Wikivoyagers who pose questions in the Pub are probably more advanced than the average casual user, and you consider that, within less than a week, at least two of us (JIP and I) have been baffled by the "+", it would be nice to fix this problem. Instead of "+", I would like to see a composite symbol with all of the numbers. That would, of course, require a change to the WMF Labs mapping program. A more local solution could be for our Listing and Marker templates to create that composite symbol, but that would be problematic, because the merging of points that are not quite in the same location should go away at higher zoom levels. Peter Chastain (talk) 14:35, 25 January 2016 (UTC)[reply]
I, for one, see nothing wrong with the "+", as long as it keeps grouping coordinates that are actually different, but differ too little for the current zoom level to be able to differentiate between them. But if the coordinates are exactly equal, the final (closest) zoom level should show them as different. But as User:Nurg said, the listing already says "at the nightclub Tulisuudelma (see section Nightclubs below)", so I guess I'll go and delete the coordinates. This raises an additional question: I added coordinates to Helsinki for the Helsinki Samba Carnaval and the Helsinki Pride parade. Parades move. They don't keep the exact same coordinates the whole time. I resorted to adding coordinates to the most central place to view them at. Is this OK, or should I delete the coordinates? But if I do, the articles won't show where in the city they are held, only tell that they are held pretty close to the centre. JIP (talk) 20:00, 25 January 2016 (UTC)[reply]
In such cases I always put the points at slightly different places (but still inside the building). Low tech but it solves the problem of infinite +. Syced (talk) 05:37, 1 March 2016 (UTC)[reply]
Do we have an instructions page for creating / using GPX?[edit]
I noticed that the German WIkivoyage uses them a lot, storing them at ArticleName\Gpx. I noticed that the dynamic maps in all Wikivoyage editions are capable of reading those routes when one stores the GPX data that way (instead of within the actual article. Is it possible to store the GPX data elsewhere (storing that data in locations such as ArticleName\Gpx causes the system to think it is an actual article, and count those pages in the total articles count). Is the GPX format a standard common format used to add custom made maps in modern GPSs? ויקיג'אנקי (talk) 16:43, 24 February 2016 (UTC)[reply]
And here's how I do. For routes, like in Trans-Siberian_Railway#Go I use the GNUHER tool mentioned, then create a new page called Template:GPX/[The exact name of the article] and copypaste the code there together with the Wikivoyage header (Example). If you have a mapframe in the article, the route should now be visible there.
Borders for areas can be made with some similar tools. But if you're lazy and untechnical as I, click on a dynamic map where you want to have each waypoint and copypaste the coordinates to a text editor. Replace the lat= long= things with | and commas, wrap it in to a mapmask tag and just put it in the article like here and then the map should look something (like this) ϒpsilon (talk) 19:01, 24 February 2016 (UTC)[reply]
Thanks to the amazing work by JGirault (WMF) (talk · contribs), the new <mapframe> and <maplink> maps on English Wikivoyage now support external layers and all other wikivoyage article links just like the wmflabs-based maps! I saw some cool maps experiments done by Matroc (talk · contribs) on their page, and copied a portion of it above. I will now try to adapt current community's templates (without modifying the originals just yet), so that the {{see}} and others can be used directly with the new map. As always, feedback is highly welcome. --Yurik (talk) 19:25, 17 May 2016 (UTC)[reply]
Thank you!Yurik - Adding the external layers has made that map look 100% better... - It is also very nice to allow multiple maps on an article page (definitely something various users wanted) - The hard part will be to adapt current templates to go probably through some POI script. - Some of the maps on my home page were created using a Lua Module and data from Wikidata, saved and then edited... I am sure there is more to come that will make life easier and cause little code confusion - again, Thank you for these milestones and your hard work. -- Matroc (talk) 22:39, 17 May 2016 (UTC)[reply]
P.S. Take a look at the first migration attempt. I only changed the underlying templates, and left the page same as original. Some minor styling is still required, plus at some point I hope it will be possible to add an item from Wikidata. Feel free to modify it if needed. --Yurik (talk) 06:24, 18 May 2016 (UTC)[reply]
Some remarks:
There seem to be two full screen buttons (one top-right and one below the +/- buttons).
The layers-button shows "Mapquest open" and just "MapQuest". This last one displays nothing (when zoomed in).
When using the top-right "Full screen" button, the map is displayed full screen. However there is no indication about how to leave the full screen mode.
Alexander, those layers are exactly the same functionality as exists at the moment at Wikivoyage, so it was simply copied from the wmflabs that was created by the community. This data is not under WMF control, and moreover, users have to agree to expose their browsing activity to the 3rd party. --Yurik (talk) 19:21, 23 May 2016 (UTC)[reply]
Very interesting. Can this display type-specific or map symbols for points of interest, like our current fork-plate-knife for eateries, martini glass for drink and house for lodging? Do we have control over what's displayed in the pop-up bubble when the POI's are clicked, perhaps using a template? If a {{listing}} has a corresponding Wikidata item, can clicking the POI marker trigger a lookup to display information extracted from the item? K7L (talk) 15:04, 18 May 2016 (UTC)[reply]
Yuri can correct me on this, but I believe that the default icon set we have available at the moment is the public domain licensed Maki icon set made by Mapbox. As for pop-up content, templates can be included (see my goofy mockup), but I'm not sure on the Wikidata part. Yurik! :) CKoerner (WMF) (talk) 18:57, 23 May 2016 (UTC)[reply]
At the moment we can only show pushpins with any of the maki icons as Chris mentioned above, in 3 different sizes and any color. Eventually I hope we will be able to show other marker symbols, but sadly for the moment that's the limitation. --Yurik (talk) 19:21, 23 May 2016 (UTC)[reply]
The button called "Show in full screen" actually is a button that shows all POIs, I guess the button's name should be changed to "Show all listings" or something similar? Thanks a lot :-) Syced (talk) 06:36, 19 May 2016 (UTC)[reply]
Syced, It does not show all POIs, it shows all Wikivoyage articles. I think we should hide all other layers when the user clicks that button to reduce confusion. --Yurik (talk) 19:21, 23 May 2016 (UTC)[reply]
We have fixed a number of internal bugs, and I think it is ready for the roll out. Are there any objections if I switch the marker & map templates to show it like on my test page? (Note that the color of the links does not match the one on the map for the next 12 hours, after which it will be identical). The new map will allow far greater customization by the community, and will allow us to progress further. Obviously I will be listening to any feedback and suggestions. Thanks! :) --Yurik (talk) 02:08, 8 June 2016 (UTC)[reply]
I say go ahead. Switching to a new framework with greater support and flexibility should be a win for everyone. -- Ryan • (talk) • 02:27, 8 June 2016 (UTC)[reply]
Both >maplink< and >mapframe< can be configured to show just selected groups
Each maps on the same page can be configured to show different group(s)
By default, the {{mapframe}} shows these groups: mask, around, buy, city, do, drink, eat, go, listing, other, see, sleep, vicinity, view (in that order)
Setting text="" for <maplink> does not show the link, but still adds link's data to the specified group (this is what's used by mapmask template)
maplink - if you use text="" or text="Click me!" and marker-symbol is -number-xxx you will get back-ground color (marker-color) a small colored space or the text with that back-ground color.
if no text parameter is entered and marker-symbol is -number-xxx then you would get numbered box with back-ground color. (you can use the <sup> before the maplink and </sup> as well is you wish for a different appearance..
maplinks of the same group will appear when you select "Click me!" and not just the single entry. This is one way to have multiple locations shown on a single map when selected that might not be otherwise shown on a visible map or a grouping of significant or special grouping.
if text="" is entered and marker-symbol is not -number-xxx then geographical coordinates will appear as link.
maplink - if you use marker-symbol such as -number-see (used for common listings see,sleep,go etc.) - it will offset all the numbers displayed in those visible listings on a page that use that same group counter. (Be careful)
maplink - if you use a maplink containing the same coordinates and also a member of a common group (or same group ie. see) - it will overlay the symbol on top of the normally numbered one such as created by a listing. (depends on order of listing or maplink entry)
using <mapframe> and <maplink> - if you want a different symbol on a distinct map then that is also possible using maplink. This can be done by using such symbols as a bed for sleep or knife,fork and spoon for eat and a suitcase for next instead of numbers. The basic trick is to keep track of the group name (I prefer a disctinct group name) you want to display on a map and keeping those groups distinct from the normal ones.
maplink - one advantage to using the maplink description is being able to add an image, adding more descriptive text, shutting off the link to commons and use of alt field. - another is to be able to add something to a map that is not normally found in listings. This added information allows for a slightly different, informative and useful map.
maplink - these can be separate by themselves or the same effect can be by using a number of features within a single mapframe.
I have tested several of the items discussed above HERE decided to pass this on. To create all maplinks that are not seen on that page, I ran the page through a module test function looking at listings and created the maplinks. I also did some minor editorial work.
@Yurik: Tested \" comes out fine in <maplink> description - was just reading up on the escaped characters that JSON uses: \",\b,\f,\\ etc. - Thanks! -- Matroc (talk) 05:36, 12 June 2016 (UTC) - ps Thanks for closing the ticket![reply]
At this time Mapbox icons are available marker symbols and Maki icons have not replaced Mapbox icons yet for <mapframe> & <maplink> - Matroc (talk) 22:02, 11 June 2016 (UTC)[reply]
I presume you mean that Mapbox has released additional maki icons, and the new ones have not yet been made available? --Yurik (talk) 03:20, 12 June 2016 (UTC)[reply]
If you use <maplink> with a description but no image - the text will come out in an ugly narrow width grayed out area... to overcome this use a blank image with a height of 1 px before the description -- Matroc (talk) 00:28, 12 June 2016 (UTC)[reply]
@Matroc: Please file this as a bug, with the extact geojson or template invocation showing how to produce it. Also, please check if it works if you also set the geojson's "title" value. --Yurik (talk) 03:20, 12 June 2016 (UTC)[reply]
Be careful, test and enjoy! There should at some point be a good discussion as to when to use <mapframe>, {{mapframe}}, <maplink> and {{marker}} -- Yours Matroc (talk) 04:17, 10 June 2016 (UTC) --Yurik (talk) 13:18, 9 June 2016 (UTC)[reply]
@Matroc: I am a bit worried about too much magic in the params. I think we should change it to a bit more direct and straightforward way, especially with when things get autostyled (colored), hidden, etc. A better design is welcome :) --Yurik (talk) 05:47, 10 June 2016 (UTC)[reply]
@Yurik: I agree and that is why I thought that we should all discuss and maybe come up with a possible set of polices for wikivoyage - (develop Help pages, dos and donts, and how to keep this as simple as possible for all editors/users). -- Matroc (talk) 06:29, 10 June 2016 (UTC)[reply]
Dear community, this week we launched geoshapes service. So if Open Street Maps community has defined a region and assigned it a Wikidata ID, you can draw it on the map with that ID. Or you can use Wikidata Query Service (via SPARQL language), to query for those IDs and draw them on the map, coloring them and adding popup information. See documentation.
<mapframe>: Couldn't parse JSON: Control character error, possibly incorrectly encoded
P.S. We also enabled <maplink> support on all Wikipedia and sister projects. Our next big step is to add an informational sidebar to the map, similar to what is being shown on the "geohack" page (map link in the upper right corner of most location articles). Check out proposed screenshots.
@Yurik, Matroc, RolandUnger, Mey2008, Atsirlin: Tonight I have been playing with the new geoshapes/Wikidata/geomask implementations and I'm hugely excited about the possibilities - see User:Wrh2/Maps for some examples. I put copies of Module:Map and Template:Mapframe into my userspace and hacked them to use the new features, but I'm not very knowledgeable with Lua, nor do I have a strong understanding of the Kartographer extension, so I'm hesitant to attempt a non-hack for the "real" template and module. Is anyone working on getting these new features implemented into the existing module & template? I think it would be amazing to allow map borders imported directly from OpenStreetMap and would love to see that functionality available sitewide, and while I'd be willing to work on putting the needed changes in place, I'll happily defer to someone who likely knows far more than I do about how best to do it. -- Ryan • (talk) • 05:02, 15 November 2016 (UTC)[reply]
@Wrh2, Yurik, RolandUnger, Mey2008, Atsirlin: - That looks really good to me! All I know is that Yurik et al. have been swamped. I think Yurik is the one that has been working very hard on the various templates and Module:Map. In addition, he has been working on the GPX information found in the GPX templates and storing them on Commons with the idea to incorporate that information into various maps in an efficent manner. As far as Lua goes - I am a novice!. As an aside, I have been working on an interim hack Module:Mapdraw that allows one to draw circles (and several other shapes) and put their respective polygon info (GeoJSON?) into maplinks that then could be displayed on a map. If interested you can see these examples. The only shape that we in general in wikivoyage might use I expect would be circles as Kartographer does not have method to draw circles. (That function might be added to the Map Module). I am glad you are excited about future prospects and your examples are awesome as far as I am concerned. -- Matroc (talk) 05:49, 15 November 2016 (UTC)[reply]
I'm hopeful someone else can implement a better fix, but here's my attempt to add wikidata support to the existing templates (test versions currently):
From my limited understanding I think that these updates should be safe, although there is probably a better way to implement them, so feedback would be much appreciated. -- Ryan • (talk) • 03:25, 16 November 2016 (UTC)[reply]
Yes, that's the great feature! Unfortunately, I can't really comment on the module implementation. Rather I have a (very naive) question. Suppose that I want to use the same mask for all maps displayed on the page, but I want to define this mask only once. For POIs I define, for example, group="see" and then call it as show="see". How can I do the same thing for the mask? @Yurik, I bet you know the answer. --Alexander (talk) 15:14, 17 November 2016 (UTC)[reply]
I think I resolved my own question. One should assign the map a group name (for example, group=mask) and call it this name in all other maplink and mapframe commands. --Alexander (talk) 15:28, 18 November 2016 (UTC)[reply]
One problem with storing the region boundaries on OSM: Wikivoyage tends to split provinces and states into subregions in manners which don't follow any official political boundary. There's a legal definition of New York State as a geographic entity, but who decides where some arbitrary sub-provincial region like Central New York ends and some other region in the same state begins? Each WV language has been reaching its own consensus on this, so the boundaries for Seaway Region and the like need to be stored locally. K7L (talk) 04:36, 22 November 2016 (UTC)[reply]
Make subway/train lines more prominent in dynamic maps[edit]
Two subway lines cross at Roppongi station (also serving some neighbouring stations that some might find more convenient) but they are not visible on the map unless you zoom to house-level (and even then, they are masked by any street that happens to run above))
How about making subway/train lines more visible? Tourists tend to use public transport more than the locals. This is especially true for big cities and countries like Japan (but I guess we can't have per-area map styles). Thanks!Syced (talk) 06:03, 20 September 2016 (UTC)[reply]
I absolutely agree with that. I noticed this issue when looking up stuff for a trip to Seoul (Seoul/Jongno) and Busan (Busan/Central) and found it quite annoying to have to switch between the dynamic map with all the sights and the subway map with just the station names. Drat70 (talk) 06:36, 20 September 2016 (UTC)[reply]
Great idea. Most major Chinese cities would definitely benefit as well. I would still employ the caveat that it should be used on destinations with a well defined metro system (Tokyo, Seoul, London, Shanghai, etc). --Andrewssi2 (talk) 06:45, 20 September 2016 (UTC)[reply]
I like the idea too, but just wanted to raise the potential problem of light rail lines. In Germany and France there are many cities without a subway that have light rail lines that are almost as fast and frequent as subways are in other cities and they are also heavily utilized by tourists. Hobbitschuster (talk) 12:56, 20 September 2016 (UTC)[reply]
The layer "traffic line network" shows all the public transport lines. Railways, subways and buses, etc. Including line numbers and stops by name. -- Joachim Mey2008 (talk) 04:47, 21 September 2016 (UTC)[reply]
Syced, sorry for being late to the conversation. I brought this issue up to the Maps team and created a task to track this request. It doesn't sound like something we can get to immediately as there's a sizable amount of technical work involved, but it is on the radar of the team. More examples and feedback are welcome. CKoerner (WMF) (talk) 21:44, 30 September 2016 (UTC)[reply]
If a static map exists, instead of displaying it as an alternate where dynamic map support isn't available (print? no JS? whatever?) both maps are always being displayed. Trans-Labrador Highway does this when it used to display the dynamic map as primary and hide the alternate (static) map.
Matroc, K7L, ϒpsilon, take a look at the proposed technology for centrally storing GeoJSON data and reusing it in multiple mapframe/maplinks. [13]. I think it should provide a much better alternative to the current GPX/KML storage. Let me know what you think. --Yurik (talk) 05:05, 8 November 2016 (UTC)[reply]
It will make it somewhat easier when it comes to making routes without having to type out all the coordinates. As far as geoshapes go, I would imagine the code to retrieve the GeoJSON information will be similar to what we would do now for geoshapes from OpenStreet... Just a minor question. Would we be able to change the fill color, opacity, stroke-color and stroke thickness, add a description etc... The example you displayed has many geoshapes. One might want to change the fill color of Harlem for example. The overall stroke thickness is a little bit thick. If not, would one then have to use the output as is. On one hand I still think some understanding of coding would be useful, but at a minimal level I hope. It is definitely a step in the right direction. Thanks! .. Matroc (talk) 06:26, 8 November 2016 (UTC)[reply]
Matroc you can already change that using properties object on all features, e.g. "properties":{"fill":"#bd0000"}. See simplestyle at Kartographer help page. --Yurik (talk) 07:11, 8 November 2016 (UTC)[reply]
Yurik - Good! So pretty much the same type of action is going to occur as with mapshape and OpenStreet. Just wanted to make sure that one still could make minor changes. Having a centralized GPX/KML storage in commons for multiple wiki use is good idea! -- Matroc (talk) 02:52, 9 November 2016 (UTC)[reply]
Wikivoyage:How_to_use_dynamic_maps#Adding_boundaries_and_tracks. First I go to [14], and click on the map where I want to have route points. When the route is done, I click save and I can download a textfile to my computer with the coordinates and "everything else". After this I create a template page named "Template:GPX/exact name of the article the route is for" (e.g. Template:GPX/Trans-Siberian Railway), copy paste the content of the text file I just downloaded and click save. That's pretty much it.
The question is how we going to store it. Storing DATA as not-easily-parsable wiki text is a really bad idea - there is no validation nor an easy way to use it from code (like mapframe). You have to build complex and error-prone lua scripts to parse that text, and constantly fix errors. Storing it as geojson removes all these problems, because the data is validated on save, and does not save until the errors are fixed. Plus there could be many easy to use additional ways to validate that data, and some options to convert it to KML/GPX/... formats if needed. Worst case - the data can be copy/pasted to a number of sites that will do it. --Yurik (talk) 02:58, 9 November 2016 (UTC)[reply]
Maps broken when there are no listings with coordinates[edit]
@RolandUnger, Yurik, Andyrom75: Recently I've noticed that maps render as an empty frame on articles where there are no listings with lat/long coordinates - see for example Marshfield (Massachusetts). I'm using Chrome 53.0.2785.143 on Windows 7, and the error in the Javascript console does not seem particularly informative: "Uncaught SyntaxError: Unexpected token u in JSON at position 0". I've disabled all code in User:Wrh2/common.js and still see the problem, so I don't think it's due to any customizations, but it would be helpful if someone else could check the Marshfield article and indicate whether the map renders for them or not. -- Ryan • (talk) • 07:07, 24 October 2016 (UTC)[reply]
We have seen this problem too (in Russian Wikivoyage). I think it is browser-independent, or at least appears in both Chrome and Firefox. --Alexander (talk) 07:09, 24 October 2016 (UTC)[reply]
In it:voy we do not use the new map because of the limitation on the number of POI showable in one map (on top on others bugs), so I haven't experienced before this issue. By the way, I confirm you that I cannot see that map in my browsers. I haven't tried with iPad, but I think that the problem will occur there as well. --Andyrom75 (talk) 09:17, 24 October 2016 (UTC)[reply]
This behavior is due to a bug in the Kartographer extension. All the marker data are stored after code parsing in the document head in the wgKartographerLiveData variable. If there are no marker data senseless data were stored which are no valid JSON code. That's why you get the "Unexpected token" error message. To solve this problem I opened a phabricator task and attributed it to Yurik and JGirault. --RolandUnger (talk) 14:43, 24 October 2016 (UTC)[reply]
Hi everyone, we had no deployments last week, but were very actively working on the code and fixed a number of data bugs. I tried to replicate phab:T148971 on this page at beta cluster and it seems to be working, so I suspect we have already fixed it, and it should be deployed to all Wikivoyage servers on Wednesday. Beta cluster always contains the latest version of the code, making it a good place to experiment. --Yurik (talk) 15:08, 24 October 2016 (UTC)[reply]
I also have this issue, especially when the OSM contributor has created a very large and detailed map with additional features. Ultimately we just need very simple ways (clarification: a 'Way' is a polygon area used in OSM) is to illustrate areas on Wikivoyage. --Andrewssi2 (talk) 09:26, 14 November 2016 (UTC)[reply]
I see the same thing as Andrewssi2, it appears that there is excess information and not just a simple polygon. I noted there were nodes for a few cities?, multiple segments and possibly other map information - when all put together may cause this problem. One would have to be able to select only the pertinent map segments to create the polygon. -- Matroc (talk) 17:48, 14 November 2016 (UTC)[reply]
I tried deleting items one by one from the OJSM but the problem persisted to the end. Granted, I am very new to this software and 99% of its options are arcane to me, so maybe I was not deleting the right things. But at the very least, in the present form the tools are unusable by 99% of the potential users. We need to simplify them (or write better instructions) so that layman can handle them. As a note, I've been teaching my students how to edit wikis and contribute to Wikivoyage, and they think the maps are cool, but we are unlikely to use MapMask, as nobody in the class can figure out how to generate error-free maps, at least reliably. I hope someone here can figure out a solution, if not right now, then hopefully by the time I teach this class again next year :D PS. We were able to fix some simple errors (a square in the map) by deleting the city name / dot from the very center of the map. Maybe that will help someone, as it does fixes at least some of the errors we encountered. --Piotrus (talk) 03:09, 15 November 2016 (UTC)[reply]
The other option is just to create your own boundaries! Many of the boundaries defined on OSM have a very granular level of detail (down to a meter) which can throw off our map mask. However a map mask is nothing but a sequence of Geo coordinates, and you could define your own if the region is relatively easy to define. Andrewssi2 (talk) 05:33, 15 November 2016 (UTC)[reply]
Btw, I just noticed that Wikipedia maps are different from ours, and they work better. Well, they work for Katowice, not for Chuncheon. I guess we use a different system because we want to interpose our own locations...? --Piotrus (talk) 06:44, 15 November 2016 (UTC)[reply]
User:Zerabat - The Mapmask for Wonju has 900 coordinates that are used to build a polygon around Wonju - a few groups of coordinates are out of order (sequence) thus the map looks the way it does - Once in sequence it should be fine. -- Matroc (talk) 02:31, 6 December 2016 (UTC)[reply]
Piotrus - The Mapmask for Chuncheon has 1212 coordinates that are used to build a polygon around Chuncheon. A few groups of coordinates are out of order (sequence) thus the map looks the way it does. Once in sequence the map should be fine. -- Matroc (talk) 03:01, 6 December 2016 (UTC)[reply]
I built a test with all the coordinates as markers for both Wonju and Chuncheon and could see that the coordinates were out of sequence in both cases. -- Matroc (talk) 03:01, 6 December 2016 (UTC)[reply]
@Matroc: Thank you for figuring this out. Is there an easy way to fix it? Perhaps we could write some user script that would reorder the numbers in the correct fashion? --Piotrus (talk) 03:08, 6 December 2016 (UTC)[reply]
I doubt that a script could be written to put them in correct order as coordinates can go all over the place - up, down, left and right etc. though an interesting idea. The only way I can think of is to walk one's way through it and eyeball each coordinate which might be somewhat frustrating to do. When I have some time on my hands I will see if I can find which ones are out of order (sequence). -- Matroc (talk) 03:31, 6 December 2016 (UTC)[reply]
@Wrh2, Yurik, RolandUnger, Mey2008, Atsirlin: et al. - Has the Kartographer Extension / Javascipt been modified? Perhaps someone should take a look at it again.
The samples are pretty much the same from the Kartographer Help page on Mediawiki.org.
Is this a new direction - we are now having a Q with link to a map appear - How do we get rid of and/or use that Q.
<maplink text="click me" zoom="13" longitude="-122.3995" latitude="37.8103"/>
When text is "click me" example - click me becomes a link as before - but I question why data that is enclosed with code and nowiki getting interpreted also. (Parsing the page maybe?) Why the Q?
Matroc, it's not a "Q", but a map pushpin, just like you have one in Facebook and many other sites to indicate that the link is a map link. The related discussion is at phab:T145176#2784036. We had to enable it because it was very confusing for the users to see a link which wasn't really a link but a popup dialog. The easiest way to turn it off is to set class="no-icon" attribute on the <maplink> tag. I think we shouldn't generate anything when the text is set to "". Tracking in phab:T150922. The #3 and #4 are by design. The #1 (fixed) was due to having text="". Removing it restores auto-number generation. If the "marker-symbol" is not set to either "-number-*" or "-letter-*", the link is treated like a regular link, using the "text" attribute's content. The <nowiki> was misspelled - i fixed it too. --Yurik (talk) 02:08, 17 November 2016 (UTC)[reply]
Thought that was a Q - I am overdue for new glasses! - I corrected my sample test pages as well. Thanks for checking into this - sorry to be such a pain. I hope I am at least contributing in some small measure. Thanks again - ps. Did you get to take a look at Wrh2's work on Module:Map and Template:Mapframe (see above) -- again a big Спасибо -- Matroc (talk) 05:59, 17 November 2016 (UTC)[reply]
@Yurik: Yesterday I added the class parameter to the {{Maplink}} template because it is used by {{Mapframe}}, too (with no-icon class). But it was a little bit frustrating to have an unexpected behavior without any announcement. It took some time to learn what happened. By the way it would be nice if the maplink call like would work with the real Maki icons instead the simple pushpin. --RolandUnger (talk) 16:50, 19 November 2016 (UTC)[reply]
@Yurik: Some weeks ago I added a small "Enlarge icon" to the mapframe like for thumb images. It opens a map with a zoom level increased by 1. Maybe this feature could be added to the Kartographer core. --RolandUnger (talk) 17:03, 19 November 2016 (UTC)[reply]
Hi @RolandUnger:, do you mean make to wrap the maki icon into a different style "pushpin" (e.g. a circle), or is it to simply have maki icons themselves interactive on the map (similar to how Google maps does it)? The first (phab:T131618) is fairly difficult to implement due to technology limitations, but we do want to address it once we upgrade the internal data pipeline and switch to WebGL maps. The second is somewhat different entirely - you usually don't want to blend the generic map information (something available on every map) with the information relevant only to the current article. Anything article-specific should stand out from the generic map background. It would inform the user that there is some extra information available if clicked. We do want to make the map more informative in general, e.g. more POI information, possibly even clickable, but we should balance that with the desire to make the map less prominent, more bland, so that article-specific information would stand out. This also implies that drawing maki icon without the pushpin frame might blend in. I am very sorry about not communicating the maplink indicator more widely - we went though many iterations of the feature, and were almost certain the existing links would not change, but as always, there was a case when they did :( A better announcement would have helped too. Lastly, could you give me an example of the "enlarge icon" feature? It might be useful to add it for everyone, but I would like to see it first :). And as always, please keep the comments coming - it keeps us on our toes :) --Yurik (talk) 18:06, 19 November 2016 (UTC)[reply]
The hiking layer was used on Milford Track and some other walking itineraries, but at present layer selection on the page (rather than the reader selecting it) is not working. The Milford Track page has Mapframe|-44.850|167.834|zoom=11|layer=RH, but this just displays a standard Wikimedia map. AlasdairW (talk) 21:59, 21 November 2016 (UTC)[reply]
I think the section on filling in gaps in OSM's coverage needs a warning about following OSM rules on allowable sources. I'm particularly concerned that it suggests adding names without mentioning the need to actually survey on the ground, or use sources with an acceptable licence. However, even the reference to satellite imagery could mislead people into violating third party rights, as much "satellite imagery" is actually from aircraft, and only specific such images can be used (not even all the images from Bing can be used). Even true satellite imagery, except for that from NASA, may not be acceptable.
Is this an issue for Wikivoyage in particular? For the most part we are fairly passive users of OSM, not active contributors. AFAICT this project page doesn't even discuss contributing back to OSM --Andrewssi2 (talk) 21:50, 2 April 2017 (UTC)[reply]
SPARQL - geoshapes and Pages with broken file links[edit]
If one uses SPARQL and is creating File via concat, this appears to place the page in Category:Pages with broken file links.
(concat(?stateLabel, '\\n', '[[File:', substr(str(?img), 52, 100), '|200px]]') as ?description)
FYI - I discovered this when using a function in a Lua module that I use to find and fix broken file links on a page. This I believe produces a false-positive. Probably someone may have to check wiki coding that produces that Category page??? -- Matroc (talk) 03:30, 4 April 2017 (UTC)[reply]
I was trying to use a normal mapframe with layer=W then adding a C (to the layer to include the transparent cycle layer to show the cycle route on the map. But whatever I did the C was ignored and playing around further it seemed that the entire layer= parameter was being ignored. However, if I click on the layers button in the resulting mapframe and select the cycle layer is shows just as expected - so the cycle layer works, just I seem unable to get it included in the mapframe. Am I doing something wrong or is it "broken"? (I did search out the documentation from the help and tried pretty well everything) PsamatheM (talk) 16:06, 9 April 2017 (UTC)[reply]
I believe layer parameter was changed and W is the default - other layers can be selected using the layers button. Hopefully this will be confirmed to avoid confusion for me and others as well -- Matroc (talk) 01:04, 15 April 2017 (UTC)[reply]
The button seems to work to select other layers. Just in some cases it is appropriate to add layers to be displayed automatically (by default for the particular mapframe). I was hoping to include the cycle track on a mapframe by default (in the specific case, there was only one significant cycle track marked (or rather needing to be marked) and things make a lot more sense if the map could include it by default rather than the user needing to start pressing buttons and selecting appropriate layers. And thinking about it there is another place where having a map showing footpaths would be great as well (paths that are discussed in the "Do" section of the destination page. Having them show as determined by the page means one can "geo locate" them or rather a location lat and long would make more sense when pointing to something rather than pointing to the middle of nowhere. PsamatheM (talk) 08:50, 15 April 2017 (UTC)[reply]
Hi all, I have created a gpx-track for a sightseeing tour around Hpa-An in Myanmar and uploaded it to the template page. But shomehow when I try to download the gpx for Hpa-An the track is not included. Do I have to be more patient or is there a technical problem? Thanks.
-- User:Renek78 10:31, 23 April 2017
Patience won't fix anything. Template:GPX/...whatever... was permanently broken by replacing our old map system with mw:Extension:Kartographer. Furthermore, it wasn't ever intended as a means to get the track into the GPX download, but merely as a way to draw the track on the {{mapframe}} map.
I believe I created the Trans-Siberian Railway GPX for the {{mapframe}} using <maplink> (found in Next section). A route can also be created directly in a <mapframe> which may be the preferable method. (see talk page Trans-Labrador Highway). The {{geo}} template uses as far as I can tell the actual {{GPX}} template tile. Yup, it is all still in a bit of flux.
As far as Conversion of GPX to GeoJSON - my experience has been somewhat limited to using a text editor while looking at the formats.
Documentation is sparse, scattered and rudimentary in places and its easy to get lost (frustrated) as well as the several nuances that may exist to compound the situation.
The idea is to eventually have these <mapframe>s stored in Commons so that the data is in one location . Yurik did take GPX template files and converted them (see Yurik/Sandbox/GPX1 and GPX2) and I had corrected a few. -- Matroc (talk) 05:53, 24 April 2017 (UTC)[reply]
Downloaded the GPX file using Download GPX for this article button for Hpa-An and it has coordinates for multiple locations or points, it did not have GPX coordinates for the Day Trip route; however, the template {{GPX/Hpa-An}} does have the coordinates for drawing of the route. Anyhow, I converted it and created a <maplink> and put it on your page in the Go Next section -- You can edit or remove it if not to your liking. -- Matroc (talk) 08:33, 24 April 2017 (UTC)[reply]
Hi Matroc, this is a nice workaround. It would actually be close to perfection already, if this track was included in the gpx file, which can be downloaded via Download GPX for this article. Because that's what it's all about. A traveller, who is interested in this trip needs to get it to his phone/GPS device somehow. Thanks for your support! --Renek78 (talk) 20:09, 24 April 2017 (UTC)[reply]
Yes I agree. In the case of Hpa-An there is an issue of sorts with the downloadable GPX file and will hopefully be rectified. Putting a route on a map in an article of course is a different matter. -- Matroc (talk) 22:13, 24 April 2017 (UTC)[reply]
Using <maplink> was just a workaround that I came up with some time ago to meet a particular need to produce the Trans-Siberian Railroad routes before a lot of work was done on templates.
K7L all templates mentioned above are useful, viable and still very much valid. {{GPX}} is not to my knowledge defunct. If at all possible, use the templates is my thought.
There still needs to be a definite discussion as to what to use and when as there seems to be no real consensus of best practice(s). The methods I used evolved around testing and using the Kartographer extension directly (not for the faint-hearted). The basic reason various templates were modified/created was in order to avoid a lot of confusion by using that particular extension directly by the casual editor. After all, what do some of these templates do but produce Kartographer output as far as I can see.
I have found in the past that there are many ways to skin a cat. (ie. mapmask to draw a circular route is possible, mapshape can be used to draw a line), using <mapframe> or <maplink> can be used for routes, polygons, multilines, multipoints, etc.) and through some Lua module functions as well and another module that creates various shapes such as stars, boxes, hexagons, polygons etc. So it boils down to a matter of pick your poison. :}
May be time to gather up all the information about maps etc. and consolidate them, reach some consensus, create more how-to examples and perhaps a Request - Question & Answer pages. Traveller's Pub can too easily be filled up with map discussions!
I am not an expert and do not necessarily have the correct answers, I just hope I have added something useful once in a while. -- Cheers! -- Matroc (talk) 22:13, 24 April 2017 (UTC)[reply]
Wikivoyage:How to use dynamic maps#Adding boundaries and tracks needs to be rewritten. It's for the old "poimap2" which expects GPX. If mw:Extension:Kartographer expects GeoJSON, or the method to use the new extension is different from the old one, then what's there now is doing more harm than good as it's only creating user confusion. Following the instructions on that page will not yield map tracks or boundaries. I'd rewrite it, but I only have a very incomplete idea of how to get a GeoJSON track onto a map here. (14:26, 26 April 2017 UTC) I've edited it a bit, not removing anything but shifting the emphasis to creating GPX tracks for conversion to GeoJSON for use in Wikivoyage. It's still a mess, but I believe it's at least factually accurate - though not easy to follow. Hopefully someone else (who is familiar with the templates) will take a crack at it at some point? K7L (talk) 15:43, 2 May 2017 (UTC)[reply]
On that matter, would anyone know whether it be possible to use other ExternalSources than explained in the Kartographer documentation. E.g. I got http://www.gpsies.com/files/geojson/w/v/l/wvlbpblefmwwkkap.js (gpsies ID: wvlbpblefmwwkkap), which would perfectly fit into the Kartographer concept. But I did not find any reference on how to integrate a link into the Kartographer.
It looks as if we're deliberately avoiding hosting maps, layers or traces on non-WMF servers for various reasons, including user privacy. (We have access to OSM data because Wikimedia is hosting a copy of the OSM tiles for our use.) Presumably you would need to copy and paste the GPSies data (assuming it's under some sort of free licence) and place it into <maplink> tags on the local site. K7L (talk) 17:43, 26 May 2017 (UTC)[reply]
Multiple Mapmasks with different colors in one map[edit]
Hope it is okay to ask a technical question here. I would like to create a dynamic overview map similar to the one for Berlin. Unfortunately many cities in the world do not have districts with wikidata items as of now. Thus I have to use Mapmask instead of Mapshape and "draw" the boundaries manually. The question now is: Can I add multiple masks with different colors within one Mapframe by using Mapmask? I played around with the parameters a bit, but without success.--Renek78 (talk) 11:37, 4 May 2017 (UTC)[reply]
Have you looked at mw:Help:Extension:Kartographer? If the underlying extension can do this, that page would say so – the only catch is that it doesn't document our templates as it seems to be assuming that you are calling the extension directly. K7L (talk) 17:56, 4 May 2017 (UTC)[reply]
It is probably best practice to use the available Wikivoyage templates if possible. The Help page on Mediawiki for Kartographer is naturally for using the extension itself. Kartographer is used behind the scenes to generate dynamic maps. The templates work with the Kartographer extension to provide some transparency and hopefully avoid some confusion. Their output is basically Kartographer GeoJSON formatted data (which you don't have to code or edit). The templates usually have a documentation page the should be of some help.
I also have seen instances where a Wikidata item doesn't exist or if a Wikidata item exists and there is no corresponding OpenStreetMap data available to do masks and shapes as well as Wikidata items not matching an article correctly. At times it can be frustrating and hopefully things will improve as time goes along. -- Matroc (talk) 21:31, 4 May 2017 (UTC)[reply]
They look to be storing the boundaries of each region as a template, {{Boundary/Москва/Восток}}, {{Boundary/Москва/Запад}}, {{Boundary/Москва/Север}}, {{Boundary/Москва/Северо-Восток}}, {{Boundary/Москва/Северо-Запад}}, {{Boundary/Москва/Центр}}, {{Boundary/Москва/Юг}}, {{Boundary/Москва/Юго-Восток}}, {{Boundary/Москва/Юго-Запад}}. These are likely called from other templates, not sure which ones. K7L (talk) 02:10, 5 May 2017 (UTC)[reply]
Yes, region boundaries are stored locally (in the Template namespace). Eventually, they should be transferred to the Data: namespace on Commons, such that all projects could use them. --Alexander (talk) 11:14, 5 May 2017 (UTC)[reply]
Hi Renek78, I'm not sure which of the two maps you're referring to, but I caution it's just tests and the process isn't very user-friendly for either one. The Vancouver district map was done by editing the map in the Visual Editor. It has tools that let you draw shapes on top of the map and the editor creates the GeoJSON data (I think it's in a box below the map). Once that's done you can edit the properties in the GeoJSON code to change the colour, border, etc. I find it difficult to make nice neat boundaries with this method and it doesn't show other listings and markers on the page. It also puts a lot of data on the page that other editors will need to scroll through when they edit that section. You can get around this by setting up templates like Atsirlin mentioned, but I don't know if those templates exist on English WV.
For the Oregon Coast map, I was testing out the Data page capability in Commons, where, if you have the GeoJSON data, you can store it in Commons and then call it up to display on a dynamic map in another Wikimedia project. It works -- I created pages that store the boundary definition for each region I was testing and then displayed them on a dynamic map on WV -- but there's no template (at this point) to make it easy, you still need to create the GeoJSON data, and I haven't found a way to get it to display other markers like our dynamic maps currently do. If you want to experiment, I'm happy to try to answer any questions, but it's still a work in progress. -Shaundd (talk) 06:26, 21 May 2017 (UTC)[reply]
Alternative is to retrieve the ExternalData for all 3 within the mapframe rather than using 3 separate maplinks by placing them in an object array within the mapframe and assign group="other". (about 7 lines of code) All you need for result is show="city". As usual, who knows what changes Kartographer will have in future and this approach may become invalid. -- Matroc (talk) 03:19, 22 May 2017 (UTC)[reply]
When there are map coordinates of a destination in Wikidata, this is not translated into a correct positioned map, when {{mapframe|||zoom=10}} is used without coordinates. I discovered this with the Chiang Rai page. This destination has in Wikidata the coordinates (Property:P625) 19°54'34"N, 99°49'39"E.
After making the map full screen, the address line in the browser shows:
Here 20.0960/99.8752 (20°5'45.60"N/99°52'30.72"E) are the coordinates of the map center, not the same as the P625 value in Wikidata. On the right side of the displayed map, another value is displayed for the coordinates: 20.0217, 100.0951.
I guess there must be something wrong in the supporting module of the mapframe template.
Any dynamic maps with the Relief Map layer have the caption "API Key Required" on them since yesterday. (see example below - please change the map layer to the Relief Map layer in order to see the caption).
We cannot remove these captions. Thunderforest.com (Open Cycle Map) changed their license policy, anyone has now to use a API key. Now I do not know if can can use other maps. People must have an own account at Thunderforest.com first. The URLs in the past like http://{s}.tile.thunderforest.com/landscape/{z}/{x}/{y}.png must have an addition like ?apikey=<insert-your-apikey-here> but I think we cannot do it for Wikivoyage in general. See also OSM Help Page.
If anyone knows another relief maps source then we can change it easily.
I want to add a <<mapshape>> entry to Akko in place of the <<mapmask>> which is currently used. However, when I try to do this (in preview mode) the shape it uses is totally wrong, it looks like it picks 4 random points from the correct shape to form a quadrilateral, and discards all the other points. What is going on? Ar2332 (talk) 20:56, 19 July 2017 (UTC)[reply]
My guess is OSM just has those 4 points available - if this is the case, OSM data would have to be corrected/created to be used with template mapshape as the first avenue to take. Other more tedious solutions are to take the current accurate coordinates you have and convert them to GeoJSON format and add to the existing mapframe or create a maplink and yet another option is to create a Commons:Data File and call that map file as External Data. -- Matroc (talk) 04:55, 20 July 2017 (UTC)[reply]
I think something like this happened once before with an OSM relation; regrettably, I don't remember the cause or solution -- Matroc (talk) 01:46, 21 July 2017 (UTC)[reply]
Was it an OSM entry last time? I vaguely recall a case like this which was using a manually-supplied list of co-ordinates on which the first co-ordinate pair matched the last one to draw a closed figure. Adding or removing one final point from that local list "fixed" things. That sort of tinkering with data to work around a bug isn't going to be straightforward if OSM is being used as an external data source. K7L (talk) 11:33, 21 July 2017 (UTC)[reply]
Hi all, I added a dynamic map to Saint Petersburg via a maplink to Commons. But there are plenty of "listings" (e.g. embassies) and "do" markers cluttering up the map, which I would like to hide. Normally one can use the paramter "show" on the mapframe. But in this case I don't know how to address my Commons map. "show=maplink" or "=Commons" or whatever all doesn't work. Anyone knows a way? --Renek78 (talk) 12:27, 23 July 2017 (UTC)[reply]
Renek78{{Mapframe|59.92|30.24|30.30|zoom=9|show=other}} - add "show=other" to just show maplinks belonging to group other -- (you can add "|group=other" to your mapframe but is not needed -- Matroc (talk)
Did not find problem - The coordinates appear to be correct as I built a polygon from them with mapframe - I also plotted out the points to check order and that is fine as well ... I agree, something is happening somewhere as this should work... -- Matroc (talk) 04:51, 25 July 2017 (UTC)[reply]
Renek78 - I fixed this mapshape to work by repeating one of the coordinates which in my mind should not have corrected the issue at all - anyhow working! -- Matroc (talk) 06:11, 25 July 2017 (UTC)[reply]
I have been trying to add the top GPX icon+link to all the relevant articles on the Hebrew Wikivoyage without much luck. Maybe anyone around here know how to fix the following issue?
The icon is isn't displayed neatly next to the little map+magnifying glass icon but instead it is displayed above it AND it also affects the banner below which becomes smaller as a result. (See example)
I had the same issue in Spanish Wikivoyage. The issue with the banner appears when there isn't a breadcrumb (in Wikivoyage editions with a breadcrumb above the banner), but it's fixed by adding it. I don't know how to permanently fix this problem. --Zerabat (talk) 03:35, 8 January 2018 (UTC)[reply]
Wikidata Q409036 --> OSM 272078 -- Mapshape/Inner is outputting "| stroke=#00888A, 00888a" for 5th line to be drawn thus GeoJSON error - Issue is the extra 00088a in the stroke parameter. The other 14 pieces are fine... -- Matroc (talk) 03:32, 22 April 2018 (UTC) -- see Talk Page[reply]
Getting this error when copying lat/long numbers from GeoHack to McBride. (Also, the Geomap "find on map" function appears to be broken - all I see is the left-hand menu, no matter which browser or OS I use.) --Robkelk (talk) 01:39, 6 May 2018 (UTC)[reply]
As a result of having the new dynamic maps fully integrated at the Hebrew Wikivoyage, we now have various bugs that need to be fixed.
The one bug that needs to be fixed the most happens When loading any article on Hebvoy that has a dynamic map - the interface always requests that the user would give permission to access an external source (this message keeps coming up on articles with dynamic maps unless the user clicks on "it's okay"). once the user click on "it's okay" the interface displays the map layer "articles nearby" automatically. (example - look for the dynamic map in this article)
I suppose that you call these 'articles nearby' from some template, but I can't say more without knowing which templates are used. This is a bit hard to figure out in Hebrew. --Alexander (talk) 15:48, 19 May 2018 (UTC)[reply]
Another technical question for the map experts[edit]
One of the main features that dissapeared when the new maps were integrated to the Hebrew Wikivoyage was the option to display specific map layers automaitcally when a certain artice loads - for example, for an article about a hiking trails I would usually display the Hiking layer and the Hill Shading layer. These layers do not load automatically anymore when they are defined to do so in the code (example - look for the dynamic map in this article).
If I remember correctly this was an issue raised some time ago. I think that the parameter layer may have became defunct? As an aside, be aware that recent changes are happening and that the code for mapframe and maplink in Wikivoyage is slightly different from that to be found in Wikipedia. ie. group and show is not available and the box to select layers, groups etc. no longer exists and other quirks. The most recent update to the Kartographer extension in Wikivoyage dated May 7 of this year shows that sidebar.js was updated. Hopefully, any future changes to Wikipedia implementation will have no effect on our present capabilities. -- Matroc (talk) 19:19, 19 May 2018 (UTC)[reply]
Matroc - Is there anyone I can ask for help with this? appearntly this feature has not been removed... it actually still works - one can select the Hiking layer or the Hill Shading layer from the side box after the map has loaded, but it simply does not load automatically anymore. Maybe they changed the code so that a different code needs to be entered to display it automatically? ויקיג'אנקי (talk) 20:18, 19 May 2018 (UTC)[reply]
The ability to select a layer using a parameter rather than a button was disabled here a while ago. This was to address privacy concerns as some of the layers used external sources. The button method still works. See Wikivoyage_talk:How_to_use_dynamic_maps#Layers. Unfortunately there has been no interest in just enabling the options that are not privacy concerns, but disabling those (eg Mapnik) that use external servers. AlasdairW (talk) 21:05, 19 May 2018 (UTC)[reply]
or 
map symbols for points of interest, like our current fork-plate-knife for eateries, martini glass for drink and house for lodging? Do we have control over what's displayed in the pop-up bubble when the POI's are clicked, perhaps using a template? If a {{listing}} has a corresponding Wikidata item, can clicking the POI marker trigger a lookup to display information extracted from the item? K7L (talk) 15:04, 18 May 2016 (UTC)
Done
would work with the real Maki icons instead the simple pushpin. --RolandUnger (talk) 16:50, 19 November 2016 (UTC)
