35

Why is it useful to store data in unusual projections and datums?

I understand the value of projections as output constructs, because of distortion, etc: that much is justifiable.

However, I don't understand why, for instance, states use state plane projections in data. We have decimal accuracy: why not just store precise values in EPSG:4326? Is this entirely a remnant of pre-auto-reprojection days, or is there a value proposition I'm missing?

I'll restrict the scope of this question to vector data only to make it more concrete.

Improve this question
4
  • You might care to make a distinction among data formats. The case for paying attention to how raster data are projected differs from the argument for vector data.
    – whuber
    Oct 27 '11 at 20:54
  • 2
    You could consider the case of having to perform calculations of some parameter (eg. area) being done repetitively. Having to project the data each time to a planar coordinate system would be a waste of time, whether it is done "on-the-fly" or not. There is a place for both decimal degree and projected coordinates. Datums, historically reflect our knowledge of the shape of Earth, hence, legacy data must still be dealt with not to mention that some projections are better suited to some locations are their datums.
    – user681
    Oct 27 '11 at 20:59
  • Thanks Dan. The reprojection reason I feel is transitory; it's a performance tweak to keep data in projections then, and it'll become less necessary as we have faster reprojection? As far as datums, could you elaborate on how some projections are better suited to datums, and how that differs from the problem of reprojection? Is it possible to 'update' a dataset's datum and keep a record of the change?
    – tmcw
    Oct 27 '11 at 21:04
  • 1
    I think what will hold the need is the fact that most software does processing in only the "native" projection/unit. That is especially smaller softwer with less environment control. So to get meters you have to input meters. No on-the-fly calculations.
    – Brad Nesom
    Oct 27 '11 at 21:19
33

Legacy. Back in the Day (and now too) it was/is (much) easier to write a system that works in cartesian space instead of spherical coordinates relative on a spheroid. (What's the distance between A and B on a plane? over the surface of a sphere? of a spheroid? do you feel the degree of difficulty increasing?) And since most counties/states/cities exist in limited geographical areas that are amenable to fitting into map projections, it made sense to store and work with their data in cartesian coordinates in a local map projection.

Improve this answer
0
9

I'm a little uneasy relying on project- and/or calculate-on-the-fly when it comes to analysis. There's a lot of pressure to get things done and show them to the user quickly, and this leads to shortcuts. I can't count how many days I've lost tracking down problems with data alignment across layers that come from different processes only to discover that at some point a program(mer) decided that for expediency "we'll just ignore everything past the 6th decimal".

Unless one has the code, and the knowledge to understand it, the calculations behind on-the-fly transitions are invisible, it's hard to test their veracity, and impossible to tweak. For example, to use a raster geoprocessing analogy (I know your question is about vectors but it illustrates the concept clearly), when I project "manually" I can choose among nearest-neighbor, bilinear, cubic, spline, etc. depending on the nature of my data and the purpose the result is destined for. On-the-fly generally drops or hides things like this.

In the fullness of time I expect on-the-fly processing will be honed and tested enough to be reliable. I don't think we're they're yet, I could be wrong, but I remain to be convinced.

Improve this answer
3
  • 6
    On this point, isn't it true that whenever you project from one datum to another that there is some error or shift introduced? See Revenge of the Shift
    – blah238
    Nov 1 '11 at 20:54
  • 2
    I love that presentation, the author Joel Cusick actually uses the speakers notes, which makes the .ppt worth reading. Wish I'd seen it live. Thanks for reminding me about it. That said I think his point is not that datum shifts always introduce change (error) but that using the NAD83 variants (for example) interchangeably will add error. It's worth a new question to clarify.
    – matt wilkie
    Nov 1 '11 at 21:30
  • It's also worth noting that at the end of that presentation Cusick recommnds the MxGPS Arcgis addon because it records the transformation method used. When I corresponded with him a couple of years ago he'd switched to using/recommending DNRGarmin because of it's other abilities in addition to being datum smart. Dunno if that's still the case.
    – matt wilkie
    Nov 1 '11 at 21:32
5

Different projections offer different balances of distortions in shape, area, and distance/scale. Such distortions are unavoidable when projecting a 3 dimensional object, the earth, to a 2D medium, a paper map or computer screen. Even Google Earth, 3D Analyst, and other "3D" tools don't really display 3 dimensions. So the mapmaker must choose an appropriate projection that best balances the distortions based on the purpose of the map.

Often local/state governments have mandated a projection or by law. This usually happened long before modern advances in GIS. The chosen projection, or group of projections, usually best balance all three distortions based on the locality. Governments will then require developers to tie surveys to the locally mandated projection. This will make it easier to compare developers' maps with official maps for public review, hearings, etc. It also makes all official maps look similar.

Improve this answer
3
  • 2
    I think this is a good argument for why map projections are relevant, but less so for why the data itself is so often stored in a projected coordinate reference system.
    – blah238
    Oct 27 '11 at 23:41
  • 4
    Yeah - my question is directed towards projections in data only. The justification for output projections is well-established.
    – tmcw
    Oct 28 '11 at 18:10
  • Sorry I missed that - read the question too fast. Of course, data has to be digitized in a specific projection, and will look very different from one projection to the next. To store the data without the original projection info. might mean it doesn't render properly outside of its original projection. I'd have to experiment to be sure, though.
    – user3461
    Oct 28 '11 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.