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)

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)
(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)
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)
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)
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)
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)
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)
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)
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)
Well, let us know if you get an answer from the OSM folks. LtPowers (talk) 01:53, 26 February 2013 (UTC)

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)

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

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)

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)

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)

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)

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...

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

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)

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)
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)
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)
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)
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)
@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)
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)
Thanks for the hint, I changed the hover text. -- Joachim Mey2008 (talk) 09:14, 16 January 2014 (UTC)

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)

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)

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)

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

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)

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)
@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:
  • In order to use the switch tag, you need to be able to modify the XML source, that means svg files become more complex. What do you think about? --Nastoshka (talk) 11:05, 3 April 2015 (UTC)
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)

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)

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

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)

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