Wikivoyage talk:How to draw static maps

From Wikivoyage
Jump to navigation Jump to search

Archived discussions

OSM size woes[edit]

Ugh, recent changes to OSM have made exports impossibly big. All SVG exports now run 100+ MB, making them utterly unusable in Inkscape. Does anyone know a way to deal with this? Otherwise I'm going to have to return to the old days of tracing maps... --Peter Talk 02:07, 23 February 2013 (UTC)[reply]

An example problem was trying to export an SVG of just the area covered by the Adirondack Park—it forces a download of the background image for The Americas. Unsurprisingly, The Americas contain a lot of nodes irrelevant to my task. Similar deal right now trying to just grab the southern half of Saint Petersburg. --Peter Talk 02:10, 23 February 2013 (UTC)[reply]
(edit conflict) I did one yesterday of Copenhagen, 1:20000, 1200x1400 pixels, which was just 17 megs, might just be the specific area that has some very large nodes? Sertmann (talk) 02:17, 23 February 2013 (UTC)[reply]
btw, I'm almost certain there is a smart way to delete all the unnecessary nodes outside the image area, I just haven't figured out how yet. That might solve the problem if you are able to at least open the svg, delete those, save it, and reopen. Maybe finding an inkscape forum or IRC channel could enlighten us. Sertmann (talk) 02:22, 23 February 2013 (UTC)[reply]
I can usually open them (with 8GB ram), but can't do any edits without crashing Inkscape... It's not just one part of the world—it's anything larger than a very small map. Even the map I'm doing of just a few blocks in Saint Petersburg right now downloaded the background path for the whole of Leningrad Oblast. --Peter Talk 02:25, 23 February 2013 (UTC)[reply]
I'm throwing out wild guesses here, but I wonder if it's the proximity to the Canadian border that's causing the problem for the Adirondacks. I've noticed that if any part of a shape is visible in (or even just outside) the map area, the entire shape is included in the SVG. St. Petersburg is along the shoreline of the Oblast, so it would make sense that the entire outline gets in. As for a solution, have you tried editing the SVG as an XML text file? 100+MB is a lot for Notepad, but it might work better than Inkscape. LtPowers (talk) 03:55, 23 February 2013 (UTC)[reply]
That's not it either—the Adirondacks (and Bogotá, which I just checked) downloads every node in the Americas gray path—right down to Tierra del Fuego. As best as I could tell, trying to do the southern half of Saint Petersburg downloaded every node for the background shape for Eurasia. That map crashed Inkscape pretty quickly when I tried to zoom out, but I definitely made out the coastline of Korea. I've only tried figuring out what the heck is going on just today, but this problem has been present for at least weeks.
Unfortunately, XML exports are pretty useless because of the strict node limits. OSM wouldn't even let me export an XML file for that half of St Petersburg I keep referring to—too big an area (possibly because it's including the entire Eurasian continent?). --Peter Talk 05:30, 23 February 2013 (UTC)[reply]
I've brought this up on the OSM wiki [1], but I'm not sure whether that was the right place. --Peter Talk 05:46, 23 February 2013 (UTC)[reply]
I think you misunderstood me. An SVG file is really just a specialized XML file. SVGs are totally editable in a text editor. If you can find the right tag to remove, you can remove the large shapes in text and make the file small enough to edit in Inkscape. (It may not be easy to identify the right tag, though.) LtPowers (talk) 15:19, 23 February 2013 (UTC)[reply]
Gotcha. I have struck out so far, trying to edit the SVG via a text editor without causing the SVG to crash on loading in Inkscape. I did manage to just delete the (continent+ sized) background shape, which drops the size of the Bogotá map down from 140MB to 22MB. But this means I can't use OSM to generate coastlines anymore, which is a real shame. I usually would get rid of extraneous nodes in the background shape (which is always too big, just not so ludicrously in the past) by doing an intersection operation with the blue background object that matches the size of the export area, but that operation crashes inkscape without fail when performing it on a shape with millions of nodes. --Peter Talk 19:38, 25 February 2013 (UTC)[reply]
Well, let us know if you get an answer from the OSM folks. LtPowers (talk) 01:53, 26 February 2013 (UTC)[reply]

Cycle paths[edit]

I'm trying to create a cycling map of Copenhagen for the Cycling in Copenhagen guide, and I'm trying to figure out a way to mark streets with cycle tracks on them (which in Copenhagen means most major streets). I'm using the standard city map template, but I'm having major problems figuring out a way to this that looks good, I've tried marking the whole street in various colours, but haven't come up with anything I like.

Anyone who can come up with a suggestion?

It needs to be fairly toned down, since I plan to mark some suggested routes as the maps main feature, but at the same time it should be clear enough to use while biking the town. --Stefan (sertmann) talk 13:50, 25 February 2013 (UTC)[reply]

The first thing I'd try would be underlaying the route with a colored path (red, maybe) that slightly exceeds the width of the streets. This would show as a red border on either side of the route. LtPowers (talk) 18:11, 25 February 2013 (UTC)[reply]
The official D.C. bike routes map [2] uses a key with dashed lines for off-street trails, solid lines on top of roads with dedicated bike lanes, dotted lines on roads with on-street signed routes, plus four categories of road suitability (colors): good, fair, poor, and prohibited. I think it's pretty effective. --Peter Talk 18:16, 25 February 2013 (UTC)[reply]

What are background and forground?[edit]

