[Gdal-dev] A Question of Coordinate Storage

David M. Baker dmbaker at cox.net
Sun Oct 7 15:46:41 EDT 2007


Dean,

 

Thanks for the link you provided.  There is a lot on info on this subject
germane to my problem.  Please see a reply I made to Frank earlier.  We are
not proposing storing our corporate data in NAD27 even though most of us
geoscientists do in our local database (because most of our vendor data come
in NAD27).  I guess I need to do some testing similar to those referred to
here: http://srmwww.gov.bc.ca/gis/bceprojection.html.  The GIS guys claim
greater accuracy, though I think they mean precision, but the fact is our
data is not that accurate.  If we are within a meter we are doing well,
though if I new for sure we were within 5 meters I would be happy.  We have
old data that is measured off a Jeffersonian gird system and converted to
NAD27 lat/lons, we have newer, survey, data that referenced to state plain
and then converted to NAD27 lat/lon, but more recently we get data that the
positions are acquired by GPS and reported in WGS84.  So we start with a
real provenance problem, but we live with that.  What concerns me is
potential for compounding or needlessly adding error for the sake of speed
in our map display.

 

David

  _____  

From: Dean C. Mikkelsen [mailto:dcmikkelsen at shaw.ca] 
Sent: Sunday, October 07, 2007 11:55 AM
To: 'David M. Baker'; gdal-dev at lists.maptools.org
Subject: RE: [Gdal-dev] A Question of Coordinate Storage

 

Hi David,

 

I would recommend keeping all the co-ordinates in geographics
(latitude/longitude), rather than UTM Zone 14. Keeping all the data in one
zone for an area that covers 3 to 5 UTM Zones does not make sense from a
mapping point of view or even from a data conversion point of view.

 

Essentially your error is increasing exponentially the further away you go
from the Central Meridian in the UTM Projection. The more zones you cover,
the greater the error in the values. Not only that, as you transform the
coordinates back and forth from UTM 14 to geographic to UTM 12, 18, 15,
etc., you will also be introducing errors again. Then if you reproject to a
different datum, say NAD83, you are introducing another error (even if you
are using a grid conversion, such as NADCON (larger error if you are using a
Molodensky conversion).

 

For example, here in British Columbia, even using ArcSDE, coordinates are
stored in geographics (and we are covering 5 UTM Zones, but have settled
upon an Albers Projection - for mapping, and NAD83 for the datum). For
working in ArcSDE, take a look here:
http://srmwww.gov.bc.ca/gis/sdedata.html. Note that even the BC Gov't states
that for working outside B.C., that there "needs a different spatial
reference, even if it is stored in geographic or BC Albers projection. Data
in this larger area must have a lower resolution".

 

Remember, coordinates that are stored in latitude and longitude are usually
stored as two real numbers in decimal degrees and we know that these range
from -180.0 W to +180.0 E in longitude, and -90.0 S to +90.0 N in latitude,
for a total of 360.0 degrees around the earth in each direction. The earth's
circumference is roughly 40,000 kilometres or 40,000,000 metres and
therefore one can conclude there are about 

 
  40,000,000 
  ----------  
      360
 
or about 111,000 metres per degree of latitude anywhere on the earth. The
size of a degree of longitude varies - at the equator it's the same as a
degree of latitude, but at the poles it is 0. 

9 significant digits is sufficient to preserve metre precision (this would
be number (9,6) in Oracle), or 11 significant digits to preserve centimetre
precision (this would be number (11,8) in Oracle).

Also note that by restricting the range (extent) of the area that can be
included in a dataset, it is possible to increase the precision of the
coordinates stored - therefore I would not store everything in UTM 14. I
would only keep the coordinates in UTM 14 if that was my only are of
interest, otherwise keep it geographic (latitude and longitude). UTM is LESS
PRECISE after all the conversions and especially since we are talking about
3 to 5 zones.

I would also recommend that your GIS department move their data into
NAD83/WGS84, not NAD27. WGS84 is a precisely determined system, while NAD27
is not. NAD27 is based on triangulations being joined together to form a
model of the earth, which is centered at Meades Ranch, Kansas, while WGS84
is ECEF (Earth Centered Earth Fixed) and determined by Satellite
Measurements. NADCON is an accurate conversion for most mapping and GIS use,
so you should be safe there. I would also look at your local HARN network or
any local geodetic work done by your State Gov't Agency to see what they
recommend.

Let me know if I can expand further or answer more questions.

Cheers,

Dean

Dean C. Mikkelsen, B.Sc., P.Eng.

Terra ETL Ltd. - http://www.terraetl.com

 

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of David M. Baker
Sent: Sunday, October 07, 2007 8:40 AM
To: gdal-dev at lists.maptools.org
Subject: [Gdal-dev] A Question of Coordinate Storage

All,

 

Though this question is not specific to GDAL, OGR or FWTools, I believe some
of the most knowledgeable people of the subject are on this mailing list and
hope you will allow me to ask.

 

At my company, there is an ongoing debate as to the best coordinate system
to store cooperate spatial data in.  The debate is mainly between the
Geoscience department and the GIS department.  The vast majority of the data
the Geo's use comes from public sources that are in geographic lat/lon in
NAD27.  This data is then reprojected for mapping and display in various
coordinate systems, state plane and UTM (zones 12 - 18, but mostly in 13, 14
and 15).  The GIS guys supply many layers to the Geo's for display.  They
are currently upgrading from ArcSDE 9.1 to 9.2, and in the process are
converting all their coordinates for storage in UTM zone 14.  GIS made the
comment that this is a much more accurate way to store the data, that
geographic coordinates are less precise, though, their main reason for
storing the data in a projected system is to avoid having to do any
coordinate conversion on the fly when displaying the data on corporate web
maps.  The layers supplied to the Geo's will need to be reprojected if their
current map projections are not UTM Zone 14.

 

The question: is it wise to store coordinates that cover such a wide area in
a single projected coordinate system, or would it be better to store them in
some geographic coordinate system, e.g., NAD83 or WGS84?  And if this not
the best way (UTM14), why?  What are the pitfalls?  Is it really more
accurate, or precise to store data in a Cartesian coordinates and suffer the
conversion to a different projection as needed?

 

Thanks,

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20071007/0779ca75/attachment.html


More information about the Gdal-dev mailing list