A Question of Coordinate Storage

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

A Question of Coordinate Storage

dmbaker

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


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: A Question of Coordinate Storage

Frank Warmerdam
David M. Baker wrote:
> 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?

David,

I will make a few observations.

1) You mentioned NAD27 earlier.  All else being equal, I would be very
queasy about keeping spatial data in the NAD27 datum as the NAD27 datum is
often poorly defined, and there is some cost and error in shifting between
it and more regular datums like WGS84 since it is accomplished with approximate
grid shift files.

2) For coordinate data, like vector features, there is some difference in
precision between coordinate systems with a local origin as opposed to a
global origin.  That is, the further the coordinate system origin is from
the data, the greater the loss of precision.  Storing stuff in WGS84 lat/long
uses a global origin and so would lose a few bits of precision in double
precision storage compared to data stored in a coordinate system with a
local origin such as state plane for instance.  UTM however is really only
local in the east-west direction (relative to the central meridian of that
zone offset by the false easting).  Because UTM uses the equator as it's
Y origin precision of northing values is generally no better than working
with latitudes in degrees.

3) For raster data every resampling step results in spatial and radiometric
damage.  So it is best to keep the data in the coordinate system it was
collected in, or that it will be used in, if possible.

I don't think any of these 3 points will definatively settle the discussion,
but hopefully it will give slightly more concrete precision and accuracy
issues to consider.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

Dean Mikkelsen
In reply to this post by dmbaker
Message
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: [hidden email] [mailto:[hidden email]] On Behalf Of David M. Baker
Sent: Sunday, October 07, 2007 8:40 AM
To: [hidden email]
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


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

dmbaker
In reply to this post by Frank Warmerdam
Frank,

Thanks for the quick reply.

We are not proposing to store the data in NAD27; it makes me uneasy too, but
a majority of our data vendors report coordinates in this system. I would
opt for WGS84. The fact of the matter is that for most of the data we deal
with we do not know provenance of the original coordinates, so my guess is
we are well within the decimal precision of any system we may use.

I see your point about UTM only be local east-west.  I had not considered
that!  Accept for the 2D and 3D seismic data that we collect (the bins of
which are surveyed in x,y's on the ground) most of our data has been
converted from one system to another before it is delivered (for the most
part NAD27).  Example: A well location is reported in NAD27 that would fall
in the in the very west extreme of UTM13 is converted to UTM14 for storage.
Would there not be significant error in the location in stored.  Also, if we
had a 3D survey that was surveyed in local coordinates of UTM13, would there
not be a difference?  Also, is more error introduced if a geologist then
re-projects this same well to a state plain system?  Would we have been
better off storing in WGS84?

Thanks,
David



-----Original Message-----
From: Frank Warmerdam [mailto:[hidden email]]
Sent: Sunday, October 07, 2007 11:55 AM
To: David M. Baker
Cc: [hidden email]
Subject: Re: [Gdal-dev] A Question of Coordinate Storage

David M. Baker wrote:
> 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?

David,

I will make a few observations.

1) You mentioned NAD27 earlier.  All else being equal, I would be very
queasy about keeping spatial data in the NAD27 datum as the NAD27 datum is
often poorly defined, and there is some cost and error in shifting between
it and more regular datums like WGS84 since it is accomplished with
approximate
grid shift files.

2) For coordinate data, like vector features, there is some difference in
precision between coordinate systems with a local origin as opposed to a
global origin.  That is, the further the coordinate system origin is from
the data, the greater the loss of precision.  Storing stuff in WGS84
lat/long
uses a global origin and so would lose a few bits of precision in double
precision storage compared to data stored in a coordinate system with a
local origin such as state plane for instance.  UTM however is really only
local in the east-west direction (relative to the central meridian of that
zone offset by the false easting).  Because UTM uses the equator as it's
Y origin precision of northing values is generally no better than working
with latitudes in degrees.

3) For raster data every resampling step results in spatial and radiometric
damage.  So it is best to keep the data in the coordinate system it was
collected in, or that it will be used in, if possible.

I don't think any of these 3 points will definatively settle the discussion,
but hopefully it will give slightly more concrete precision and accuracy
issues to consider.

