I was starting to look harder at the query operation in the ArcGIS Server REST API today to figure if I can leverage it to get specific results I needed instead of building my own REST services. The scenario I was looking at was to be able to get the records corresponding to the minimum and the maximum values in a given field. To provide an example, let’s say you have a ‘States’ layer with a field called ‘POP2008’ that contains population numbers for the year 2008. In this case, I want to obtain the state records with the minimum and the maximum population for the year 2008. At the outset, there didn’t seem to be a way to do it. After spending some time investigating the possibilities with the REST API query operation, I found that the above was in fact possible. Assuming that the FeatureClass name of the ‘States’ layer is ‘States_DTL’, the query below will produce the desired results.

POP2008 = (SELECT MIN(POP2008) from States_DTL) OR POP2008 = (SELECT MAX(POP2008) from States_DTL)

I was surprised to find out that I was able to use the name of a FeatureClass in the query. Agreed, the user of the REST API will/might not know the name of the FeatureClass. But the user could get lucky and be able to guess the name of the FetaureClass after ‘n’ tries. The FeatureClass / Table being used doesn’t even need to be a part of the MapService. I am not yet sure about how far this behavior can be exploited. Nevertheless, I found that this behavior was a little more than interesting.

Being able to flash a shape on the map is a nice usability feature in GIS applications to relate shapes on the map to attributes in a data table or data grid. Also, most GIS users have gotten used to the feature in ArcMAP. I had written up an extension method to the Graphic class in the ESRI Silverlight API to be able to do this easily with a simple function call. Here is the code for the extension method.

After including the above extension method in your project just call the ‘Flash’ method on the graphic object

graphic.Flash();

Note that I am using the Storyboard as the timer which is preferred over of the DispatcherTimer.

This has also been added to the ESRI Silverlight API Contrib project here.

I just added some utility methods to the ESRI Silverlight API Contrib project that do the following

1. Determine if a point is inside a polygon. Find the code here
2. Buffer a point in the WGS84 spatial reference system. Find the code here
3. Midpoint of two points in the WGS84 spatial reference system. Find the code here
4. Find the end point given an origin point with a distance and an angle. Find the code here

The above methods should help you avoid some HTTP requests back to the ArcGIS Server to perform these spatial operations. Thus reducing the load on your ArcGIS Server and also increasing the performance of your web application by sticking to Steve Souders’s performance rule number one even though this is a Silverlight client.

I have been working with Silverlight and in particular the ESRI Silverlight API recently and have been having a lot of fun with it. It is a refreshing change from working with the HTML/CSS/JS combo, even though I do miss the the simplicity and power of HTML/CSS/JS a lot of times. Silverlight brings with it a lot of capabilities that wasn’t possible with JavaScript. These capabilities in Silverlight can help simplify some of the workflows and increase the usability of some of the features needed in a lot of the web-based mapping applications. Like for example, one of the common requirements is for users to be able to view Shapefiles on their machines on the web maps.

With the JavaScript APIs, the only way this could be achieved was to upload the Shapefiles to the web server and then render the shapefiles either as images on the server that are sent down to the browser or as SVG/VML in the browser. Well, this is where the power of Silverlight helps us simplify things by allowing us to open and read the shapefiles in the Silverlight plug-in of the browser itself. This eliminates the need for uploading the shapefiles to the server and thus simplify the workflow involved.

There are a lot more things that the Silverlight plug-in is capable of that a lot of web-mapping applications can use. The ESRI Silverlight API packs a lot of punch but there are still a lot more holes to be filled. So, to help fill those holes, I have started an open-source project on CodePlex where I have uploaded some of the useful things that I have been working on. Please find the link to the project below.

ESRI Silverlight API Contrib

The project currently contains the following features.

1) A custom GeoRSS layer type that can be added to the ESRI Silverlight API map.

2) An custom map layer where the image is created dynamically in the browser itself. The current layer regenerates the image for the layer multiples times a second to simulate ripples on the map.

3) Utility classes that will help users load shapefiles from their computer directly on to the Silverlight API map without uploading the shapefile to the server

Please download and use the project as you see fit. Even better, you can sign-up as a contributor and help grow the project and the codebase. I also welcome any and all inputs on other ideas for new features that you might want to see added or critiques of the current codebase.

Target of databinding in Silverlight “HAS” to be a “FrameworkElement” and not just a “DependencyObject” like in WPF. I am not sure that there is a reason why databinding to “DependencyObject”s in Silverlight is explicitly omitted by Microsoft. Seems like it might be an oversight. But even after many people have complained about it in the forums, the databinding to “DependencyObject”s feature doesn’t seem to be included in the beta version of the latest Silverlight 3 library.

So, what does that mean"? Where does it really become a limitation? Well, it really does limit our options when trying to databind values to the “Transform” classes like the “RotateTransform”, “ScaleTransform”, “SkewTransform”, “TranslateTransform” etc. Let’s say that you are symbolizing your points as an Ellipse or a Rectangle, and you want to be able to size your symbols based on some value in the Attributes collection of your Graphic. The best way to do this would be to apply a ScaleTransform on the Ellipse or Rectangle (on the RenderTransform property) and databind the attribute values to the ScaleX and the ScaleY dependency properties of the ScaleTransform. But since the ScaleTransform is only a DependencyObject and not a FrameworkElement, we cannot bind to the ScaleX and ScaleY properties of the ScaleTransform. This scenario can easily be solved by binding to the Width and Height property of the Rectangle or Ellipse. But there are a lot of other scenarios that cannot be overcome as easily. Like for example, you will not be able to label along a line by databinding to a RotateTransform on a TextBlock for example. Also in the ESRI Silverlight API, we cannot apply a TextSymbol to a polyline or polygon geometry.