I am familiar with Inkscape, and am trying to follow the instructions, but I don't understand what are "background" and "forground" supposed to mean, nor do I have any idea where I should draw them. Could someone please explain? Thanks a lot! Nicolas1981 (talk) 04:33, 28 March 2013 (UTC)[reply]

I wouldn't worry about that. The distinction was between the dark gray background and the light gray foreground (the selected area), but it's not an important one. --Peter Talk 04:35, 28 March 2013 (UTC)[reply]

Non-WV user Burmesedays[edit]

I noticed that user (WT-en) Burmesedays was listed as a potential helper, however as far as I can tell they are a WikiTravel user who has not migrated to WikiVoyage. I removed their reference from the main page, however if I have made an error in doing this then please undo my change and point to the relevant current user? --Andrewssi2 (talk) 08:12, 22 October 2013 (UTC)[reply]

It's not that material, but he did come here and was driven away due to a misunderstanding with the display of some of his photos - it's my fond hope that he may return... --118.93nzp (talk) 01:10, 12 January 2014 (UTC)[reply]

Replacing hand-crafted maps with auto-gen crap[edit]

Am I incorrect in thinking that edits like this are completely and totally inappropriate? I'm absolutely stunned by the rudeness and arrogance of this edit. Powers (talk) 00:22, 12 January 2014 (UTC) If the static map is well-drawn, up-to-date and helpful there may be very good reasons why it should continue to be displayed in tandem with a dynamic map...[reply]

I can certainly understand why this edit might seem brusque and disrespectful to the author of the static map.
Dynamic maps have huge advantages when the reader is online, but... --118.93nzp (talk) 01:08, 12 January 2014 (UTC)[reply]
Continuing to refer to dynamic maps as "auto-gen crap" doesn't help. My personal opinion (and that of others) is that dynamic maps are the way forward, and you (LtPowers, as well as others) have made it clear that you feel that static maps are superior. We're eventually going to have to find some resolution to that difference of opinion, but until that point is reached I thought the focus of the continuing dynamic maps rollout was going to be on articles without Wikivoyage-style maps - that was also previously discussed in a couple of discussion threads at Wikivoyage talk:Dynamic maps Expedition. We need to answer the question of how the two should co-exist, whether one should be preferred, or whether some other solution is appropriate, but thus far I haven't seen anyone attempting to spearhead that discussion in a way that proposes a compromise solution or otherwise addresses concerns from both sides of the issue. -- Ryan • (talk) • 01:18, 12 January 2014 (UTC)[reply]
Then you have not been understanding what I have been writing, Ryan. Each has their advantages and disadvantages and most articles would benefit from both types being displayed for the reader. You still have not answered the question that I have posed twice now at Wikivoyage talk:Dynamic maps Expedition. --118.93nzp (talk) 01:41, 12 January 2014 (UTC)[reply]
Static maps counteract the wiki idea. Article texts can be supplemented and corrected by any visitor immediately and without prior knowledge. This must also apply to maps. Dynamic maps meet this 100%, even automatically because coordinates should be already registered in the listings. Almost all new editors use dynamic maps intensive. - For static maps, additional software is required. Long training periods are required and extensive data traffic (svg, png). And this is repeated for every single change. Has a new user ever created a static map in Wikitravel style (yes, Wikitravel) as a SVG file? As long as we use the same images (maps) as Wikitravel [3], we will never get a better ranking [4]. Graphics are first checked for duplication and classified as a mirror. - Therefore, I am in favor of introducing dynamic maps as soon as possible for all the articles . - Joachim Mey2008 (talk) 07:50, 12 January 2014 (UTC)[reply]
Yes, that is a powerful exposition for rolling out dynamic maps to all articles as soon as possible.
I had forgotten about the SEO advantages, but we may have to leave many of the "inherited" static map images in place since they are so time consuming to create and we have so few who are competent to change them. Would a bot be capable of tweeking each static map file so that it is not a duplicate from the code perspective? --118.93nzp (talk) 19:50, 12 January 2014 (UTC)[reply]
If someone can look at this dynamic map on Saint Marys (Pennsylvania) and declare it superior to the map that was previously there, then this project is hopeless. The dynamic map is focused only on downtown and gives no sense of the dimensions of what constitutes Saint Marys as a community (versus as a municipal division). Quite frankly, the simple fact that it doesn't display the two main chain hotels in the city alone justifies calling it "crap". If Joachim or anyone else is going to go around removing hand-crafted maps as soon as they're the least bit out of date, we have a serious problem here. Powers (talk) 01:57, 13 January 2014 (UTC)[reply]
Powers, are you able to suggest any kind of rule for when a static map is sufficiently out of date and should be replaced by a dynamic map? I'm just trying to find any common ground at all here. Andrewssi2 (talk) 02:35, 13 January 2014 (UTC)[reply]
@LtPowers: This is a dynamic map of high quality. You can move, zoom, or just press the button "Show me all markers". I did not expect that this is so hard to understand. Dynamic maps should always be set to the "best view" and not to a general overview. Then you can discover interesting details. For example, the exact course of the river "Elk Creek" (entered using official maps at a scale of 1:600​​). In the Mapnik layer even the underground course is specially marked. How can you call something like this: "crap"? - Joachim Mey2008 (talk) 06:22, 13 January 2014 (UTC)[reply]
There is no reason to make the reader jump through hoops before we show them what they need to know. This is especially true for travelers, as they often need to restrict the amount of data they receive, or even print out our pages before they travel. The ability to zoom in and out is pretty useless if the user doesn't know he needs to do so before hitting Print.
However, this is all beside the point. The point is that there was a good map already in the article, and its errors should have been fixed rather than the entire effort tossed in favor of a quick-and-dirty solution. This is absolutely equivalent to noticing that some operating hours are out-of-date and then choosing to replace the entire contents of the article with content generated from TripAdvisor. Powers (talk) 18:46, 13 January 2014 (UTC)[reply]
I do not understand your excitement. In the German Wikivoyage I have dozens of static maps removed and replaced with dynamic maps. No one got upset because the maps were out of date. An update would be too complicated. 50% of these maps I myself had drawn (Inkscape, Zoner Draw-svg etc.). Here is an example [5]. You put great importance to the static map. Just put my entries again reversed. I'm not angry with you. This is a wiki. So everyone should be able to live with this. -- Joachim Mey2008 (talk) 05:38, 14 January 2014 (UTC)[reply]
Some things that are worth doing may be more complicated than a quick-and-dirty alternative. That doesn't make them not worth doing. Powers (talk) 15:27, 14 January 2014 (UTC)[reply]
It is clear that there is disagreement regarding the merits of static vs dynamic maps, and at this point I would suggest we just agree to disagree, and try to respect each other's opinions. We need to move on from "dynamic is good, static is bad" (or vice versa) and try to find a solution that will either work for both sides or make clear that one map type is preferred. -- Ryan • (talk) • 15:59, 14 January 2014 (UTC)[reply]
I've already acquiesced to the addition of dynamic maps on articles that are otherwise lacking maps. But I would very much like some assurances that my hard work on maps will not be summarily removed as soon as someone deems them to be "out of date". Powers (talk) 19:28, 14 January 2014 (UTC)[reply]
That compromise works for me at this time - we'll eventually have to find a way to move forward in case of disputes (such as what is currently going on at Saint Marys (Pennsylvania) and with the stalled starnom for El Camino Real), and hopefully someone can come up with a viable proposal for doing so that garners support, but there are more than enough articles without maps that I think we can focus on those articles with respect to dynamic maps in the mean time. That's my opinion, anyhow - I'd much rather have an imperfect solution that allows dynamic maps to move forward now on a slightly-limited basis while we work out a solution that can be applied more broadly in the future. Hopefully others can add their own feedback. -- Ryan • (talk) • 19:42, 14 January 2014 (UTC)[reply]
You seem to have ignored my feedback, Ryan.
There is simply no basis for your faux summary commandment of
  • "Do not add a dynamic map when a Wikivoyage-style static map is already present."
