GeoJSON & GPX support added to the ESRI Silverlight API Contrib
I’ve added support for the GeoJSON and GPX layer types to the ESRI Silverlight API Contrib project on CodePlex. Adding GeoJSON or GPX layer to the ESRI Silverlight API map is real easy and you would add it just like adding a FeatureLayer to the map.
Adding a GeoJSON layer to the map
<esri:Map x:Name="MyMap" Grid.Row="1">
<esri:Map.Layers>
<esri:ArcGISTiledMapServiceLayer ID="StreetMapLayer"
Url="http://server.arcgisonline.com/ArcGIS/rest/services/ESRI_Imagery_World_2D/MapServer"/>
<slContrib:GeoJSONLayer ID="geoJSONLayer"
URL="http://localhost/SLMaps.Web/Data/JSON.txt" />
</esri:Map.Layers>
</esri:Map>
Adding a GPX layer to the map
<esri:Map x:Name="MyMap" Grid.Row="1">
<esri:Map.Layers>
<esri:ArcGISTiledMapServiceLayer ID="StreetMapLayer"
Url="http://server.arcgisonline.com/ArcGIS/rest/services/ESRI_Imagery_World_2D/MapServer"/>
<slContrib:GPXLayer ID="gpxLayer"
URL="http://localhost/SLMaps.Web/Data/fells_loop.txt" />
</esri:Map.Layers>
</esri:Map>
This adds to the GeoRSS layer support already present in the library.
Other than just adding these data sources as layers to the map, The GeoJSONReader & GPXReader classes can also be used to just parse the data source and obtain the geometry and attribute values of the features in the data source if/as required. This should allow for the users to upload GeoJSON & GPX data from their GPS units directly from their computers to the Silverlight map control without the need to upload files to the server. Allowing the workflow to be smoother, faster and simple both on the server-side & client-side.
Exploring/Exploiting the query operation in the ArcGIS REST API
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.
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.
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”
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.
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.
ArcToSQL2008 – An ArcCatalog Command to export FeatureClasses to MS SQL SERVER 2008
I had written this tool 3-4 months ago and it had been sitting on my machine waiting to be wrapped with an installer project. I finally got around to building a setup and deployment project for it and it is ready to distribute. The tool can be downloaded below
Once installed, you should be able to open the “Tools -> Customize” dialog in ArcCatalog
Under the “GeoSpatial.NET” Categories, the “ArcToSQL2008″ command should be available. Drag the command to any of the toolbars.
Select the FeatureClass you want to export to the SQL Server 2008 database and click the “ArcToSQL2008″ button on the toolbar. The dialog below should pop-up. Enter the name of the SQL Server 2008 database server and click connect. The Database drop-down will get populated with all available databases on the server. Select a database from the list and enter the name of the table that you want the FeatureClass exported to. Click OK. The FeatureClass will get exported and a message box should pop-up when the import is completed.
Some highlights of the tool:
-
Exports FeatureClasses in a Projected Co-ordinate System as SQLGeometry in SQL 2008.
-
Exports FeatureClasses in a Geographic Co-ordinate System as SQLGeography in SQL 2008.
-
Any errors that occur during the export are logged in a log file found under in the install directory.
-
The tool is built using a broader GIS framework that should enable developers to customize the export process to their liking. I still have a little bit of house cleaning on the code for the broader GIS framework. I will post when it is all done. Hopefully that will be real soon. Contact me if you want to look at it sooner…
Things left to do:
-
Better UI showing the progress of the export operation.
-
More flexibility to the export operation by allowing the user to select the fields to be exported.
-
The export operation can be made faster by using the geometry builder classes to construct the SQLGeometry and SQLGeography objects. I took the shortcut for now and just parsed out the geometries from WKT strings.
Please let me know if you find any bugs in the tool using the “contact me” link on the right pane of this blog.
Filter Encoding Standard 1.1 and the curious case of the missing ‘IN’ operator
I was working with the Filter Encoding (FE) 1.1 standard recently and was surprised to find that it did not have an equivalent to the ‘IN’ operator. The FE 1.1 standard currently supports the following comparison operator.
-
- PropertyIsEqualTo
- PropertyIsNotEqualTo
- PropertyIsLessThan
- PropertyIsGreaterThan
- PropertyIsLessThanOrEqualTo
- PropertyIsGreaterThanOrEqualTo
- PropertyIsLike
- PropertyIsBetween
- PropertyIsNull
That was a big bummer for me since when I tried to use multiple “PropertyIsEqualTo” comparison operator coupled with the logical “OR” operator the performance was VERY bad. I am using ArcGIS server 9.3 like always.
The OGC support in ArcGIS Server is really great in case your are wondering. ArcGIS Server 9.3 supports the Filter Encoding 1.1, Styled Layer Descriptor 1.0 and other OGC standards as listed here http://www.esri.com/software/standards/standards_tables.html. Support for Styled Layer Descriptor 1.1 is not there yet but may happen in the future versions.
The FE 1.1 standard does include support for the ‘GmlObjectId’ object identifiers way of querying data. This can serve as the ‘IN’ operator if you are querying by the object identifiers. Unfortunately, I wasn’t. The Filter Encoding does include support for ‘Functions’ where custom filters can be supported by the GIS Server. And since, the ‘IN’ comparison operator is missing, it can be implemented as a custom ‘Function’ by GIS Servers to serve clients who desperately that functionality…
ArcObject, PostGIS and spatial operations performance
I have caught myself cursing at ArcObjects numerous times for not being performant for some of the spatial operations I had done using it in the past. I have also heard the same about it from other developers I have come across in the past. But what I was always curious about was, how does ArcObjects compare in performance to the other open-source spatial libraries like PostGIS? Since I have always been swimming in the ESRI and .NET ocean, I have little or no knowledge on how the PostGIS and Java worlds performed. So, it was interesting to listen to John Coryat speak this thoughts on how using the PostGIS library (that sits on top of the PostgreSQL database) makes spatial operations up to 10 -100 times slower than if those operations where performed using the spatial operations built into Postgresql.
Both ArcObjects and PostGIS suffer from the same drawback that make them significantly slower, they both are spatial libraries that run outside of the process space of the database where the spatial data is stored. Please see comments from Paul Ramsey below explaining that PostGIS actually runs within the process space of the database and how recents changes have made it considerably faster. ArcObjects runs outside of the process space of the database where the spatial data is stored.And that takes a major toll on the performance. Most databases these days including MS SQL Server 2008 pack a powerful set of spatial operations built right now that can satisfy the requirements for some cases but definitely not all of them. The spatial operations that are built right into the databases should always be prefered over using external spatial libraries since they run magnitudes faster. But the problem is that spatial operations included in those databases are not comprehensive and they all don’t pack the same geometry operations either. Most of them do support the SQL functions outlined by the OGC like SQL Server 2008 but some don’t. The most notable memberwould be MySQL.
To overcome or to add more capability to the spatial operations in these databases, an external spatial library become a necessity. Expecting the database vendors to develop spatial operations and to have to them keep up with the developments in the industry would not be an attractive option. This puts us, the spatial developers, in a catch-22 situation wherein we need to give up on performance to gain more powerful spatial capabilities. So, we may not be able to FIX the performance issues with spatial operations but just patch it as needed.
Even though John Coryat talks about his experience with PostGIS and PostgreSQL performance comparisions, that still doesn’t give a comparision between ArcObjects and PostGIS performance. It would be interesting to see some performance benchmarks between the two though.
Subscribe
Follow Me
Contact me
2 comments