[Gdal-dev] A Question of Coordinate Storage

[David M. Baker]

Dean,

 

Perfectly said!  Thank you for your insight.  What is interesting is we are
doing an evaluation of Discovery on OpenWorks and the original
recommendation that Halliburton was to store all data in some projected
coordinate system as OpenWorks is so Landmark seismic oriented.  But were
are looking for a robust corporate well data store and have operations from
the Rockies to the Gulf and New Mexico to Appalachia, so a single projected
system is not practical.  The new version of OpenWorks at least stores both
the original coordinates and the master projected be it x, y or lat/lon.

 

David

 

  _____  

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

 

Hi David,

 

There is often a misunderstanding between accuracy and precision, but
essentially all things come down to the quality of data and the accuracy
required for intended purpose.

 

Having worked in the oil industry for many years (w/Schlumberger) where I
encountered this same problem with the Gulf of Mexico datasets, and more and
more data being acquired in WGS84, yet the MMS required at the time, the
data to be reported in NAD27 (in fact many oil companies still kept the data
in NAD27 due to the apparent cost of coverting data between the two - BP is
now just undertaking this exact process due to a change in gov't legislation
and a lobby group here in Canada (CAPP) finally recommending that the data
be stored in WGS84), and it is interesting to note, as we go to deep water
offshore GOM, there is hardly any NAD27 control (in fact only three points
measured on wells), which makes the transformation between NAD27 and NAD83
very questionable (less control, less parameters for the transformation
between the two systems), so the surveyors used their own control networks.

 

The recommendation that we adopted (as was applied to products such as
GeoFrame, Finder, OpenWorks) was to store coordinates in lat/long in WGS84
and let the software handle the map projection transformation as the speed
was hardly noticeable - this became the default for the software. It was
felt best to store the data in a defined ECEF coordinate system. There is no
need to compound the error, but instead maintain the errors at a level that
you know and understand. By moving the data to WGS84, you will know the
level of error and be able to assign some level of quality to the data. I
would still avoid storing everything in a map projection, specifically for a
specific zone, as you have a large area.

 

Historical data provides obstacles, but there is often other points to
consider as well with the data quality and even the monumentation (metes and
bounds, etc.) done at the time and what is available currently (presently).

 

Cheers,

Dean

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

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

 

-----Original Message-----
From: David M. Baker [mailto:dmbaker at cox.net] 
Sent: Sunday, October 07, 2007 12:47 PM
To: dcmikkelsen at shaw.ca; gdal-dev at lists.maptools.org
Subject: RE: [Gdal-dev] A Question of Coordinate Storage

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/31378ea2/attachment.html