since no rationale for this commandment has yet been advanced despite continuing requests by me to do so! Please replace that commandment with something along the lines of:
"Do not remove either a dynamic map or a Wikivoyage-style static map from a destination page without a consensus to do so being achieved on the article discussion page first!" --118.93nzp (talk) 23:40, 14 January 2014 (UTC)[reply]

Internal Server Error[edit]

To clarify: We use two servers. For HTTPS (mapframe) the Tools Server of the Wikimedia Foundation [6] in the U.S. Unfortunately, this server is not very reliable. Reasons? - For the full-screen display (HTTP) is used, a server of Hetzner AG in Germany [7]. This server is professionally monitored and maintained. Hetzner is a leading web space provider in Europe (30,000 servers, 250,000 domains). So if the full screen map should not run, then I myself once again programmed garbage. - Joachim Mey2008 (talk) 08:24, 12 January 2014 (UTC)[reply]

Thanks for that clarification, Joachim.
Since the "mapframe server" is not very reliable, is that an argument in itself for retaining a static map in addition to a dynamic map on the grounds that even an out of date and incomplete map may be better than none? --118.93nzp (talk) 19:50, 12 January 2014 (UTC)[reply]
If mapframe server fails, there are several ways to go to full screen mode. 1) Click "View full-screen map for ...". 2) Click on the Map icon in the upper right. 3) Click on a marker in the article text. The programs run on the Hetzner server completely independent of the mapfram server. Those are mirrored there twice. Theoretically, a server failure should there hardly noticeable (milliseconds). - But in mapframe window should no error message appear. Better a helpful hint. We work on it. - Joachim Mey2008 (talk) 06:48, 13 January 2014 (UTC)[reply]
Yes, the last two are both methods that work.
However, as you will see from my screenshot above, sometimes the mapframe server fails big time and then there is no message of "View full-screen map for ..." displayed at all.
Also and unfortunately, neither of the latter are completely and intuitively obvious to the casual reader.
The "Map icon in the upper right" is simultaneously ugly, badly positioned (looking like an afterthought) in relation to the banner and not intuitively obvious as to its function. Would blue text underneath such as "full screen dynamic map..." help?
Thanks in advance for continuing to work on more helpful error messages, Joachim... --118.93nzp (talk) 07:29, 13 January 2014 (UTC)[reply]
The first method works also well. You only have inadvertently cut off the link "view full-screen map for ..." on your screen shot. This link comes from Wikimedia server and is always present, regardless of the Wikimedia tools server [8]. - The icon on the top right I have not placed anything, just basically proposed. But an improvement, such as according to your proposal I also find necessary. The mapframe idea is also not mine, only the map display. But I find mapframe pretty well done and would fully support it. - Joachim Mey2008 (talk) 08:08, 13 January 2014 (UTC)[reply]
In general, if a server error. I have sent twice a short e-mail to the administrator address specified in the error message. After 2 or 5 minutes everything was OK. I hope this was not an coincidence. -- Joachim Mey2008 (talk) 08:48, 13 January 2014 (UTC)[reply]
@118.93nzp: I've added a tooltip to the geo-icon. For integration into the page banner (which was originally planned) my programming skills are not enough. -- Joachim Mey2008 (talk) 06:07, 16 January 2014 (UTC)[reply]
Thanks, Joachim, that hover text of "full screen dynamic map" is an improvement but I would suggest expanding to "Click for a full screen dynamic map..." might be even better? --118.93nzp (talk) 07:17, 16 January 2014 (UTC)[reply]
Thanks for the hint, I changed the hover text. -- Joachim Mey2008 (talk) 09:14, 16 January 2014 (UTC)[reply]

