Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV

From: Andrew Daviel <[email-masked]>
Date: Tue, 1 Jul 2003 20:23:07 -0700 (PDT)

On Fri, 20 Jun 2003, John Schnizlein wrote:

> Thank you for the probing questions. Clarification embedded in context:
>
> At 08:38 AM 6/20/2003, Robert Elz wrote:
> >The definitions of altitude in that draft need work.
> >
> >Metres (positive and negative) is simple enough, but relative to
> >what?   Unless I missed it, I could find no definition of what is 0.
>
> Zero is defined by the datum, at least for those we know.
> To cover any cases where it is not, we propose clarifying text as follows:
>    If MU = 1, an AltRes value 0 would indicate unknown altitude.
>    The most precise Altitude would have an AltRes value of 30.
>    Unless otherwise defined by datum, a value of 0 is with respect
>    to mean-low-tide.
>
> >If the assumption is that it is to be "mean sea level" then which sea?
> >If it is to be above (+ or - below) ground level, which ground level
> >within the designated area given by the latitude and longitude (sloping
> >ground).
>
> It is our understanding that mean low tide is well defined, since
> political and personal land-ownership boundaries are based on it.

It depends on the jurisdiction. For instance, it is different in Canada
and the US - one uses mean lower low water and the other uses lowest
normal tide or something as a nautical chart datum.

Defining elevation seems to be more problematic than defining position.
If consumer-grade GPS has a horizontal resolution between 5-30 metres,
that's good enough to give a street or maybe a room in a building. But the
vertical resolution may be double that, and that's 3 floors at best, even
assuming you have ground level sorted out properly. Other navigation
techniques such as LORAN (obsolescent) or cellphone-signal based may not
give elevation at all.

On the other hand, from what I read, survey-grade differential GPS
is currently capable of excellent accuracy (15cm or better), but this is
unlikely to be available in inexpensive mobile devices.

The European GALILEO service will provide greater accuracy than GPS, and I
think I read somewhere that it may penetrate buildings and dense
vegetation better. Augmentation systems such as SBAS, WAAS, EGNOS
seem to provide enhanced accuracy to 3-5 metres, so maybe within a decade
we will have inexpensive devices able to discern which floor they're on
...    http://www.magellangps.com/en/products/aboutgps/ etc.

Andrew Daviel
Vancouver Webpages

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 2 Jul 2003 11:04:44 -0400

Andrew, thank you, this is good information.  To be sure we all
understand each other, please see comments below.  Remember, this
mechanism we are proposing will be most useful for wired network
connections, the easiest type of device to locate (and currently the
largest type of connection used within an enterprise).  Wireless devices
will have to employ a more exotic mechanism possibly at layer 1 or 2 for
a more precise device location.

> normal tide or something as a nautical chart datum.

For those who are struggling with this, it is not our intention to
(re)define zero altitude.  We are simply attempting to provide a
mechanism for people who understand altitude values to share them
amongst each other via a standardized mechanism.  If one were to receive
such data, it is assumed that they will understand the definition of
zero altitude within the jurisdiction/authority from which the data
originated.  Some map datum define zero altitude, some don't.  For those
that don't, we define mean low tide.

> techniques such as LORAN (obsolescent) or cellphone-signal based may
not

Hence our measurement unit of floors.  We are expecting the altitude
data within the MU floors to be derived from the numbers on the wall
next to the elevators, not from a gps or similar device.

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Jul 2003 21:22:21 -0400

> that don't, we define mean low tide.

Like the datum, what's wrong with providing an indication of the unit of 
the measurement?

I think it is generally a bad idea to assume that all parties along a 
chain of transmission know what the data meant initially. This only adds 
a modest number of bits to the format, given that the number of choices 
appears to be on the order of two.

---

From: [email-masked]
Date: Thu, 3 Jul 2003 08:30:29 -0600

I support Henning on the requirement for a UoM. This is why I referenced the
OGC recommendation paper on Units of Measurement. Many geospatial
technologies today - in order to make best use of coordinates - need to know
the UoM.

Regards

Carl

----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
To: "Marc Linsner" <[email-masked]>
Cc: "'Andrew Daviel'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 02, 2003 7:22 PM
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration
Information for GEOPRIV

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Jul 2003 00:13:21 -0500

>Like the datum, what's wrong with providing an indication of the unit of 

OK.... so I'm having a bad day and (perhaps) as a result of this, I don't 
understand what (which?) "unit of the measurement" you are referring to...

It seems to be in relation to Altitude - which we have a unit of 
measurement included already (meters and floors). Do you want additional 
ones defined?

We state that if the datum doesn't define a "0" altitude, we define it as 
"mean low tide". Does this not cover that angle? This seems pointless when 
the altitude is measured in floors, but I could be wrong.

I'm not frustrated, I just don't know what you are referring to here (that 
Carl agrees to)

I need a vacation..... :-/

>chain of transmission know what the data meant initially. This only adds a 
>modest number of bits to the format, given that the number of choices 

cheers,
James

                                *******************
                    The answer is "42", what's the question?

---

From: John Schnizlein <[email-masked]>
Date: Wed, 09 Jul 2003 12:31:21 -0400

At 10:43 AM 7/9/2003, Greg Troxel wrote:

>But almost no one actually understands what altitude means (I didn't
>until I read several geodesy textbooks)...  My point is that referring to
>altitude/height other than with a specific reference to an established
>vertical or 3-dimensional datum is madness.

It seems we don't either. Thank you for the tutorial background.
Is your recommendation that we specify no default?

>For location in the US (sorry for being US-centric; I'm not
>familiar enough with datums in the rest of the world to comment
>precisely), we have multiple possible meanings of altitude:
>  relative to MLLW (nautical charts)
>  relative to NGVD29 (older topo maps, typically NAD27 horizontal datum)
>  relative to NAVD88 (newer topo maps, typically NAD83 horizontal datum)
>  relative to WGS84 ellipsoidal height (not used for civil heights)
>  relative to WGS84 geoid (should match NAVD88 closely enough for
>        "mapping purposes")
>
>The latter is what a typical GPS receiver produces.  GPS receivers
>calculate positions on the ellipsoid (obtaining an ellipsoidal height)
>and apply a geoid model to obtain an estimate of orthometric height.
>
>This is all overkill for geopriv, but I'm really uncomfortable with a
>notion that altitude is in a local convention for datums that don't
>define altitude.  Even this is ambiguous: the North American Datum of
>1983 is a horizontal datum, but "everybody knows" that orthometric
>heights given in conjunction with this datum are in NAVD88.  Except on
>nautical charts.
>
>  From: "James M. Polk" <[email-masked]>
>  Date: Wed, 09 Jul 2003 00:13:21 -0500
>
>  We state that if the datum doesn't define a "0" altitude, we define it
>  as "mean low tide". Does this not cover that angle? This seems
>  pointless when the altitude is measured in floors, but I could be
>  wrong.
>
>Altitude should always have a datum.  Using orthometric height
>relative to the WGS84 geoid is a fine default choice.  Mean low water
>only makes sense at the shore; WGS84 is defined globally.
>
>There should be two datums: horizontal and vertical.  For datums which
>are 3-dimensional, like WGS84, the same code can be used in both
>slots.  Either that, or datum codepoints should be required to be
>either a 3-D datum or a pair of horizontal/vertical datums
>(e.g. NAD83/NAVD88).  The use of pairs is really quite natural;
>vertical and horizontal datums were typically developed alongside each
>other.  (This must be defined already in other standards, but the "if
>no vertical datum then use mean low water" makes me think not quite
>enough of another representation was adopted.)

Are you recommending that the default for altitude be WGS84 if not
otherwise specified by the datum value in the option?

>Perhaps we should define a 'floor' datum.  Floors aren't really a
>"unit of measurement", since they aren't necessarily the same size, 13
>might not exist, etc.  The floor datum is simple: the value is a
>number (no units), and corresponds to elevator labeling if there are
>elevators, or posted labels if those exist.  If not, 1 is where people
>normally enter, and whole/half flights of stairs change value by
>1/0.5.  Floor levels are very useful, perhaps more so than orthometric
>height in buildings, but we shouldn't try to make them into an
>altitude, since they simply don't have the same properties.  And every
>building is different; a floor number without an identified building
>doesn't make sense.

It was not our intent to make floors into altitudes.
Since your tutorial demonstrated that most of us do not understand
"datum", this term is probably not better than "unit of measurement".
There is no requirement that all units of measurement have the same
scale properties; some might be only nominal or ordinal measurement
units (like hardness), but others might be interval (ratios of 
differences meaningful, like degrees of temperature) and others might 
have meaningful ratio measurement properties. We need not get into
the depths (pun intended) of measurement theory for this term.

>...
>I haven't been following very closely; sorry if I'm off in space or
>seeming difficult.  I think that trying to follow established geodetic
>practice will make some things smoother.  For those people that don't
>know their altitude, it won't matter anyway.

We are happy to accept specific text that makes this document better
"follow established geodetic practice". Is it just the default for
altitude for which you want to recommend text?

John

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Jul 2003 14:42:42 -0500

At 01:39 PM 7/9/2003 -0400, Henning Schulzrinne wrote:
>James M. Polk wrote:
>
>
>I gather the datum for long/lat does not uniquely define the datum for 
>altitude.

Our original datum was WSG84 (geoid or 3D) which has a vertical datum along 
with lat/long - and we added the UoM of floors for wired devices (one of 
the primary reqs of this effort) because for emergency responders in 
buildings - a meters of altitude value was determined to be too vague 
(which floor is 63 meters up?), thus necessitating "floors" be included 
instead of meters.

Floors have an established "0" as written in this ID.

We also included text stating that ~ 'if the datum does not include an 
altitude datum, consider "0" altitude to be "mean low tide" '. Perhaps we 
didn't take the same preciseness of altitude into account that we did for 
lat/long. We favored the view that precision of altitude in meters wouldn't 
be as important as it is in lat/long. We're obviously being corrected for 
that now.

However, I presently don't favor a move to separate the current altitude 
field into two: one of altitude (in meters for example), and one for floors 
(exclusively). I don't yet see the reason why both should reasonably ever 
be included at the same time. Parsing on the Altitude UoM field to see how 
the Altitude value should be interpreted should be sufficient here.

Adding text defining altitude, I have no problem with. I look forward to 
Greg's opinion (and hopefully text to this) to resolve this issue of 
clarity. We should state what's most reasonable towards defining or scoping 
altitude, and yet not try to solve (within an IETF document) that which 
(per Greg) hasn't been resolved by Geoloc focused people for more than a 
century (re: vertical datums).

Does this sound fair?

cheers,
James

                                *******************

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Jul 2003 15:16:45 -0500

At 02:21 PM 7/9/2003 -0400, Greg Troxel wrote:
>John Schnizlein <[email-masked]> writes:
>
>not quite.  My recommendation is that the protocol not be capable of
>encoding altitude without an associated vertical datum, since that
>combination doesn't make sense.

This seems reasonable

>That is one reasonable choice.  The other is to change the datum to be
>a pair in such cases.  Using WGS84 height with older datums strikes me
>as odd; such old horizontal datums generally have associated old
>vertical datums.
>
>In draft-ietf-geopriv-dhcp-lci-option-01.txt,
>
>I suggest changing "MU" and "Measurement Unit" to "AT" and
>"Altitude Type".  Define code 1 to be "Altitude (orthometric height,
>not ellipsoidal height) in the specified datum, expressed in meters.".
>
>This doesn't change the semantics much, but it provides a datum
>reference, and makes clearer that the different between MU=1 and MU=2
>is more than using meters or feet; the type of measurement (m in WGS84
>and floor) are far more different than that.
>
>The 'floors' text is not precise enough to be interoperable.  How
>about replacing it with:
>
>   The "floors" Altitude Type is provided because altitude in WGS84 may
>   not be known within a building, and a floor indication may be more
>   useful.  The value 0.0 for floor is meaningful even outside a
>   building, and represents ground level at the given latitude and
>   longitude.  Inside a building, 0 represents the floor level
>   associated with ground level at the main entrance.  This document
>   defines a number; one must arrive at the number by counting floors
>   from the floor defined to be 0.
>
>   Note that this definition will differ from conventional usage for
>   floor labeling in the US; some sort of locale support may be needed
>   for presentation of this information to users.  A further
>   complication is that floors in buildings can be labeled "M", "L",
>   "G", or "B".

I like your suggestion up until the last part. The M, L, G, or B floors 
(which they are) are to be denoted as x.1, x.2, x.3 etc. This was text that 
existed once - but was somehow was left out of the current version (my 
fault as editor though I don't remember when this happened), but was 
covered in an email to both dhc and geopriv lists by Marc Linsner dated 
6/20. This text regarding sub-floors (or in between floors) will be included.

>It seems that there is no way to provide both altitude and floor.  I'm
>not sure this is good.  In general the altitude type scheme heads down
>the path of blurring geodetic coordinates and civil location
>information.

This ID  is intended to get emergency responders to wired device locations. 
That is a very limited scope. Of course this can be used for wireless 
devices, but the amount of precision becomes an issue at that point.

>Having read what I just wrote, it seems that "floor" should be a
>string, not a number,

this will make the string variable and would make version longer than the 
originally proposed length of the Option. hmmmm

>so that it can contain whatever value is written
>on the walls outside the elevators.

In between floors (like mezzanines) are to be denoted with the x.1, x.2, 
etc value. This should solve this.

>So I must recommend that the
>floor type be deleted and left to the civil location object.

Your suggestion changing the measurement unit to altitude type (AT = 1 
means meters, AT = 2 means floors) is a preferable solution here. Floors is 
pretty important to this effort, and I don't really want to delete its 
benefit if possible.

>In section 5, text for MU=1: remove "from mean low tide" (it is
>inaccurate), and replace with "in the specified vertical datum".

ok

>In section 2.1, amend the datum description by adding after the
>"Datum:" line:
>
>   The datum must be both a horizontal and a vertical datum.  Some
>   datums, such as WGS84, are both.  For others, such as NAD83, a datum
>   codepoint denotes both a horizontal datum and an associated vertical
>   datum.

ok

>In codepoint 4, add:
>   The associated vertical datum is the North American Vertical Datum
>   of 1988 (NAVD88).

ok

>I don't know what the corresponding vertical datums are for ED50 and
>ED87.  They may well be different in different countries; I suspect
>this is particularly true for ED50.  There seems to be something
>called European Vertical System 2000 (EVS2000); this is perhaps
>appropriate with ED87.

hmmmm

>We are in need of a European
>geodesy nerd.

I agree with this

>The following paper may be interesting, but only if you thing the
>notion of height is fun: http://www.wettzell.ifag.de/publ/publ/wtz142.pdf
>
>The inclusion of ED50 (which is not a "modern" datum, meaning that it
>isn't tied into a global system) raises the issue of inclusion of
>NAD27, a similar datum for the US.  That begs the question of datums
>for India and the Far East.

Carl Reed wanted ED50 and ED87 included, so we put them in. We have 255 
available choices to include (from EPSG's 264 listed datums).

Should we include NAD27, or delete ED50 (and or ED87)?

>Stepping back, coordinates in all of these datums can be converted
>into WGS84 (or ITRF).  So arguably there should be just one
>on-the-wire format for geodetic location, and WGS84 seems like a good
>choice.

This was our original plan

>Otherwise hosts have to deal with conversion, or
>location-carrying protocols have to represent multiple datums.  My
>view is that people/hosts/organizations which are capable of
>generating location information sufficiently accurate for the datum to
>matter (hundreds of feet) are either using GPS (hence WGS84 already)
>or knowledgeable enough to perform datum transformations.
>
>If people object to a coordinate system defined by the US
>DOD, we could specify ITRF instead (but the values will remain the
>same unless one is at the centimeter level, more or less).  See
>http://www.iers.org/iers/products/itrf/ I recommend sticking with
>WGS84.  I would be shocked if altitudes obtained with Galileo differ
>from WGS84 or ITRF by any noticeable fraction of accuracy achieveable
>with normal GPS receivers - all the modern horizontal and vertical
>datums seem to be aligning with ITRF.  WGS84 itself has been revised
>twice.
>
>If you don't want to make datums a pair (I see the downside in
>complexity), modify the altitude to specify that it is always in
>WGS84, regardless of the horizontal datum.

Looking for others to state whether this is a good idea (Carl and/or 
Nadine?)....

This seems reasonable to me, but others have a more vested interest in 
which datums are included I think

>Add a normative reference to WGS84.  See
>http://164.214.2.59/publications/specs/printed/WGS84/wgs84.html
>This is MIL-STD-2401, published by NIMA.

Thank you for this, I'll include it

>--
>         Greg Troxel <[email-masked]>

cheers,
James

                                *******************

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 10 Jul 2003 09:27:41 -0400

Greg, thanks for the input, wish we could have chatted 12 months ago :^)

> 
> This still begs the question of why use geodetic coordinates instead
> of a civil location, if the latter is what you need.  I presume the
> civil location option serves the latter purpose.

Civil location obviously works well for emergency services when summoned
from a known building. Standardization of civil location for transport
is another issue, especially on a global basis (how many different
'datums'?), and Henning is working feverishly on this.  One reason
behind geo-loc is due to the fact that in the US, PSAPs that are Phase
II wireless enabled are already receiving lat/lon/alt from the wireless
vendors.  PSAPs today are requesting GIS systems that are aerial photos
with a very high degree of resolution (3cm).  They have the ability to
pinpoint the geo-loc received from the carrier onto the map for a very
accurate location.  Obviously maps will supply civil location given a
geo-loc.  So, in an attempt to find a single object type for emergency
services location, geo-loc will serve all, where civil will not. I do
believe that both types have a place and are needed for several years.

Another aspect, geo-loc is machine to machine language, sometimes not
easily interpreted by humans, whereas civil location can be viewed as
the human interpretation of the geo-loc.  Since geo-loc info can be
turned into civil location with a variety of means (very cheaply), why
not use the much smaller, easier to transport, 'what we thought was more
standard' geo-loc for machine to machine communication and let the
wonders of our modern machinery convert it to something a human can
understand?

> 
> lat/lon/floor still seems odd to me.  Floor will matter only in large
> buildings, and those tend to be close together (in cities).  This
> environment (urban canyon) is precisely where GPS works the least
> well, due to blocked sky views and large amounts of multipath
> interference.  So here, I think a civil location is really desired.

We are advocating that this geo-loc configuration information be passed
from a DHC server to a wired device that would not have a GPS installed.
The wire map database could be built from a gps, or a gis type service
that would supply the geo-loc coordinates to a building operator for use
in the wire map. The geo-loc would show up on the PSAP GIS map and show
quadrant of the building along with floor of the caller.  It may also be
desirable that the GIS software hold any other 'local knowledge' that
the building operator and emergency responders deem necessary.

We also envision that there is nothing wrong with the PSAP receiving
both the geo-loc and civil loc information at call setup time if
available.  Obviously SIP and GeoPriv have work to do to pass this
information along.

So in our trek to utilize a more 'standardized' method to express
location, we are now finding that geo-loc is almost as ugly as civil
location in this respect.

Are you going to be in Vienna?

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jul 2003 12:51:02 -0400

Greg Troxel wrote:

> 
> Perhaps civil locations should have a datum codepoint that uses
> address and building # as the horizontal datum and floor as the
> vertical datum.

Good point; I've added this to the civil location draft.

---

From: Greg Troxel <[email-masked]>
Date: 09 Jul 2003 10:43:24 -0400

But almost no one actually understands what altitude means (I didn't
until I read several geodesy textbooks). Datums and jurisdictions
don't map cleanly; many jurisdictions have maps with several datums
still in current use - near Boston a map/chart could have any of three
vertical datums.  Most older datums are only horizontal or only
vertical.  Depths on nautical charts are almost always relative to
some (regionally varying) form of low water, but heights on land are
usually not.  What we usually call altitude is more precisely referred
to as "orthometric height", which is the distance along the plumb line
(normal to the gravity field) to a reference equipotential surface
called the geoid, loosely known as Mean Sea Level.  Vertical datums
(such as National Geodetic Vertical Datum of 1929, and the North
American Vertical Datum of 1988) were orginally based on some notion
of mean sea level at tidal stations, and extended by leveling
(following the equipotential and measuring the distance travelled
vertically).  But, the distances between equipotential surfaces change
as you move horizontally due to variations in the gravity field, so
leveling doesn't quite get you orthometric height.  So height in a
vertical datum is really relative to heights of nearby benchmarks,
whose height values have been established by leveling and a
least-squares adjustment.  My point is that referring to
altitude/height other than with a specific reference to an established
vertical or 3-dimensional datum is madness.

See the following slide for a hint of the complexities:

http://www.prism.washington.edu/educatin/forum99/Findlayson/sld009.htm

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jul 2003 13:39:09 -0400

James M. Polk wrote:

> 
> OK.... so I'm having a bad day and (perhaps) as a result of this, I 
> don't understand what (which?) "unit of the measurement" you are 
> referring to...
> 
> as "mean low tide". Does this not cover that angle? This seems pointless 
> when the altitude is measured in floors, but I could be wrong.

---

From: Greg Troxel <[email-masked]>
Date: 09 Jul 2003 14:36:21 -0400

Exactly.  Older datums (pre navigation satellite) are either
horizontal only or vertical only.  There is a newer group (WGS84,
ITRF) which are three dimensional.

The reason for the split is that classical geodetic methods for
determining horizontal coordinates (chaining and tapes for distance
and optical measurement of angles) and vertical coordinates (use of
telescopic levels to transfer vertical location horizontally, and
measuring rods for measuring vertical distance) had very little to do
with each other, and the measurement campaigns were often separate.
Modern geodetic practice makes use of satellite measurements which
result in three-dimensional position differences between stations.

But, as I pointed out in the message I just sent, there is generally a
vertical datum associated with a given horizontal datum.  By
associated, I mean that, e.g., I suspect that well over 90% of all
maps in NAD27 use NGVD29.  So there is not a lot to lose by defining a
codepoint for a pair; the combinatorial explosion won't arise.  E.g.,
ED50 and NAVD88 is simply not a sensible combination - I'm willing to
bet there are no actual maps in that combination.

This wouldn't be so confusing if it were not for nautical charts,
which use different vertical datums.  The question is "will my ship
hit the bottom", which drives the reference surface to Mean Lower Low
Water.  I hold that the presence of such charts makes it necessary to
be unambiguous about the height reference system.  There are current
charts with NAD83 horizontal datums and MLLW vertical, and current
maps with NAD83 horizontal and NAVD88 vertical.  So NAD83 does not
have an unambiguous associated vertical datum.

---

From: Greg Troxel <[email-masked]>
Date: 09 Jul 2003 16:46:30 -0400

"James M. Polk" <[email-masked]> writes:

> I like your suggestion up until the last part. The M, L, G, or B
> floors (which they are) are to be denoted as x.1, x.2, x.3 etc. This
> was text that existed once - but was somehow was left out of the
> current version (my fault as editor though I don't remember when this
> happened), but was covered in an email to both dhc and geopriv lists
> by Marc Linsner dated 6/20. This text regarding sub-floors (or in
> between floors) will be included.

OK.  Modulo process concerns about whether a new draft and last call
period is needed - I have serious questions about how unambiguously
this can work in practice in terms of an EMT knowing where to go when
getting a 0.3 location code, unless the floors have signs that say
"You are now on DHC-LCI Floor 0.3" :-)

> This ID  is intended to get emergency responders to wired device
> locations. That is a very limited scope. Of course this can be used
> for wireless devices, but the amount of precision becomes an issue at
> that point.

> means meters, AT = 2 means floors) is a preferable solution
> here. Floors is pretty important to this effort, and I don't really
> want to delete its benefit if possible.

But how to communicate with emergency responders is not my area of
expertise - in my town it's "where the texaco station used to be",
just like in the jokes.

> Carl Reed wanted ED50 and ED87 included, so we put them in. We have
> 255 available choices to include (from EPSG's 264 listed datums).
> 

I'm probably the closest to someone who needs NAD27, and I don't think
it should be included.  I use paper and scanned topo maps in NAD27,
together with GPS-derived positions (in WGS84), and convert
coordinates as needed.  Geocoding and any public safety systems have
already gone to NAD83/WGS84.

NAD83 is considered equivalent to WGS84 for mapping and charting
purposes.  I've seen this stated on both DMA (now NIMA) maps and
nautical charts.  People who care about the NAD83/WGS84 difference
won't be happy with 3mm resolution.  So I don't see a justification to
include NAD83 - it seems like needless complexity.

Carl:

Are European police/fire/ambulance really set up to accept ED50
coordinates and be able to arrive (rather than WGS84)?

Is ED87 really different from WGS84 (within areas where ED87 is used,
beyond a meter or so)?

Is this about not using a US coordinate system?  If so, I'd be happy
to replace WGS84 with "the most recently published International
Terrestrial Reference Frame" - functionally equivalent for our
purposes (same coordinate values to well within a meter).
This would avoid the US-defined coordinate system and leave us with a
single datum.

---

From: Greg Troxel <[email-masked]>
Date: 09 Jul 2003 14:21:28 -0400

Having read what I just wrote, it seems that "floor" should be a
string, not a number, so that it can contain whatever value is written
on the walls outside the elevators.  So I must recommend that the
floor type be deleted and left to the civil location object.

In codepoint 4, add:

appropriate with ED87.  We are in need of a European
geodesy nerd.

choice.  Otherwise hosts have to deal with conversion, or

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 10 Jul 2003 19:45:31 -0600

See embedded comments -

Carl

> understand what (which?) "unit of the measurement" you are referring to...
units of measurement (UOM) typically are feet, meters, centimeters, yards,
rods, etc. elevation in the geospatial world is usually measured in either
feet or meters -not floors :) Any geospatial metadata that conforms to
either the FGDC or ISO metadata standards will have UOM as one of the
fields.
> >chain of transmission know what the data meant initially. This only adds
a
> >appears to be on the order of two.
Right. That is the whole reason for metadata. Add a couple of bits to deal
with UOM and you most likely will save many potential head aches down stream
(or in he  future).

