Custom Color Ramps For ArcGIS

Back in 2012 I wrote a post about loading custom color ramps into ArcGIS. It’s been a consistently popular post but is very outdated. In that post I suggested downloading and installing ESRI’s ColorRamps2.o package. ColorRamps2.0 was replaced with ColorRamps3.0 around the time I wrote the post. Today, although there’s a link to download ColorRamps3.0 it doesn’t seem to be functioning.

Instead of simply updating an old blog post, I thought it would be helpful to write an updated post. I’ll show you how to create color ramps on the fly in ArcGIS and how to import custom color ramps into ArcGIS 10.5. I’ll also provide a list of color ramp creation and download sources.

If you already have a color ramp .style file, you can follow the steps below to add them into ArcMap:

  1. Copy the .style files to C:\Program Files (x86)\ArcGIS\Desktop10.5\Styles. Your Styles will be different depending on your operating system and version of ArcGIS.
  2. Open ArcMap.
  3. Click the customize dropdown and select Style Manager.
  4. On the right side of the Style Manager click on the Styles… button. At this point your custom style name should just show up in your style manager. However, if it doesn’t because you put your style file in a different directory or some other reason, you need to follow two more steps. First, click Add Style to List. Navigate to the directory where you placed the .style files and select your custom file. Highlight the file and click Open. You will have to do this for each .style file you want to add.
  5. After all of the styles are shown in the Style References list, make sure they are check marked and click the Set as Default List button.
  6. Click OK and you should see your styles on the left side of the Style Manager. Close the style manager. At this point you can go to the symbology tab of your Layer Properties for a given raster and select one of the new color ramps. If you want to see the text descriptions of the ramps, click on the color ramp dropdown and uncheck ‘Graphic View’.

So where can you find alternative .style files with color ramps? It seems to be getting harder to find them these days. As I mentioned above, you used to be able to get them from the ESRI mapping center but that resource seems to be abandoned. Let me know if you know where to find ColorRamps3.0 or 2.0 today. used to be another good resource but the site has removed the option to download ramps in the .style format. Fortunately, you can still access them by going to and downloading the zip file.

You can check out Fred Lott’s color ramps on GitHub too. Of course, if you aren’t finding quite the ramp for your needs and you’re trying to show quantities, you could always build your own.

To set your own quantities ramp for your layer, follow these steps:

  1. Right click on your layer and go to the symbology tab.
  2. Click on Show Quantities and select Graduated Colors.
  3. Choose your field’s value and normalization and how many classes you want your data broken into. Your classes will already have a color ramp assigned
  4. Double click on the first class symbol color. Choose another color that you want for the start of your custom ramp.
  5. Next, double click on the last class symbol color and choose the last color in your ramp.
  6. Right click on any of the symbols and select Ramp Colors. This will generate the color ramp between the top and bottom colors you chose.


So there you have it. If you’re not happy with what ESRI has already provided you for styles you have a few options for customization. If you know of any other style resources I didn’t mention, please feel free to let me know in the comments. Thanks for reading.


Five Things I Love About the ESRI Javascript API

Having worked with both the ArcGIS Silverlight and Javascript APIs I have to say Javascript has been much more fun. There is just something about working on the front end of a web map and being able to have it do so many amazing things. Here are my top five reasons I enjoy working with this API.

1. Your maps are device independent. Unlike the Flex and Silverlight APIs, Javascript and HTML5 can be viewed on almost any device. The obvious advantage here is that you can reach more people with your spatial data.  Of course having the ability to code for multiple devices means having to customize your code for different screen sizes which can turn into a lot of work. Check out this post from the Treehouse Blog for a great primer on responsive web design.

2. Plenty of code samples and live examples. Code samples are a great way to get your own map up and running quickly without having to figure everything out first. While the samples are not perfect they are a good way to discover map functionality that you might want to incorporate.

3. Support for a ton of layer and data formats. From GeoRSS and GeoJSON to KML and shapefile, this API pretty much covers it.

4. Well written API reference documentation. If you are going to use an API (any API) you want to be able to understand it so you can use it effectively. Good documentation is critical for this. The Esri JS API is (in my own humble opinion) extremely easy to read and understand. Each class has all the information you need to use it without having to decode any meanings. Furthermore, there are links from each class to samples that use it.

5.  Editing tools for online editing of SDE data. Let’s be honest, online editing through a web browser is not a great idea if you are trying to build accurate data. However, there is definitely a place for it. If you are trying to outline an area inhabited by a herd of elk or mark an area of weed infestation, browser editing is probably fine.  It is great just to be able to have this ability so more diverse mapping applications can be developed.

Wow, this list was a lot harder to write than 5 Things I Hate About the ESRI Javascript API. One reason is that there are other APIs out there that do a lot of what the ESRI API does (yes I am thinking about OpenLayers). Another reason is that as I write I think about things I would like ESRI to do better or differently. Oh well, you can’t have everything. Let me know what your thoughts are on the ESRI Javascript API – good or bad.

5 Things I Hate About the ArcGIS Javascript API

Building a mapping application with ESRI’s Javascript API is a lot of fun. But it can also be a real pain. Here are five things that absolutely drive me crazy when writing an ArcGIS Javascript map.

1. It is based on Dojo. It’s probably just my lack of Javascript programming sophistication but I find Dojo a little hard to work with. Although the API documentation has improved in recent versions, I don’t find it very intuitive. If you are a beginner or new to Javascript, the getting started documents are just plain frustrating. Ben Farrell thinks there are seven stages of learning Dojo including anger and acceptance. I’m not sure if there are really only seven stages but I can attest to the anger and acceptance.

2. It uses multiple versions of Dojo. Here I go again with the Dojo thing. Half of the developer samples on the developer’s site seem to be written pre version 1.7 while the others are post 1.7 and rely on the AMD module format.  I understand that version transitions of supporting libraries can be difficult but this is ridiculous. Since the ArcGIS API updated to version 3.6, many of the developer samples have been updated to show the AMD require format. Unfortunately, the transition has been slow and there is still a lot of mixed version code and a lot of live samples are broken. If you are going to upgrade to a new version of your API, let’s have things ready to go.  

3. No built-in label engine for dynamic, on-screen annotationIt seems obvious to me that the users of a map would want to mark it up with text; especially in conjunction with a draw toolbar. Apparently it isn’t obvious to the ESRI developers. Instead we are left to work with with the labelPoints function which uses the geometry server to create an unseen point and then puts a text symbol on top of it.

4. The label engine problem above leads me to my next gripe. The LabelPoints function doesn’t allow line breaks. That means that if you want to label a polygon with something like, oh say, area and perimeter, you have to have it all on one line or call the labelPoints function twice and use an offset. How about we get the ability to at least use a newline character (\n) and be done with it.

5. No out-of-the-box support for a table of contents. There is a lot of debate about whether an ArcGIS-like table of contents is a good thing in a web map. No matter what side of the debate you fall on, the fact is that people are used to using them and users often want the ability to turn layers on and off. There are a few projects out there that attempt  to solve the problem but each has its own limitation and problems.  It is a little surprising that ESRI doesn’t have a solution for this one yet. Or, maybe it isn’t really that surprising.

I have plenty more gripes with the Javascript API than the ones listed above but I don’t want to get too depressing. Also, I actually enjoy developing with the API (most days) and there are some great things about it. If you want to add to my list put it in the comments.