SVG *and* PNG upload[edit]

As I understand it, the mediawiki software automatically converts SVG images to PNG, so why are images uploaded in both formats? Doesn't it make more sense to use the SVG images directly, like in Wikipedia?

Tiago Dias (talk) 12:08, 30 March 2014 (UTC)[reply]

Two reasons, actually, and thanks for asking; we perhaps should put an explanation on the project page. First, the MediaWiki SVG renderer doesn't handle fonts very well. SVG maps you see on Wikipedia likely have had their text converted into uneditable shapes (text-to-path conversion). Doing so ensures that the text will appear exactly as the author intended... but it makes the text uneditable as text (you can't just type new text, or fix typos easily). But we didn't want to resort to that because we want people to be able to edit the text on our maps easily. Secondly, we tend to create a single SVG for all language versions of Wikivoyage, and include the language-specific text for each language within the same SVG file. We then export only the text for a specific language into any single PNG file. So we would have, for example, a single master SVG file, and then several PNG files (English, Russian, German, etc) derived from it. Does that make sense? Feel free to ask any more questions if anything was unclear. Powers (talk) 01:28, 31 March 2014 (UTC)[reply]

exporting from Open Street Map[edit]

I see the Export tab, but when I click it, I don't get offered any options in relation to settings or file format, just the ability to adjust the boundaries and an Export button (which gives me an OSM extension file). What am I doing wrong? Thanks Kerry Raymond (talk) 06:45, 27 May 2014 (UTC)[reply]

I found the "Share" tab on the right produces PNG files. Still no option settings, but at least I have a map now. Kerry Raymond (talk) 06:59, 27 May 2014 (UTC)[reply]
As noted at Wikivoyage:How to draw a map#SVG imports from OSM, the interface on the main OSM site is effectively broken. Using Maperitive, as described in that section, is probably your best bet if you want to create an SVG using OSM data. Powers (talk) 17:33, 27 May 2014 (UTC)[reply]

Fonts[edit]

Hi, I was talking with a graphist on Commons and he pointed out two problems with our standard fonts:

  • The words, Airport And Train Station uses Blue Highway which to this page svg fonts is not an approved font.
  • The rest of the text uses DejaVu Sans Condensed. Running Ubuntu and Linux Mint that font has another name, DejaVu Sans Semi-Condensed.

Was this a known issue? Is there a solution? --Nastoshka (talk) 08:13, 2 April 2015 (UTC)[reply]

Blue Highway is often used for historical reasons; it's deprecated now but we still use it sometimes. The version of MediaWiki we used to run on Wikitravel didn't support inline SVG rendering. The lack of support for Blue Highway is a minimal issue because we don't display SVGs within articles; we use PNG renderings of master SVG files. (This also allows us to keep map labels for all languages in one SVG file, exporting a different PNG for each language.)
I wasn't aware of the naming issue for DejaVu Sans Condensed. As it's a supported font, I assume there's some sort of workaround in place?
-- Powers (talk) 00:06, 3 April 2015 (UTC)[reply]
@LtPowers: No idea if is there a workaround for the naming issue. Regarding the map labels in one SVG files, the same graphist on Commons suggested that we can keep several labels in several language in the same SVG file without having to export a png file. Take a look here for more info. To switch between two or more language, you need just to add |lang=en or |lang=de... to the image syntax (e.g.: [[File:example.svg|lang=en|thumb|caption]]).
here some examples. It has two main advantages:
  • Svg files become much less heavy
  • No need to increase tenfold the files on Commons, one png for each language..
And one disadvantage:
That's an interesting solution! But if Inkscape doesn't support the switch tag, updating the maps would destroy the language switches. Powers (talk) 19:13, 3 April 2015 (UTC)[reply]

Static maps numbering and numbering of markers for dynamic map[edit]

There is an interesting point which cropped up in a different discussion (Wikivoyage_talk:Map) and I thought it's something we should talk about.

I have been working on updating/creating static maps from time to time. In the past the numberings on them didn't matter so much, as they were entirely independent, but now listings with coordinates have numbers assigned as they are shown on the dynamic map. When I update/create maps, I usually make sure the numbers on the static map correspond to the numbers assigned to the listings (see Unst or Singapore/Bugis) but I realise this is quite stupid, as any update will break the ordering. Furthermore, I notice that in some old maps, if there's more than 9 listings, the numbering will continue with A, B etc, whereas now I have to squeeze in double digit numbers. Another issue I saw is that sometimes there are numbers which I would like to skip on the static map (too close together, so can be merged, or off the map), which now just makes it look like something's missing.

Is there any rule/suggestion on how to handle this that I have missed out? AlasdairW suggested using letters instead of numbers for static maps, which I think would be a potential solution. Drat70 (talk) 01:55, 10 October 2017 (UTC)[reply]