Best regards,
--
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
[hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: A Question of Coordinate Storage

Frank Warmerdam
David M. Baker wrote:
> Accept for the 2D and 3D seismic data that we collect (the bins of
> which are surveyed in x,y's on the ground) most of our data has been
> converted from one system to another before it is delivered (for the most
> part NAD27).  Example: A well location is reported in NAD27 that would fall
> in the in the very west extreme of UTM13 is converted to UTM14 for storage.
> Would there not be significant error in the location in stored.  

David,

As Dean pointed out typical algorithms to evaluate transverse mercator will
have increasing error as you move out from the central meridian - that is
a "round trip" from WGS84 -> UTM -> WGS84 will incur some error.  But I don't
think it is significant near the zone bounds.  In my experience you need to
be quite a ways from the central meridian before this sort of error accumulates
significantly (perhaps 9 degrees - one whole zone over).

 > Also, if we
> had a 3D survey that was surveyed in local coordinates of UTM13, would there
> not be a difference?  Also, is more error introduced if a geologist then
> re-projects this same well to a state plain system?  Would we have been
> better off storing in WGS84?

In my experience the reprojection error for point data in areas where
projections are well defined/implemented is not all that significant,
though there is always a bit.

But, it really sounds like the accuracy of your source data isn't great
anyways so some of these precision arguments are likely not very relavent.
For feature (vector/point/etc) data there is something to be said for the
simplicity of keeping everything in WGS84, and reprojecting to other
coordinate systems as needed.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

dmbaker
In reply to this post by Dean Mikkelsen
Message

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:[hidden email]]
Sent: Sunday, October 07, 2007 11:55 AM
To: 'David M. Baker'; [hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of David M. Baker
Sent: Sunday, October 07, 2007 8:40 AM
To: [hidden email]
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


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

dmbaker
In reply to this post by Frank Warmerdam
Frank,

The info Dean presented was quite good!  My point to GIS has been just that,
it is a lot easier to maintain our data in WGS84 and reproject.  Most of our
data is reported in lat/lon in decimal degrees to 7 decimal places, -/+ a
1/10 of a foot, an precision that is much higher then the real accuracy of
the data.

Thanks for the replies, this has been a great help!

David

-----Original Message-----
From: Frank Warmerdam [mailto:[hidden email]]
Sent: Sunday, October 07, 2007 2:23 PM
To: David M. Baker
Cc: [hidden email]
Subject: Re: [Gdal-dev] A Question of Coordinate Storage

David M. Baker wrote:
> Accept for the 2D and 3D seismic data that we collect (the bins of
> which are surveyed in x,y's on the ground) most of our data has been
> converted from one system to another before it is delivered (for the most
> part NAD27).  Example: A well location is reported in NAD27 that would
fall
> in the in the very west extreme of UTM13 is converted to UTM14 for
storage.
> Would there not be significant error in the location in stored.  

David,

As Dean pointed out typical algorithms to evaluate transverse mercator will
have increasing error as you move out from the central meridian - that is
a "round trip" from WGS84 -> UTM -> WGS84 will incur some error.  But I
don't
think it is significant near the zone bounds.  In my experience you need to
be quite a ways from the central meridian before this sort of error
accumulates
significantly (perhaps 9 degrees - one whole zone over).

 > Also, if we
> had a 3D survey that was surveyed in local coordinates of UTM13, would
there
> not be a difference?  Also, is more error introduced if a geologist then
> re-projects this same well to a state plain system?  Would we have been
> better off storing in WGS84?

In my experience the reprojection error for point data in areas where
projections are well defined/implemented is not all that significant,
though there is always a bit.

But, it really sounds like the accuracy of your source data isn't great
anyways so some of these precision arguments are likely not very relavent.
For feature (vector/point/etc) data there is something to be said for the
simplicity of keeping everything in WGS84, and reprojecting to other
coordinate systems as needed.

Best regards,
--
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
[hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

Dean Mikkelsen
In reply to this post by dmbaker
Message
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:[hidden email]]
Sent: Sunday, October 07, 2007 12:47 PM
To: [hidden email]; [hidden email]
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:[hidden email]]
Sent: Sunday, October 07, 2007 11:55 AM
To: 'David M. Baker'; [hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of David M. Baker
Sent: Sunday, October 07, 2007 8:40 AM
To: [hidden email]
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


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: A Question of Coordinate Storage

dmbaker
Message

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:[hidden email]]
Sent: Sunday, October 07, 2007 3:48 PM
To: 'David M. Baker'; [hidden email]
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:[hidden email]]
Sent: Sunday, October 07, 2007 12:47 PM
To: [hidden email]; [hidden email]
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:[hidden email]]
Sent: Sunday, October 07, 2007 11:55 AM
To: 'David M. Baker'; [hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of David M. Baker
Sent: Sunday, October 07, 2007 8:40 AM
To: [hidden email]
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


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev