Subject: Re: AW: [Geopriv] Quick random comments ondraft-ietf-geopriv-pdif -lo-profile-00

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Jul 2005 20:52:26 -0400

James Winterbottom wrote:
> Henning,
> 
> By uncertainty I am assuming that you mean precision, that is I am 
> equally likely to be anywhere with in this area or volume, then I see 3 
> ways of representing this, depending on what information I am given to 
> start with.

Right; sorry to confuse the terms.

> If I am given Geo as defined in RFC-3825 and altitude is not required, 
> then a polygon is best, as this copes with the 180th meridians quite 
> well. If altitude is required, then polygon doesn't work, as I don't 
> know at which value in the range of altitudes to specify my vertices. In 
> this case I can opt for an Enveloped bounding box and this will allow me 
> to define a very nice rectangular prism, you have to careful around the 
> 180th meridians as bounding boxes do not like to cross them.

I don't quite see the need for this much complexity. Unless you're 
talking about airplanes, which are unlikely to use DHCP to determine 
their location, in the practical cases I can think of, a simple polygon 
projected to the ground (or the lower range of the altitude) and an 
altitude range will do reasonably well, i.e., keeping the two separate.

> 
> If we were to get out geo from a GPS or something like that that 
> specifies a simple point, then a radius may be a better way to go.

Agreed.

> 
> I think that restrictions are good, but there are horses for courses. I 
> think that the 3 I have mentioned are sufficient for most cases that I 
> can think of.

 From a practical perspective, I think 3825 made a mistake in coming up 
with its own, rather peculiar, means of doing precision that has no 
relationship to measurement technologies, but that's water under the 
bridge. I don't think it will get much real use, so having 2 simpler 
versions (circle + polygon) seems sufficient to me.

We need polygon specs for other things, so that's also useful outside 
the immediate context. (Just as an example, civic-to-geo translations 
may generate polygons since civic addresses rarely refer to a point.)

My concern is that specifying additional, geometrically somewhat messy, 
options complicates the job for receivers. The third option will be used 
so rarely for any real purpose that it won't be tested and thus break 
things badly when it shows up every blue moon.

Henning

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

---

From: "James Winterbottom" <[email-masked]>
Date: Wed, 6 Jul 2005 10:39:48 +1000

Henning,

By uncertainty I am assuming that you mean precision, that is I am equally
likely to be anywhere with in this area or volume, then I see 3 ways of
representing this, depending on what information I am given to start with.

If I am given Geo as defined in RFC-3825 and altitude is not required, then
a polygon is best, as this copes with the 180th meridians quite well. If
altitude is required, then polygon doesn't work, as I don't know at which
value in the range of altitudes to specify my vertices. In this case I can
opt for an Enveloped bounding box and this will allow me to define a very
nice rectangular prism, you have to careful around the 180th meridians as
bounding boxes do not like to cross them.

If we were to get out geo from a GPS or something like that that specifies a
simple point, then a radius may be a better way to go.

I think that restrictions are good, but there are horses for courses. I
think that the 3 I have mentioned are sufficient for most cases that I can
think of.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Wednesday, 6 July 2005 10:07 AM
To: Tschofenig, Hannes
Cc: GEOPRIV
Subject: Re: AW: [Geopriv] Quick random comments
ondraft-ietf-geopriv-pdif-lo-profile-00

Tschofenig, Hannes wrote:

> a motivating example would certainly help.
> 
> one example is the currently specified dhcp-geo where floor is 
> combined with geospatial location info.

Given that we have very limited deployments (to put it generously) of 
either civic or geo options, another path forward to consider: Deprecate 
the use of floors in the geo DHCP option and don't carry it in PIDF-LO 
unless it is part of the full civic option. Logically, floors were 
always a bad fit for the geo option, but necessary until we had others.

The geo floor option has known problems (cannot represent certain 
floors) and I can't picture a scenario where the floor (and geo) is 
known, but the street address isn't. Having to merge floor and country 
information from geo and civic just adds complexity and error cases, for 
no increase in functionality.

> i have seen the jabber location document and i fully agree with you 
> that we should be as simple as possible.

We really only four things to create a deployable system:

(1) How to represent a simple geo coordinate pair + altitude (however 
derived, whether by GPS or DHCP) in PIDF-LO/GML.

(2) Add the missing civic elements to PIDF-LO.

(3) Describe uncertainty in exactly one way.

(4) Deal with the combination of civic + geo (and rule out various other 
combinations of geo + geo, civic + civic, etc).

> i also hope to shorten it although i think it might be good to have 
> more examples.
> 

I agree that examples are a very good thing.

Henning