We need to display a map legend that shows ranges of pipe diameters. Currently we have something like this:

Current legend

The problem with this is that the edge cases are ambiguous. Does 50mm fall in the first or the second category? We could do something like this:

Possibility one

Even though this reduces the ambiguity, some still remain. In which category is 50.5mm?

Anyone have a good solution for this? Our users are not engineers or mathematicians, so interval notation would not be an acceptable solution.

5 Answers 5


The specific answer to your question is to go with the first solution. That is the standard cartographic convention, effectively eliminating the question of where, say, 50.5 goes. As far as where the exact category breaks go (say, precisely 50), it doesn’t matter. Users understand that that the categories are functionally fuzzy. For example, obviously 49.999 is one category while 50.001 is another, but users realize that that the two are practically the same. As far as they’re concerned, “50-ish” pipes, including pipes exactly 50 mm in diameter, can be in either category.

The more broad answer to your question is that if you’re worried about ambiguity of your category divisions, then you need to change your category divisions. Cartography texts recommend that you break your categories at meaningful points for your users –make divisions related to the users’ tasks or decisions. It may not be necessary for the categories to have neat regular intervals. If your users really need to know if a pipe is exactly 50 mm, then maybe that should be a category of its own. User research will help determine the meaningful categories and breakpoints. How do you users group pipe diameters into operationally “similar” versus “different”? I suspect the roughly exponential scale you’re using now is supposed to reflect this, but is it based on actual user research?

For example, you could put the breakpoints at natural places of low data -diameters that characterize relatively few pipes. I would expect there are industry standard pipe diameters, so you make sure no standard diameter is right on the division between two categories. Now there's virtually no ambiguity because there are virtually no pipes to be be ambiguous about. If there are no standards, then find out what diameters exist in the field. Given a statistical distribution of pipe diameters, cartography has mathematical formulas to create categories with minimal variation within each category and maximum variation between categories.

On the other hand maybe pipe diameters gradually grow and shrink over miles of pipe (not very likely, I would think, but it could characterize, say, daily flow volumes, or river sizes). Then maybe your existing divisions are fine. Where is precisely 50? Precisely where the 0-50 code changes to 50-100, implying the diameter goes up in one direction and down in the other. Alternatives to your categories would be equal intervals, nested means, equal progression (e.g., a true exponential, but there are other algorithms too), or categories with equal statistical frequency. Which one you use depends on the results of your user research.

For an introduction to cartography, I recommend the classic Elements of Cartography, by Arthur Robinson et al, now in its 6th addition (1995). I expect there are other excellent texts of more recent vintage that specifically cover electronic maps.

  • Great answer, this addresses the core of the problem Commented Jul 31, 2012 at 13:18
  • As for electronic maps, I've not found anything useful even in the British Library, there is a book from the 90s but that doesn't even deal with tilemaps... I always bugged Astrid (the designer of Nokia maps) that we should simply write one :) (I even started its base...)
    – Aadaam
    Commented Jul 31, 2012 at 13:52

How about a solution like this:

enter image description here


enter image description here

Compare it with this:

enter image description here

The reason why there is no sense of ambiguity in all these 3 examples, is because you don't mention the limit twice. You don't say: 0-50 / 50-100 / 100-200 /... you just mention 0 - 5 - 100 - 200 -...

  • 1
    Looking at the chart 50, 100, 200 and 1000 would be identified as white. Commented Jul 31, 2012 at 10:40
  • 2
    Nice, but edge values are still ambiguous? Commented Jul 31, 2012 at 13:12
  • @Android Hustle: This is just a quick and dirty mockup. You could replace the white space with a black dash. Commented Aug 1, 2012 at 5:33
  • I updated my answer. Both are just quick and dirty mockups of course. The values are absolutely not ambiguous in any case. You read from left to right. You start with 0 and as soon as you hit 50, 100, 200,... you get a new value. Commented Aug 1, 2012 at 5:42
  • 1
    Indeed, this is the standard cartographic convention.
    – User 1
    Commented Aug 1, 2012 at 6:56

I've faced similar issues with speed legends on a map system I work on. I finally came to rest with your latter method, however the developers added a tool tip so that a specific piece of road's speed can be seen when hovering. This allows the users to pinpoint exactly where they need to know the pipe size (in your case) and covers you for complicated junctions or transitions between the two.

  • That's a nice solution!
    – Aadaam
    Commented Jul 31, 2012 at 10:40

I don't know about you, but I'd denote pipe diameters with line width rather than colors... it's somehow more logical

What about using textual notation, with the English construct "between"?

  • lightblue - less than 50 mm
  • blue - between 50 mm and 100 mm
  • navy blue - between 50 mm and 100 mm
  • etc

It's a bit longish, but it could be shortened.

You know, it might be true, that a picture is worth a thousand words, but it's a scientific fact that a well-chosen word is worth a million ill-chosen icons.


I'm not removing the last sentence for historical reasons, but let's have another phrasing then: if you can only describe it in words but no pictures, use words.

And let's add Raskin's argument here from The Humane Interface, Chapter 6.3: Icons, http://bit.ly/NTCrCz - where you can find the details on how labels are better instead of desperately searching for a different representation.

And there is a counter-argument as well, in Jeff Johnson's ingenous Designing With the Mind in Mind's Chapter 4: Reading is Unnatural, equally supported by science

They don't really contradict each other, it's just the two sides of the same coin. Words are recognized in one chunk for accustomed readers (which most of the people in office jobs are), therefore Johnson doesn't argue about using a single word when you can't find a good icon, he's arguing about using lengthy text instead of some visual metaphor.

  • I like your idea, but how would you word it so edge values are not ambiguous? It's still not clear in which category 50mm falls. Commented Jul 31, 2012 at 13:12
  • I guess it is, I mean, less than 50 mm is up until 49.99999 I guess, and 100 mm isn't between 50 and 100, it's between 100 and 500. Or you could say, "at least 50 but less than 100", if it's clear
    – Aadaam
    Commented Jul 31, 2012 at 13:45
  • Taking the term "scientific fact" kind of lightly, aren't we? :) Commented Aug 1, 2012 at 6:09
  • @VitalyMijiritsky: Actually, not. Refer to Chapter 6.3 of Jeff Raskin's book ( bit.ly/NTCrCz ) where he cites studies conducted by Mayhem, et al, or do an A/B testing, or visit large e-commerce sites, like Expedia. Count the number of icons without explicit, non-hover labels next to them, where it actually matters in revenue. It's surprising that the myth of the icon still lives through after debunked 20 years ago
    – Aadaam
    Commented Aug 1, 2012 at 8:50
  • I was thinking along the same lines, phrasing the intervals rather than describing them merely by numbers. And I would vote this up if it wasn't for that last sentence, it just hurts my eyes too much to see where the up arrow is. Commented Aug 1, 2012 at 8:52

The issue is not the labels, the issue is the fact that you use a discrete scale I think.

If you'd like to solve it using the labels only, you'd have to use symbols like ≤ and ≥ with the labels to precisely identify what you mean. So, you'd get this:


download bmml source – Wireframes created with Balsamiq Mockups

I don't think that that is a very useful solution though. The labels would be harder to comprehend. Instead, you could considder using a continious scale. So, not one blue line piece with two labels, but a continous gradient from blue to red in your case (via as many colors as you need). You can add simple lables to that to indicate values along that scale, in the way Bart Gijssens suggests. The labels would no longer be ambigous, as they would only indicate a value along a continious scale, and not indicate a cutoff point at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.