At this year’s ESRI dev summit, ESRI was showing off how the performance of the JSON output generation by the ArcGIS Server REST API is going to be much faster. I was curious as to how this could be since it is the same JSON that is being generated. The answer turned out to be pretty simple. Here is how JSON is generated today

As you can see from the image above, at 9.3 the ArcGIS Server REST API does the work of reading (deserialize) the JSON sent in from the client (browser) over HTTP and converts (serialize) that appropriately into a SOAP message. This SOAP message is then sent over DCOM to the ArcGIS Server 9.3. The ArcGIS Server then converts the SOAP messages to ArcObjects types and does the work it needs to do. When the work is done, the ArcObjects types are converted back to SOAP and sent back to the REST API. The REST API then converts the SOAP types back to JSON and then sends the JSON results back to the client(browser).

In the 9.4, the JSON is going to be generated at the ArcGIS Server itself and thus avoiding a lot of serialization & deserialization to and from SOAP / JSON. Avoiding these intermediary data conversion steps are the primary reason for the increased performance of JSON output in 9.4.

A couple of weeks ago I had written about how the different axis ordering that can be defined in EPSG coordinate system standards makes the lives of any GIS software provider that wants to implement these standards a whole lot harder. Today, I came across some information that really doesn’t make any sense to me. Previously Morten had written about EPSG finally getting around to adding the web mercator to their standards with the EPSG code “3785″. But in February, EPSG decided to change the EPSG code from “3785″ to “3857″. Look at the change request info in the image below. That information can be obtained at http://www.epsg-registry.org.

Also, as you might have already heard, OGC had accepted KML as an OGC standard sometime last year. The KML standard includes its own method of defining styles/symbology for 2D & 3D features along with other things. But OGC in fact already had its own existing standards for defining 2D feature styles/symbology in map layers called the Styled Layer Descriptor (SLD).

Now, the OGC has two standards to define features styles in XML which really kind of makes it a double standard.

Now, from what I read, the OGC is working on combining both those standards into one. Which is going to be a tough job since there are so many overlaps between KML and other existing OGC standards.

The support for transparency in PNG images in Silverlight is to say the least really bad. Here is what the Microsoft docs says about PNG transparency support in Silverlight

Silverlight does not support all possible color depths that are included in the PNG specification. The following are the PNG color depths supported in Silverlight:

• Indexed color: 1-bit, 4-bit, or 8-bit color depth (per channel).
• Truecolor: 24-bit color depth, or 32-bit color depth (per channel) for truecolor plus alpha.

Notably, gray scale (with or without alpha), and 64-bit truecolor, are not supported in Silverlight.

Note that they don’t mention anything about the support for 1, 2, 4 and 8 bit PNGs. This creates some problems when using the ESRI Silverlight API and you might what to keep your eye out for it and pay good attention to how your map caches are being generated. Look at the results when I overlay ArcGIS Online’s Transportation layer on top of the Imagery layer in the ESRI Silverlight maps.

<esri:Map x:Name=“MyMap” Grid.Row=“1″ Grid.Column=“2″>

<esri:Map.Layers>

<esri:ArcGISTiledMapServiceLayer

ID=“StreetMapLayer”

Url=“http://server.arcgisonline.com/ArcGIS/rest/services/ESRI_Imagery_World_2D/MapServer”/>

<esri:ArcGISTiledMapServiceLayer

ID=“mapLayerTransportation”

Url=“http://server.arcgisonline.com/ArcGIS/rest/services/Reference/ESRI_Transportation_World_2D/MapServer”/>

</esri:Map.Layers>

</esri:Map>

And here it what the map look like. As you can see, the the tile areas outside the continental US are grayed out.

Also, check out this Silverlight forum post where Morten schools Microsoft about the issue mentioned above.

Support for creating generic classes in XAML is still lacking. The only XAML element that lets you specify the generic type argument is only the root element of the user control. I couldn’t find any way to create an instance of a generic class in XAML yet. One had a class called “NameValue” in the project and wanted to be able to create an ObservableCollection<NameValue> in XAML. The only way I was able to do it in XAML was to create another empty class called NameValueCollection that inherited from ObservableCollection<NameValue> and then create an instance of the “NameValueCollection” in XAML instead.

public class NameValueCollection : ObservableCollection<NameValue>
{
}

I think one way generics could be supported in XAML is by creating new MarkupExtensions for that purpose.

This is something that I ran into a little while ago. I had a property called “Name” in one of my Silverlight classes that was getting created in XAML. When I created the class in XAML all the properties on the class got applied as set in XAML except for the “Name” property. As usual, I assumed I was doing something wrong and was trying to figure out where i messed up. After, trying to debug this for a while and loosing my self-esteem as a developer, I realized that Silverlight just doesn’t like setting the property called “Name” in XAML. It works fine when you set it in code. It is just XAML that messed with my head for a little while there. So, avoid the mistake I made and retain some sanity.