If you were to use letters, you may need a legend included in the SVG at the bottom edge to indicate which letter is which POI. That'd be hard to read? K7L (talk) 02:45, 10 October 2017 (UTC)[reply]
Well, most static maps already have a legend with all the POIs on the map already with the numbers and the names of the POIs. See the maps above for example. Drat70 (talk) 04:56, 10 October 2017 (UTC)[reply]
Static maps have used numbers since time immemorial. Why not make the dynamic maps change to letters? Powers (talk) 19:44, 10 October 2017 (UTC)[reply]
Sure, either way would work. The aim would be to distinguish then, in which manner we do that is not so important. Drat70 (talk) 00:57, 11 October 2017 (UTC)[reply]

Colour-blind friendly colours[edit]

Hi Wauteurz, I saw you noted a number of maps on Wikivoyage:Requests for maps were colour-blind unfriendly. Do you have any resources or colour palettes that would be better? I drew the maps for the Central Belt and Scottish Highlands that you flagged and the pink-green colour scheme is adapted from Colorbrewer, which indicated the colours were colour-blind safe. I find making maps colour-blind friendly challenging so would be interested to hear if you know of any other sites that are helpful. -Shaundd (talk) 06:28, 16 November 2018 (UTC)[reply]

@Shaundd: Hey there, I am partially colour-blind myself (red-green blindness), so that is what most of this is based on. If I cannot see the difference between two colours, or have difficulty to tell them apart, I list them as colour-blind unfriendly. In a nutshell, anything that doesn't fit "our visual style", as I've phrased it, would not be using (parts of) the template. The region colours in there are the ones I use, and, even though I have trouble with them in some cases, they do the job pretty well. Most of the issues I have with the colours in said template are problems introduced by my monitors. The maps you listed aren't the worst offenders and I'm not claiming they are, but I can imagine someone having trouble telling apart  #ccf2c2  and  #fefee0  specifically. That may just be me though. If others disagree with my judgement as well, then feel free to remove those two maps from the list. Again, they're far from the worst offenders :)
-- Wauteurz (talk) 11:17, 16 November 2018 (UTC)[reply]
Thanks Wauteurz. Now that you point out the issue with  #ccf2c2  and  #fefee0 , I think that is where I deviated from the recommended colours. Good to know, I'll try to fix that.
I saw you also listed Baden-Württemberg (another map of mine) -- which colours are hard to differentiate on that map? It's essentially the standard palette but slightly lighter (to improve contrast between the text and the region colours). I'm also curious what you think of the region maps at Mississippi and Oregon. I hope you don't mind me asking, I've been working with different map colours for a few years trying to improve readability and make them more colour-blind friendly. I can judge if there's better contrast between text and background, but I see colours fine so I can't judge if the colour palettes I use are colour-blind friendly or not. Thanks! -Shaundd (talk) 07:39, 17 November 2018 (UTC)[reply]
@Shaundd: Of these three, Baden-Württemberg is the worst for me. I have no problems with the colours as they appear on the region list, but I think you made the colours on the map lighter? Correct me if I'm wrong, but that makes it to where I have difficulty with  #4f93c0  and  #b383b3 , as well as  #b5d29f  and  #d09440 , which, for the record have no issue with usually. What would improve the situation is a better readable border, like I myself did for File:Amstelland Wikivoyage Map.png. White borders, however, prove difficult with city maps, since roads on these are intended to be drawn in white, if I'm not mistaken. Feel free to leave the map up though. The dynamic map is showing the colours better.
As per the other two maps, Mississippi is the opposite of Baden-Württemberg, in that the dynamic map is worse to read while the static map is a-okay.  #e0f3f8  blends with  #ffffbf  and  #ffffbf  blends with  #fee090 , but  #e0f3f8  does not blend with  #fee090 . The other two colours I have no issues with. For Oregon, I don't have any issues, but I can imagine others having problems with it.  #e0f3f8  and  #d9f0d3  specifically would give me issues if the white line wasn't there to draw a border. The border, however, isn't ideal, since it blends with  #ffffbf . Truth be told, it's hard to optimise for all kinds of colour-blindness since any combination of red, green or blue can be malfunctioning.
I wouldn't be surprised if there were some sort of online tool that can simulate how colour-blind people see an image. I don't know of any myself, but if someone knows such a tool that would work to simulate the appearance of the maps we make, then that'd be in a lot of people's favour and is most likely worthwhile to link on the project page so we can prevent future issues with maps not being colour-blind friendly.
-- Wauteurz (talk) 17:39, 17 November 2018 (UTC)[reply]
Hi Wauteurz, thanks. I found a couple of filters (from this article on drawing colour-blind friendly graphics) and they're helpful for highlighting the issues you described above (other than Scottish Highlands, which looks OK in the three filters). I see what you mean by the dynamic Baden-Wurrtemberg map being more distinct than the static, while the reverse is true for Mississippi, as well as the blending problems. I'll take a look at some other maps with the filters on to see how it looks and whether there are any conclusions. Another map that I assume could be problematic is Australia, and the South, Midwest and Texas regions of the United States of America map could also blend together? -Shaundd (talk) 07:25, 19 November 2018 (UTC)[reply]
@Shaundd: The US maps look fine to me and I don't think anyone will have too much of an issue with that. Australia is a whole different story though. The Northern Territory, Queensland, South and New South Wales all blend to some degree. When I first looked at it, I honestly thought that the Northern Territory and Queensland were one region together. I'll say again that the Scottish Highlands map isn't the worst case. Looking back at that map,  #f5c7ea  might actually blend with the water more than  #ccf2c2  and  #fefee0  would blend with each other. I'm now actually doubting if the latter two conflict all that much with each other to begin with. I now also wonder if such a filter was tested on the mapmaking templates. If not, we may have some work ahead of us updating the colours and maps to actually be colour-blind friendly...
-- Wauteurz (talk) 19:46, 19 November 2018 (UTC)[reply]
Hi Wauteurz, I agree on the Scottish Highlands map. When I looked at it again with the filters, I think the biggest problem is the pink region and the blue water. With the US map, it depended on which colour-blindness filter I used. The ones where seeing blue or red were a problem tended to blend the South with other colours.
I'd be surprised if the standard map colours were put through a filter. That template is 9-10 years old and I don't recall there being many web tools available at the time that helped with readability or colour-blindness. Some of the template colours also fail the WCAG 2.0 readability standards (e.g., don't have sufficient contrast between text and background colours), which is why I tend to not use the template. I'd be interested in seeing if we can come up with more readable and colour-blind friendly maps but unfortunately don't have much spare time right now. -Shaundd (talk) 21:59, 1 December 2018 (UTC)[reply]

API Key[edit]

Swept in from the pub

On this map it says API key required when you switch to relief maps. Not sure who to raise this with to see about getting it fixed? Travel Doc James (talk · contribs · email) 17:01, 16 June 2022 (UTC)[reply]

Just going by this old phabricator task, it seems that tool has been depreciated in favour of Kartographer — are you able to use that instead? TheresNoTime (talk) 20:35, 16 June 2022 (UTC)[reply]
The mapframe in Heaphy_Track#Walk doesn't appear to show the issue with the relief map layer. It appears that is only an issue with the full page map (from the icon at the top right of most pages. I think that mapframe is Kartographer based, but I don't know about the full page map. (It is worth keeping the full page map as it has some features missing from mapframe as is better for printing.) AlasdairW (talk) 21:38, 16 June 2022 (UTC)[reply]

How to fix a bunch of grey unnecessary markers on the map?[edit]

Swept in from the pub
Map
55°46′38″N 37°36′22″E
Map of How to draw static maps
<maplink>: The JSON content is not valid GeoJSON+simplestyle. The list below shows all attempts to interpret it according to the JSON Schema. Not all are errors.
  • /0/ids: Does not match the regex pattern ^Q[1-9]\d{0,19}(\s*,\s*Q[1-9]\d{0,19})*$
  • /0/ids: String value found, but an array is required
  • /0/ids: Failed to match exactly one schema
  • /0/service: Does not have a value in the enumeration ["page"]
  • /0: Failed to match exactly one schema
  • /0/geometries: The property geometries is required
  • /0/type: Does not have a value in the enumeration ["GeometryCollection"]
  • /0/type: Does not have a value in the enumeration ["MultiPolygon"]
  • /0/type: Does not have a value in the enumeration ["Point"]
  • /0/type: Does not have a value in the enumeration ["MultiPoint"]
  • /0/type: Does not have a value in the enumeration ["LineString"]
  • /0/type: Does not have a value in the enumeration ["MultiLineString"]
  • /0/type: Does not have a value in the enumeration ["Polygon"]
  • /0/coordinates: The property coordinates is required
  • /0/geometry: The property geometry is required
  • /0/type: Does not have a value in the enumeration ["Feature"]
  • /0/features: The property features is required
  • /0/type: Does not have a value in the enumeration ["FeatureCollection"]

Results as shown on the map, how to fix a bunch of grey unnecessary markers on the map? Can help? thanks. ✈ IGOR ／ ✉ TALK?! ．WIKIVOYAGER ! 17:17, 29 June 2022 (UTC)[reply]

@Yuriy kosygin We've discussed this quite a number of times before. The issue is this data comes from OpenStreetMap and there's no way to remove the unnecessary grey markers unless you completely comment out the transport lines. SHB2000 (talk | contribs | meta.wikimedia) 00:31, 30 June 2022 (UTC)[reply]
Alas... Wikivoyage is really weak, I'm afraid we'll have to draw the route own. ✈ IGOR ／ ✉ TALK?! ．WIKIVOYAGER ! 15:34, 30 June 2022 (UTC)[reply]
There has to be a way to fix this idiocy on OpenStreetMap, but in the meantime, we need to eliminate this crap from our site. Ikan Kekek (talk) 16:25, 30 June 2022 (UTC)[reply]
Could we make the gray actually be 100% transparent? It would still be visible, but perhaps not such a disaster. WhatamIdoing (talk) 17:38, 30 June 2022 (UTC)[reply]
If I recall correctly, the issue at hand was that we couldn't make the distinction between line elements and point elements. I don't master Lua myself, so I can't make sense of whether this would be a viable workaround for Module:Mapshapes. @Andree.sk, any words on this?
-- Wauteurz (talk) 18:22, 30 June 2022 (UTC)[reply]
Mapshapes is just a thin helper to instantiate {{mapshape}}, which is the main culprint. In turn, that one uses the kartographer stuff, which can't be trivially adjusted. But there may be some hacks, I'll try to try something in the coming weeks... -- andree 20:47, 30 June 2022 (UTC)[reply]
The only other solution is to manually trace out the route on geojson.io and then add it to the article (see Canberra/Acton for an example of how this is done) SHB2000 (talk | contribs | meta.wikimedia) 07:32, 1 July 2022 (UTC)[reply]
While I don't question this working, it does come with a substantial downside: It's not 'automatically' updated whenever the line changes route (in reality, OSM-contributors update it and we import the dataset they edit). This leaves us with a lot of extra work, which I expect will get out of date quite quickly. Perhaps not for metro's, but definitely for trams or BRT's. Drawing the lines ourselves can work for cities that see regular edits or that have docents capable of editing GeoJSON data (and willing to do so). I strongly prefer making Mapshapes work, even if it's a workaround over manually doing the work ourselves.
-- Wauteurz (talk) 08:30, 1 July 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

At the German Wikivoyage I added a rule to MediaWiki:Kartographer.css which hides the grey pushpin markers. 

/* Removing grey pushpin markers on mapframe maps */
img[src$="pin-m+7e7e7e.png"], img[src$="pin-m+7e7e7e@2x.png"] {
	display: none;
}

Unfortunately, I cannot make the edit by myself. But I am sure your admins can do it. --RolandUnger (talk) 09:24, 1 July 2022 (UTC)[reply]

@Andyrom75: given you're the only active interface admin here, can you add the three-line code? SHB2000 (talk | contribs | meta.wikimedia) 10:16, 1 July 2022 (UTC)[reply]
I checked the positions of the markers, and they are the stops/stations of the public transport lines. However they don't give the name of the stop, but only the name of the line. The name of the line is already displayed by clicking the line. So, with the present marker texts, no new info is available. If the marker info would have the name of the stop it indicates, displaying them could be useful. I tested from which zoom level displaying the markers is not disturbing anymore, and came to zoom level 14-19 may show the markers, below 14 not. And this zoom level dependent conditional showing of the markers should only be done if the markers contain the names of the stops. If it is impossible to have the names of the stops in the markers, markers should never be shown. --FredTC (talk) 11:18, 1 July 2022 (UTC)[reply]
While I agree that they could be useful to some extent, the thing is that we can't properly make the distinction between lines, polygons or points/markers in the data that we fetch from OpenStreetMap. At present we also cannot import the names of these stations/halts (I believe this data gets lost between Wikidata and OSM, but I might be wrong). Roland's solution above is just a workaround that hides the marker, but the point itself stays on the map albeit invisible. So long as we can't make the distinction properly, we sadly can't implement these markers in a more useful way either. For that distinction to be made, the Kartographer extension needs additional functionalities, which we've been asking for for several years already. Until we get that, it's either hiding the markers or accepting them as-they-come, the latter of which is a lot less popular.
-- Wauteurz (talk) 12:48, 1 July 2022 (UTC)[reply]
@Ikan Kekek, do we have any other admins who can do this? Another option would be using JavaScript, but using CSS is much cleaner... Also, alternatively to 'display: none', we could change opacity to e.g. 0.3, that also looks quite ok. -- andree 09:31, 13 July 2022 (UTC)[reply]
I really don't know. I hope other admins are reading this thread. Ikan Kekek (talk) 09:35, 13 July 2022 (UTC)[reply]
This needs an interface admin to do it and as far as I'm aware, @Andyrom75: is the only interface admin who has been active recently. SHB2000 (talk | contribs | meta.wikimedia) 09:38, 13 July 2022 (UTC)[reply]
I'd say it wouldn't hurt to have at least 2-3 people with those permissions - even if they need guidance for doing technical changes... -- andree 10:15, 13 July 2022 (UTC)[reply]
@WOSlinker maybe, then? -- andree 10:51, 13 July 2022 (UTC)[reply]
Sorry guys, I've read the conversation just right now.
RolandUnger, I have created MediaWiki:Kartographer.css as per your code, but not so much time for testing. The gray POI has disappeared; it's enough? Any side effect to be checked?
SHB2000, thanks for pinging me twice. Next time, in case of emergency, leave a message on my it:voy talk page. --Andyrom75 (talk) 16:35, 13 July 2022 (UTC)[reply]
It helped, thanks both to you and Roland! :) -- andree 19:28, 13 July 2022 (UTC)[reply]
There are no side effects. The names of the pushpin images contain their colors, and this particular color is not used elsewhere. Of course, the way proposed is a workaround not a real solution but it is useful. The grey pushpin markers are present up to now, but they are invisible (hidden). --RolandUnger (talk) 04:23, 14 July 2022 (UTC)[reply]
RolandUnger, thanks for your confirmation. --Andyrom75 (talk) 10:00, 14 July 2022 (UTC)[reply]
Brilliant work. Thanks to everyone who contributed to finding a workaround.--ThunderingTyphoons! (talk) 11:52, 14 July 2022 (UTC)[reply]
Is this something that we should share with other wikis? WhatamIdoing (talk) 16:15, 14 July 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ A permanent solution to this problem has been implemented but not published for whatever reason (see https://phabricator.wikimedia.org/T292613). --Renek78 (talk) 14:14, 16 July 2022 (UTC)[reply]

Bugfix for grey markers has been deployed today. The CSS workarounds should not be necessary anymore. --Renek78 (talk) 20:25, 19 August 2022 (UTC)[reply]

Using a separate colour for freeways on static maps[edit]

Swept in from the pub

Right now, our current Wikivoyage style for static maps is to use red for a main road, while use yellow for secondary roads. While the criteria for what's a main road and what's a secondary road is fairly arbitrary and up to whoever's making the map to decide, I was wondering whether we should consider using a different colour for freeways/motorways? While I'm still new to this static mapmaking business, I personally find such a distinction of what's an ordinary road and what's a freeway useful, and many people often either want to use freeways or try to avoid them. Our dynamic maps already use a different colour for freeways, so why not static? I wanted to make such a distinction when I made a static map for Greater Brisbane today (on right), but such a change would be against Wikivoyage-style, so I'm asking the community for input; and if we do use a separate colour to distinguish freeways from normal roads, what would it be? --SHB2000 (talk | contribs | meta.wikimedia) 07:24, 5 July 2022 (UTC)[reply]

I tried using orange to identify freeways in the map of Southern Tasmania that I just created (on right). Is it obvious that the route coloured orange means a freeway? (I really want answers so I can take note of what I should do differently for my next static map) --SHB2000 (talk | contribs | meta.wikimedia) 13:32, 5 July 2022 (UTC)[reply]
What a colour means is never obvious, unless you know something about the destination. The colour could just mean "main highways" or whatever.
I think that there are many more things that might be interesting for at least some travellers, and most travellers to some destinations. How do we show good cycling routes? Roads with good bus service? Nice pedestrian routes? –LPfi (talk) 17:14, 5 July 2022 (UTC)[reply]
I don't think any colour schemes are immediately obvious wordwide. For a UK map, I would be tempted to use the same as some OS maps - blue for motorways, red for A roads, brown for B roads and yellow for minor roads, but some UK road atlases use green for A roads as this is the colour used on road signs. Another complication is the use of different colour fills for regions - a yellow road on a yellow background isn't good - spot the roads going to Richmond in Southern Tasmania.
Is it possible to use slightly different line widths to indicate road importance? We also need to allow for things like long distance walking tracks or off-road cycle routes. As both examples have a lot of sea, they could have a key explaining the colours. AlasdairW (talk) 21:45, 5 July 2022 (UTC)[reply]
Agreed. Map making 101: Every map needs a legend (key), and every symbol used in that map (intuitive or not) needs to be explained in that legend. That way you can add whatever is needed. Having a consistent style for static maps is a nice to have; it should not get in the way of making maps useful.
The color issue mentioned by AlasdairW is part of of a bigger problem: The different elements used in the map are unbalanced in terms of contrast (color, saturation, brightness) and visual weight (size, thickness).
1) The lines used for the roads are too thin in relation to everything else. After enlarging enough to properly see the roads, the text labels are way larger than they need to be. This is a static map: pick one scale and apply it consistently, using an appropriate degree of generalization.
2) Visual importance of borders (thickness, color contrast of the white vs. area colors) is too high given that areas already have different colors. Line thickness of borders is also inconsistent in the second map.
3) In general, having areas colored that heavily (dark & saturated) creates all kinds of problems for the visibility of makers, line elements and text labels. "Brisbane" in the first map is practically unreadable, for example. In File:Georgia_regions_map2.png, for example, that is much less of an issue due to different color choices.
Unfortunately, the region maps template is basically calling for many of these problems to occur. El Grafo (talk) 13:41, 6 July 2022 (UTC)[reply]
I've added a key to the Southern Tas static map (on right). How does this look? --SHB2000 (talk | contribs | meta.wikimedia) 11:24, 9 July 2022 (UTC)[reply]
But unfortunately, I have to agree with El Grafo that our region maps are at the very least, unreadable and awful-looking. If I had to design a static map from the start, this is not the way I would do it, but unfortunately the community is unwilling to accept that, in this very day and age, dynamic maps are far superior to static maps. There are few people who can edit static maps in the first place, and the two only editors (excluding myself) that I'm aware of who have even edited in the past month are Shaundd and SelfieCity. The only reason I'm making these maps is because our policy favours static maps in region articles but otherwise I think we need to revamp the region maps template. --SHB2000 (talk | contribs | meta.wikimedia) 12:15, 9 July 2022 (UTC)[reply]
I know this is a minor point, but I like the color scheme you are using. It feels just the right amount of trendy/modern/not outdated. WhatamIdoing (talk) 18:11, 9 July 2022 (UTC)[reply]
I do like the lighter colours in the color scheme though. From Template:StdColor, T1, T6, T8 and T9 feel a bit too dark (hence what's causing these problems), but a static map does look very nice if the right colors are used. So far, my favorite has to be the map I made for Southeastern New South Wales, and I've been trying to make more maps like that. --SHB2000 (talk | contribs | meta.wikimedia) 04:37, 10 July 2022 (UTC)[reply]
Hi SHB2000, I think it's fine if you want to experiment a bit use different colours and distinguish motorways. I did motorways differently for a while on maps I drew but eventually stopped because I felt it was more detail/clutter than benefit and it became another colour that had to integrated with the colour palette (which didn't always work).
I also agree with the others above that our standard colours don't always work. I ended up moving away from them so I could get a better contrast between the region colour and the text (improves readability quite a bit). -Shaundd (talk) 07:05, 13 July 2022 (UTC)[reply]
The problem may be that our regional map template colors were not originally designed to accommodate details like roads. They work fine for plainer regional maps like New York (state) or Massachusetts. Powers (talk) 20:34, 15 July 2022 (UTC)[reply]

Ground Zero (talk) 12:21, 23 August 2022 (UTC)[reply]

Retrieved from "https://en.wikivoyage.org/w/index.php?title=Wikivoyage_talk:How_to_draw_static_maps&oldid=4506837"