We are pleased to announce the beta of Drone2Map for ArcGIS is available from the Early Adopter Community. With Drone2Map, you have the power to take imagery direct from a drone and create stunning imagery products the same day it … Continue reading
With the help of our user community and partners, Esri is curating an immense and rapidly growing collection of ready-to-use maps, imagery, and geo-referenced data for the world. This online collection of authoritative content, together with the new Web GIS … Continue reading
The World Topographic Map and World Imagery Map have both been updated with new content! As part of ArcGIS Online, Esri’s Basemaps support a vast GIS community. Thank You to our Contributors and Partners who help support the Living Atlas of the World by providing data and enriching these … Continue reading
This has been a very busy month for the ArcGIS Imagery and Remote Sensing team at Esri. If you’ve been a fan of Esri imagery technology for a while, you’ll realize we’ve modified the name. Yes, we have renamed our team … Continue reading
Weather is a factor that can seriously impact your business, and having accurate information in a timely manner can help you make better decisions. We have a special presentation, AccuWeather: Weather, GIS and Big Data, planned this year at Esri … Continue reading
One of the advantages to working at Esri is the access to so many people resources to help answer questions. The other day, I was writing a blog about the new Landsat 8 imagery available through ArcGIS Online. I wanted … Continue reading
What does Landsat 8 have to do with Earth Day? Well for one thing, the latest Landsat 8 satellite imagery is some of the coolest imagery you can access, with remarkable images and information about the Earth being updated daily. … Continue reading
There’s a wide variety of tools (some new with the build 1500 release) and properties available for you to adjust and enhance raster files and image services you use in ArcGIS Explorer Desktop. Here’s an overview of the tools and properties available, and how you might use them.
Local raster files
To add a local raster file click Add Data, then chose Raster Data as shown below:
ArcGIS Explorer supports the display of many different raster formats, including: IMG, BMP, JPEG, PNG,TIF, MrSID, and many more. You can find a full list of supported image formats in the help.
Once you’ve added a raster it will appear in your contents. This one we’ve chosen is an RGB file and has a black area of “no data” around it.
We can remove the unwanted black area by setting the RGB transparency value for the image. Specify the value, then check the box to set that value transparent. Note that all pixels with your specified RGB value will become transparent.
Here’s the image after setting the transparent value to RGB 0 0 0:
With the raster layer selected in your contents, you can click the Tools tab where you will find the Transparency, Enhance, and Swipe tools in the Effects group:
Enhance was newly added with the release of build 1500, and can be used to adjust gamma, contrast, and brightness.
You’ll find more details in the control layer appearance help topic.
Image services are new with ArcGIS Server 10, and provide access to raster (and image) data through a Web service. The source of the raster data can be a raster dataset from a geodatabase, a file on disk, a mosaic dataset, or a layer file referencing a raster dataset or mosaic dataset. Publishing a mosaic dataset as an image service requires the ArcGIS Server Image Extension. Once you publish the raster data to your server, you can use the resulting image service in ArcGIS Explorer Desktop the same way you would add any other GIS service layer.
When you connect to a GIS server that publishes image services, you’ll see them shown with a unique image service icon like that shown below for the Davidson_County image service:
The same Effects tools described for local rasters above apply to image services.
You can set other image service properties by selecting the image service layer in contents, right-click to view the layer properties, and then choose the Image Service category as shown below:
Image service properties can be used to interact with the server, allowing you to specify a variety of image properties and options. The properties do not change the image on the server, but rather control how it is sent from the server and subsquently how it is displayed in ArcGIS Explorer.
Transmission compression allows you to change the image compression – more compressed image services will be quicker to display, but will affect image quality. There are more options for resampling and mosaic method, all discussed in detail in the specify properties for an image service help topic.
Server object extensions (SOEs) are a way that you can extend ArcGIS Server to run your own ArcObjects business logic. The nice thing about SOEs are that they are not application-specific; you can write one SOE and attach it to multiple services. You can also expose your SOE as a SOAP or REST Web service, a topic on which we’re preparing some future posts.
In today’s post, we’ll explain how to work with optimized map services when you’re writing an SOE. By “optimized map services”, we mean ArcGIS Server map services that are based on map service definitions (.msd files). This is the type of service that you get when you work with the Map Service Publishing toolbar in ArcMap. Optimized map services use a faster drawing engine than the traditional, MXD-based map services, so there are benefits to writing your SOE to support them.
Because optimized map service use a completely different drawing engine and source file than MXD-based services, they draw very quickly. However, this also means that they do not support full ArcObjects access from the Carto library. When working with optimized map services, you cannot use any ArcObjects directly related to the map document, such as IMapServerObjects, IMap, ILayer, and IFeatureLayer.
It turns out you can still do quite a few things when you use an optimized map service with your SOE. This post explains what objects are available, and how options have increased with ArcGIS 10.
What you can do
The Carto library contains a MapServer class that represents the map service. There are a number of supporting classes and interfaces surrounding MapServer that give you information such as the layer names, whether the service has a cache or not, and how queries should be performed with the service.
On page 6 of the .NET Carto object model diagram, you can see these classes and interfaces. You can use them with any type of map service, whether the source map is an MSD or an MXD. Avoid using other classes in the Carto library with optimized map services.
Getting to the source data at ArcGIS 10
At ArcGIS Server 10.0, the MapServer class implements a new interface IMapServerDataAccess, which allows you to access the data sources of the layers in your map. Using the GetDataSource method on this interface, you can access the IFeatureClass, IRaster, or ITable interface of the underlying data.
The typical pattern is to use the MapServer-related classes and interfaces to discover the layer names and indices in your map service; then use IMapServerDataAccess to get to the data beneath. Once you obtain the source data, you can do many things with it using ArcObjects, such as opening feature cursors or topological operators. You’re safe as long as you avoid the above-mentioned MXD-specific classes from the Carto library.
Here’s an example that gets the source feature class for a map layer named “States”.
string mapLayerToFind = "States";
//Access the map service and its layer infos
ESRI.ArcGIS.Carto.IMapServer3 mapServer = (ESRI.ArcGIS.Carto.IMapServer3)serverObjectHelper.ServerObject;
string mapName = mapServer.DefaultMapName;
IMapLayerInfos layerInfos = mapServer.GetServerInfo(mapName).MapLayerInfos;
// Find the index of the layer of interest
int c = layerInfos.Count;
int layerIndex = 0;
for (int i = 0; i < c; i++)
layerInfo = layerInfos.get_Element(i);
if (layerInfo.Name == mapLayerToFind)
layerIndex = i;
// Access the source feature class
IMapServerDataAccess dataAccess = (IMapServerDataAccess)mapServer;
IFeatureClass fc = (IFeatureClass)dataAccess.GetDataSource(mapName, layerIndex);
The above code gets all the layer information for the map service. IMapLayerInfos and IMapLayerInfo are legal to use because they do not require access to a map document; they just help you get information that the service exposes.
The code then iterates through the layer infos until it finds the index of the layer named “States”. That index is then passed into IMapServerDataAccess.GetDataSource(). At this point you’ve reached your goal of accessing the source data interface IFeatureClass.
For brevity, the above example contains no error handling; but you might want to add a check that IMapLayerInfo.Type is equal to “Feature Layer” before you go casting the result to IFeatureClass.
Registering SOEs that support optimized map services
When you register the SOE, you must also set a property defining that the SOE supports optimized map services. This property is called SupportsMSD and it is a Boolean. You have to set it to True in order for your SOE to show up in the list when you publish an optimized map service.
If you’re following the .NET SOE samples out of the SDK, you’re probably registering your SOE using a console application that calls IServerObjectAdmin2.AddExtensionType(). In this application, you set the properties of your server object extension. Here’s an example of how you’d set up the properties to support optimized map services:
IServerObjectExtensionType3 serverObjectExtensionType =
// Set properties for the SOE
serverObjectExtensionType.CLSID = "MySOE.MySOE";
. . .
// Register the SOE with the server
Notice the call to IServerObjectExtensionType3.Info.SetProperty() that sets the SupportsMSD property.
If you’re developing a Java SOE, the SupportsMSD property is not set at registration time. Instead, you set it directly in the SOE source code using Java annotations. When you later register the SOE, the property is forwarded to ArcGIS Server.
In summary, when using optimized map services with SOEs, you can do quite a bit if you stick to the MapServer-related classes. Also, with ArcGIS 10, you can use IMapServerDataAccess to access the source data for the layers in your map. From there you can do many things to work with the data directly.
Contributed by Sterling Quinn of the ArcGIS Server software development team
One of the most common questions we receive about Web map design is how to display imagery base layers. Specifically, is it better to use an image service, or a cached map service containing the imagery?
As with most Web map design questions, the answer is: “It depends on the purpose of your application”. In general, if the purpose of the imagery is only for visualization on the Web, putting the imagery in a cached map service is the most responsive and scalable solution. Other factors to consider include the required functionality, and maintainability of the application.
First, let’s address the responsiveness, or speed, of the imagery. Under any circumstance, it’s pretty hard to beat the responsiveness of a cached map service. In a head-to-head footrace to produce one view of the map, an image service may get close. This is especially true when using low-bandwidth Internet connections, because the cached tiles consist of multiple files whose imagery payload inevitably extends beyond the boundary of the screen. An image service, on the other hand, produces one image whose extent matches that of the current map view.
Cached services really hold the speed advantage when panning, largely due to browser caching. If a tile or a portion of a tile has already been fetched, it doesn’t have to be requested again from the server. An image service, in contrast, makes a new request on every pan.
No matter how fast an image service can produce an image, ArcGIS Server (specifically, the Server Object Container) still has to do work to make it happen. The cached map service, on the other hand, does virtually no work on ArcGIS Server. After you make an initial “handshake” with ArcGIS Server to determine whether a cache is available, the Web server just hands you the tiles you want. This is decidedly more scalable than an image service once your application reaches a particular threshold of users. That threshold depends on the processing power of your server and the pattern of requests.
The aforementioned browser caching also reduces the work of your Web server and contributes to the superior scalability of cached services.
An advantage of image services is that they are decidedly more functional than cached map services. When working with an image service, you can request a custom projection, image format, resampling technique, band combination, and so on. If your application requires one of these things, an image service may be a better choice.
Image services also let you specify a compression value that can be helpful over low bandwidth networks. You can set a very high compression for quick navigation; then, when you reach the imagery you want, you can reduce the compression to get a better quality image.
You can perform simple queries on either an image service or a cached map service. Queries are possible with cached services because the cache acts as a visualization mechanism only. The administrator can leave the back-end data on the server if end users will need to issue queries to the map service.
For all its performance benefits, caching comes with some overhead. You need time and server power to create the tiles, and hardware to store them. You also need to perform cache updates at some interval to prevent your imagery from becoming stale. If your application offers imagery for a vast area at large scales, you may decide that the excessive work required to build and maintain the cache outweighs the performance benefit.
If you find yourself in this situation, you should ideally perform load testing to understand if the performance of the image service is suitable for your purposes. If the image service is not going to work, you may consider only caching strategic places (such as urban areas) at the largest scales, and displaying uncached areas with a “Data not available” tile. This is the approach used by Bing Maps, Google Maps, and many other Web mapping services that offer large amounts of imagery.
Another option for filling uncached areas is to create tiles on demand. Beware that this requires you to keep the source imagery on the server, and it can introduce scalability issues if you have not sufficiently pre-cached the most popular areas of your map.
In summary, if the purpose of your imagery is only for visualization as a base layer and you expect moderate to high amounts of traffic on your site, you should attempt to use a cached map service for the imagery. If you want to expose analysis and manipulation of the imagery and you don’t feel that your server will be overwhelmed by concurrent requests, use an image service.
Contributed by Sterling Quinn of the ArcGIS Server development team