Wednesday, July 1, 2009

ArcGIS Server and map service projection on the fly

With ArcGIS 9.3.1 and the "Analyze Map" tool on the Map Service Publishing toolbar folks are realizing that projection on the fly can have a huge impact on map service performance. This leads people to think that maybe they need to project all of their data to WGS 84 or WGS 84 Web Mercator to get the best performance in their map services. This blog discusses projection on the fly as it pertains to performance for MXD or MSD based map services.

As a general rule I don’t think you need to projecting everything to WGS84 (or whatever coordinate system you are mashing up with). Map services do perform best when there is no projection on the fly happening in the MXD / MSD. But there are two places that projection on the fly can happen: within the MXD/MSD and within the map service. When you do projection on the fly within the MXD/MSD you are doing this projection on every layer in the map on every map service request. This is a lot of work and this can have a big impact on performance. When you do projection on the fly in the map service you are projecting the resulting map. This projection happens once for the entire map per request and is therefore much faster than the MXD/MSD projection on the fly.

When you have a dynamic map service who's map is using UTM (or some other local CS), it will automatically project on the fly to other map services in your application. So if you are using a WGS 84 base map from ArcGIS Online, your dynamic UTM service will overlay just fine.

Performance tip: with dynamic services, set the projection of your map to the same projection as your data.

This map service projection on the fly, does not work with cached map services. So for those map services that you are going to cache (all base maps and some of your operational layers), you need to change the projection of the map to the projection of the other services you are going to mash up with (e.g. WGS 84 or WGS 84 web mercator). In this case you would pay the price for projecting on the fly within the MXD/MSD. This would slow down your cache creation but you would get the great performance of a cached map service on each map service request. If you are building a very large cached map service, you should probably consider extracting your data to a file geodatabase just for the cache creation. A local (to the GIS server) file geodatabase is going to give you your best performance for cache creation. When you create this copy of the data for cache creation, you can project it to the coordinate system of your map service (e.g. WGS 84). The best tool for doing this is the Extract Data Wizard. Check out “Copying a geodatabase using the Extract Data Wizard in ArcMap” here: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Methods_for_copying_geodatabases

Here is info on extracting data to a different coordinate system.

http://support.esri.com/index.cfm?fa=knowledgebase.techArticles.articleShow&d=34129

The Extract Data wizard is a great tool for this because it can create a copy of your map document that uses the extracted data.

In summary, store your data in the coordinate system that makes the most sense for your data maintenance, management, and analysis. Your map services can use this data to make fast maps in any coordinate system. One final curve ball is that ArcGIS Online will be moving to WGS 84 Web Mercator later in 2009 (see the ArcGIS Online blog for more information ).

16 comments:

  1. Thanks for the tips!

    ReplyDelete
  2. really helpful, thank you....

    ReplyDelete
  3. I'm trying to use this method of reprojecting all of the data in my MXD to WGS 1984 Web Mercator, but on the schema-only extraction step I'm getting the error:

    Data extraction failed
    The M Domain on the spatial reference is not set or invalid.
    There is no precision information for this spatial reference.

    Most of my data is in California Teale Albers, but I'm assuming this message is in regards to the WGS 1984 Web Mercator projection.

    Any thoughts?

    ReplyDelete
  4. this sounds like a bug. it sounds like some of your line feature classes have M coordinates and the data extraction dialog is not creating an appropriate M domain. Actually it should just copy the M domain over from the original since reprojecting your data has no effect on the M coordinates.

    There is a work around though. We need to do a little more work in step 2 of article 34129. Follow these steps for step 2.
    1. Create a temporary file geodatabase.
    2. Do a schema only extraction to this temporary geodatabase without changing the coordinate system.
    3. Use the project tool to project the feature classes in your temp file geodatabase to your target file geodatabase (the one that will be participating in the replica). If you are going to WGS 84 Web Mercator you need to specify an appropriate geographic transformation (see tech article 34749).
    4. Continue with step 3 of the instructions in article 34129.

    ReplyDelete
  5. Thanks Tom, although I'm a little confused by step #3 in your work around. How do I project the feature classes in my temp file geodatabase when all I've done is a schema-only extraction to that gdb? Also, if I'm projecting these features to my target gdb, how does the data-only extraction work later, does it overright these features?

    Any clarification would be appreciated!
    Thanks.

    ReplyDelete
  6. Yes, you will be projecting the schema of these feature classes. No features are being projected but the feature classes will have the correct coordinate system.

    So since there are no features in those feature classes the data-only extraction does not need to overwrite anything.

    ReplyDelete
  7. Nice post on extracting data, simple and too the point :), For extracting data i use python for simple things,data extraction can be a time consuming process but for larger projects like files, the web, or documents i tried "extracting data" which worked great, they build quick custom screen scrapers, extracting data, and data parsing programs

    ReplyDelete
  8. Thanks! A really useful post. The arcgis website is so convoluted that to find something useful fast is almost impossible...

    ReplyDelete
  9. I AM tring to do some thing
    http://kumarage-prasanna.blogspot.com/

    ReplyDelete
  10. ArcInfo Coverage
    Description Spatial Attributes


    Map Projection Name: Transverse Mercator
    Scale Factor at Central Meridian: 0.999924
    Longitude of Central Meridian: 80.771713
    Latitude of Projection Origin: 7.000472
    False Easting: 500000.000000
    False Northing: 500000.000000

    Planar Coordinate Information
    Planar Distance Units: meters
    Coordinate Encoding Method: coordinate pair
    Coordinate Representation
    Abscissa Resolution: 0.000000
    Ordinate Resolution: 0.000000


    Geodetic Model
    Horizontal Datum Name: D_Kandawala
    Ellipsoid Name: Everest_Adjustment_1937
    Semi-major Axis: 6377276.345000
    Denominator of Flattening Ratio: 300.801700
    _________________


    Bounding coordinates
    Horizontal
    In decimal degrees
    West: 79.165113
    East: 79.165113
    North: 5.916379
    South: 5.916379
    In projected or local coordinates
    Left: 322115.000000
    Right: 322115.000000
    Top: 380387.687500
    Bottom: 380387.687500
    but this data set can not be shift to other origin
    when we open the map its show diferent cor-dinate
    why is like this please help me if you can
    kumarageilp2HOTMAIL.COM

    ReplyDelete
  11. I'm not sure why you are having trouble with that coordinate system. Perhaps a file geodatabase would work better.

    ReplyDelete
  12. Nice site! This is such a creative thought. Really i appreciate the effort you made to share the knowledge.

    CINCINNATI SHOPPING

    ReplyDelete