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

Greg Troxel <gdt@ir.bbn.com> Thu, 10 July 2003 17:36 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13601; Thu, 10 Jul 2003 13:36:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afKs-00056l-NU; Thu, 10 Jul 2003 13:36:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLpi-00031s-SG for dhcwg@optimus.ietf.org; Wed, 09 Jul 2003 16:46:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21270 for <dhcwg@ietf.org>; Wed, 9 Jul 2003 16:46:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLpg-0003FJ-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 16:46:32 -0400
Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx with esmtp (Exim 4.12) id 19aLpf-0003FG-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 16:46:31 -0400
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id EA0F020C3; Wed, 9 Jul 2003 16:46:30 -0400 (EDT)
To: "James M. Polk" <jmpolk@cisco.com>
Cc: John Schnizlein <jschnizl@cisco.com>, dhcwg@ietf.org, geopriv@mail.apps.ietf.org
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV
References: <4.3.2.7.2.20030709121509.02189db8@wells.cisco.com> <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <4.3.2.7.2.20030709121509.02189db8@wells.cisco.com> <4.3.2.7.2.20030709144352.056623a8@localhost>
From: Greg Troxel <gdt@ir.bbn.com>
Date: Wed, 09 Jul 2003 16:46:30 -0400
In-Reply-To: <4.3.2.7.2.20030709144352.056623a8@localhost>
Message-ID: <rmi7k6rzavt.fsf@fnord.ir.bbn.com>
Lines: 84
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

"James M. Polk" <jmpolk@cisco.com> 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" :-)

> >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.

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.

> 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.

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.

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.

> >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)?

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.

-- 
        Greg Troxel <gdt@ir.bbn.com>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg