<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word" xmlns:st1 =
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.3157" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name="State"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType
name="place"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
PRE {
FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle17 {
COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff size=2>Hi
David,</FONT></SPAN></DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2>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).</FONT></SPAN></DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=459011520-07102007><FONT face=Arial color=#0000ff size=2>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Cheers,</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Dean</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Dean C. Mikkelsen,
B.Sc., P.Eng.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Terra ETL Ltd. - <A
href="http://www.terraetl.com">http://www.terraetl.com</A></SPAN></FONT></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"></SPAN></FONT><o:p><FONT
face=Arial size=2></FONT></o:p> </P></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> David M. Baker
[mailto:dmbaker@cox.net] <BR><B>Sent:</B> Sunday, October 07, 2007 12:47
PM<BR><B>To:</B> dcmikkelsen@shaw.ca;
gdal-dev@lists.maptools.org<BR><B>Subject:</B> RE: [Gdal-dev] A Question of
Coordinate Storage<BR><BR></FONT></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Dean,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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: <A
href="http://srmwww.gov.bc.ca/gis/bceprojection.html">http://srmwww.gov.bc.ca/gis/bceprojection.html</A>.
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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">David<o:p></o:p></SPAN></FONT></P>
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT
face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Dean C.
Mikkelsen [mailto:dcmikkelsen@shaw.ca] <BR><B><SPAN
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday, October 07, 2007 11:55
AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 'David M. Baker';
gdal-dev@lists.maptools.org<BR><B><SPAN
style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [Gdal-dev] A Question of
Coordinate Storage</SPAN></FONT><o:p></o:p></P></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi
David,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Essentially your
error is increasing exponentially the further away you go from the <st1:place
w:st="on">Central Meridian</st1:place> 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).</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">For example, here in
<st1:State w:st="on"><st1:place w:st="on">British
Columbia</st1:place></st1:State>, 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: <A
href="http://srmwww.gov.bc.ca/gis/sdedata.html">http://srmwww.gov.bc.ca/gis/sdedata.html</A>.
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".</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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 </SPAN></FONT><o:p></o:p></P><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 40,000,000 <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> ---------- <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 360</SPAN></FONT><o:p></o:p></PRE><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></PRE><PRE><FONT face=Arial color=blue size=2><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. </SPAN></FONT><o:p></o:p></PRE>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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).</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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, <st1:State w:st="on"><st1:place
w:st="on">Kansas</st1:place></st1:State>, 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.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Let me know if I can
expand further or answer more questions.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Cheers,</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Dean</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Dean C. Mikkelsen,
B.Sc., P.Eng.</SPAN></FONT><o:p></o:p></P>
<P><FONT face=Arial color=blue size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Terra ETL Ltd. - <A
href="http://www.terraetl.com">http://www.terraetl.com</A></SPAN></FONT><o:p></o:p></P>
<P><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: 0in">
<P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face=Tahoma
size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original
Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B>
gdal-dev-bounces@lists.maptools.org
[mailto:gdal-dev-bounces@lists.maptools.org] <B><SPAN
style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>David M. Baker<BR><B><SPAN
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday, October 07, 2007 8:40
AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B>
gdal-dev@lists.maptools.org<BR><B><SPAN
style="FONT-WEIGHT: bold">Subject:</SPAN></B> [Gdal-dev] A Question of
Coordinate Storage</SPAN></FONT><o:p></o:p></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">All,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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?<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">David<o:p></o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></BLOCKQUOTE></BODY></HTML>