Projection on the Fly -- Steak or Sizzle?
James Fee challenged his blog readers to respond to another reader's request -- "Please list all the pros and cons of ArcView 3.1". Many obliged, and collectively came up with a fairly comprehensive list of pros and cons. Several responses (three at the time of this writing) included lack of projection-on-the-fly as a con.
But how important is on-the-fly projection? For any serious GIS work one needs to project their data anyway. I think projection on the fly as a feature was introduced by ESRI in response to Intergraph’s similar feature, which Intergraph wasn’t shy flaunting in sales presentations prior to ESRI having it. It’s just sales sizzle.
What do you think?
Posted by Atanas Entchev at 6/9/2009 8:19 PM 
Categories: Intergraph,GIS,Software,ArcView,ArcGIS,ESRI
Tags: Intergraph GIS Software ArcView ArcGIS ESRI
Categories: Intergraph,GIS,Software,ArcView,ArcGIS,ESRI
Tags: Intergraph GIS Software ArcView ArcGIS ESRI
I disagreed with you on James' site, so I'll disagree with you here, too. While it might have been sizzle back in the day, it's essential to have now because of the myriad sources of data we use on a daily basis. Many of those sources are provided as a service and thus need to be projected on-the-fly.
It's a case of sizzle becoming steak.
Reply to this
Thank you for the comment.
Services, of course, are one instance where projection-on-the-fly might be essential. But in terms of overall system performance, you pay a price (a performance hit) every time you project on the fly.
I still contend that, when possible, on-the-fly projection should be avoided.
Reply to this
The cost of reprojecting on-the-fly is negligible to the cost of hosting and maintaining massive data like statewide aerial photography. It's easier and more responsive to use the WGS84 WMS of the 2007 aerials than pull the MrSIDs off our internal server. Considering we don't have ArcGIS Server and our "GIS" server is just a windows file share, it's not surprising the OIT can handle requests better from across town than we can handle requests internally. But that's part of a bigger problem.
I absolutely agree with you in that all local data should be in the same projection.
Reply to this
I'm somewhere in the middle. While I agree with John above regarding the need to integrate various datasets, I have found this to be a handy, although not vital, tool for other reasons.
One of the most common things I run across are datasets lacking appropriate metadata, including coordinate information. It's amazing how many people use geographic data and yet don't really understand it.
ESRI's project on the fly allows me to have one of our datasets in a map with a metadata-less dataset and continue to try different coordinate systems until the dataset appears to fall where it's supposed to relative to our data.
Reply to this
"a handy, although not vital, tool" -- I believe we can agree on that.
Reply to this