---

From: Dominic Pinto <[email-masked]>
Date: Mon, 21 Jul 2003 07:23:31 +0100

1 MB of an attachment - and some of us are on dial up connections on
this list (in rural Wales, at about 33kbps)!
> 
> Yes, Greg - Thank you for taking the time to do this research.
> 
> I should note that most commercial GIS in use today simply assume mean sea
> level as the point of origin for base "0" for altitude. This works OK for
> numerous GIS (non-survey!) applications, especially when working large
> scale. This is partly due to the fact that many GIS type applications work
> fine as long as all the elevations are in relation to one another.
> 
> In any case, I have attached a really good set of slides on Geodesy that one
> of our members (a professional geodesist) put together to help educate the
> OGC membership. I should have sent this earlier, but had forgotten we had
> this presentation.
> 
> Hope the meetings in Vienna went well!
> 
<snip>

-- 
Dominic Pinto
-------------

Independent Adviser
Public & International Policy - Strategy - Regulation - PR - Commercial
Covent Garden London United Kingdom
----------------------------------------------------------------------
Cellphone/GSM Mobile: +44 780 302 8268 Fax: +44 207 379-8341
----------------------------------------------------------------------

---

From: "Carl Reed" <[email-masked]>
Date: Sun, 20 Jul 2003 16:11:06 -0600

Regards

Carl

----- Original Message -----
From: Greg Troxel <[email-masked]>
To: Marc Linsner <[email-masked]>
Cc: 'Andrew Daviel' <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 09, 2003 8:43 AM
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location
ConfigurationInformation for GEOPRIV