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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.