Generics support in XAML
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.
Avoid using properties called “Name” in your Silverlight classes
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.
Extreme makeover – ESRI Silverlight API edition
One of the good things about the custom controls in Silverlight is the fact they can be styled any way seen fit by designers without any intervention by developers at all. This gives developers a really good clean way of working with designers simultaneously. All the designer needs to be aware of are the template parts that make up the custom control and they can be on their way to designing it and animating for the various states defined in the custom Silverlight control and provide animations for transitions between states. The documentation for the ESRI Silverlight API Navigation widget template part is not there yet but that shouldn’t necessarily hold you back. Microsoft Expression Blend will get you on your way styling it any way you like. The default look of the navigation widget didn’t get us too excited about it. So, we had our designer re-work the looks of it and here are the before and after pictures.
 |
 |
 |
|
Before |
After |
I am excited to see what others will start doing with it.
Template for creating Server Object Extensions
I had created a multi-project C# Visual Studio 2008 project template and having been using it for a while now for creating solutions for creating Server Object Extensions for the ArcGIS Server. I managed to package it into a Visual Studio Installer that I have made available for download below(click image below).
Just double-click the file after downloading and it should install the project template into the correct directories. The installer will throw up a warning message before installing it. But you should be able to install by saying it is okay to proceed. Or if you want to heed to the warning, then you can also SOE Visual Studio 2008 project template and copy it to the “[My Documents]\Visual Studio 2008\Templates\ProjectTemplates\Visual C#” folder. You will have to check the “Register for COM interop” option in the properties page of both the projects that will be created. But I would suggest that you create a install project to COM register the assemblies at the deployment location instead of registering them at the “bin\Debug” location of the project. The project template will add a custom action class in both the projects that can be used in the setup & deployment projects to do the COM registration.
The SOEXplorer utility should help you register and un-register the Server Object Extensions with the ArcGIS Server.
Note: The support for creating multi-project templates is not great. For e.g. there is no way to use variables defined in the multi-project template file in the individual project template files.
Supporting IE8 for your JS API applications
Microsoft released Internet Explorer 8 sometime last week. Now, for all the web developers out there (which includes me), this means that they will have to support another browser for their applications. If you have been building your mapping application using the JS API or have some JS API applications in production, there is a little trick that you can currently do to ensure that your applications work fine on IE8. Just add the following META tag in the HEAD section of your web page
<meta http-equiv=”X-UA-Compatible” content=”IE=7″ />
This forces IE8 to render your pages in IE7. This might be a good fix until the JS API and your web applications can be written for / tested for IE8. I picked up this little trick from the JS API developers themselves at the developer summit. Check out this “A List Apart” link for more details.
Reversed co-ordinate axis order for EPSG:4326 vs CRS:84 when requesting WMS 1.3.0 images
I spent quite a bit of time last week over this and thought it might help others who might encounter the same thing as I did. I was requesting images from the WMS service version 1.3.0 in ArcGIS Server and everything was fine as long I was requesting images with the “CRS:84” value for the co-ordinate reference system. According to the GetCapabilities document returned from the WMS Server, both the “CRS:84” and the “EPSG:4326” values are suported by the WMS server.
But when I started requesting images with “EPSG:4326”, I was seeing some really weird behaviour. I spent quite a bit of time trying to figure out what was going on without luck. The OGC team at ESRI helped me out and pointed out that when using WMS 1.3.0, the co-ordinate axis order in reversed for CRS:84 and EPSG:4326. So, when requesting images in CRS:84 use the coordiate axis order of (long, lat) and when using EPSG:4326 use the (lat, long) order.
But when requesting images from WMS Server version 1.1.1 with EPSG:4326, we should still use the coordinate axis order of (long, lat)
Do these standards really help when the standards are not really STANDARD?
Then comes the issue of versioning of these standards, especially the OGC standards. The OGC standards are so reliant on one another that the different versions that exist in each standard actually adds a lot more complexity to systems that actually use them. For example, the SLD 1.1.0 standard (Styled Layer Descriptor) depends on the FE 1.1.0 standard (Filter Encoding), the SE 1.1.0 standard (Symbology Encoding) and the GML 3.1.1 standard (Geography Markup Language). As and when the standards evolve and higher versions are created, the versions of the standards they in-turn depend on change making a big mess for the systems that actually have to implement these standards.
Options for solving the problem of a graphics layer for the web
I realize that most people developing web mapping applications have already solved this problem one way or the other. But some solutions are better than others for certain scenarios and needs to be paid attention to. I also want to mention that there are numerous other ways that this can be accomplished, but I am going to limit this post to the ones that I think are the good ones. The graphics layer can really be maintained at three different tiers the client (browser), web server, ArcGIS Server. Here are some notes and observations on each
Client(Browser) – When the graphics layer is maintained on the client-tier, it is drawn by the browser as VML/SVG depending on if you are using Internet Explorer / FireFox etc. In the case of the Flex and the upcoming Silverlight mapping controls, the graphics would be drawn as the corresponding framework’s graphic elements. The geometries of all the graphics are pulled from the ArcGIS Server to the browser (REST API).
Pros:
- To identify any feature on the graphics layer, a round trip to the Web or the ArcGIS Server is not required.
- The feature symbology/styles can be changed without a round trip to the server.
- The graphics layer can be more interactive, like highlight feature on mouse over etc.
Cons:
- The drawing performance can be slow when trying to draw large number of features in the graphics laye. The performance in the case of Flex and Silverlight controls will be better than the drawing performance of SVG/VML DOM elements.
- You could be drawing only a few features (ploygons/polylines), but each of those features might have a large number of vertices. Imagine drawing county boundaries with thousands of vertices.
- When drawing large number of features, large amounts of data (relatively) is pulled in by the client (browser).
Web Server – When the graphics layer is maintained on the Web server, it is drawn by the ElementGraphicsLayer or the FeatureGraphicsLayer classes in the Web ADF. These classes use GDI internally to create the graphic layer map images. These classes create images that are then sent down to the browser to be overlaid on top of the map element. Non-ESRI solutions can use the SharpMap project to create the graphic layer map images.
Pros:
- Can draw large number of features relatively fast. Again drawing exorbitantly large number of feature can still make it slower.
- Features can be organized into layers and easily styled using the available renderers like UniqueValueRenderer etc.
Cons:
- Less interactive since highlighting features on mouse over will need a trip back to the web server.
- Identify operations will need a trip back to the web server.
- Style changes need trip back to web server.
- The web server’s session storage and thus the memory could get overloaded.
ArcGIS server – There are many ways by which you could have the ArcGIS Server handle the drawing of the graphic features for you. But I am only going to discuss the cleanest of them all. In this case, when the graphics layer is drawn on/by the ArcGIS Server, the features and their symbology are passed onto the ArcGIS Server to be drawn using the ExportMapImage method in the SOAP API. The MapDescription argument of this method contains an array of GraphicElements that will be drawn by the ArcGIS Server.
Pros:
- The graphic layer is embedded on the map image itself and doesn’t need to be pulled in as a separate image thus saving a little bit (very little) of bandwidth.
- A good solution when it comes to printing/generating print map images with the graphics layer.
Cons:
- Potentially large amounts of data is pushed between the web server and the ArcGIS Server.
- The graphic layer’s features will need to be maintained on the web server’s session.
One thing to keep in mind is that none of the above solutions is a great solution (even thought they can be workable) for labeling features on the graphics layer.
Subscribe
Follow Me
Contact me
Vishful thinking... 
2 comments