Silverlight databinding limitations
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.
Reason why JSON output is going to be much faster in ArcGIS Server 9.4
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.
GIS Standards gone crazy (EPSG especially)
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.
Lack of good transparency support in Silverlight and what it means to online mapping apps
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”
</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.
Subscribe
Follow Me
Contact me
Vishful thinking... 
1 comment