Subject: [Ecrit] draft-ietf-lost-00 and lost regions

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Jul 2006 14:44:47 -0700

In the responseGeo messages, I'm not sure I understand what the  
Polygon gets used for. I'm assuming this is so a device like a mobile  
phone can determine when it moves outside the polygon and needs to  
redo the query or should not use the service URI provided in that  
response. I'm a little worried about the geographic size and accuracy  
of these polygons, the size of the response on the wire,  and the  
complexity on the device of determining if a point is inside the  
polygon. I realize I may have mistaken assumptions here.

If the polygon is defined as a polygon that includes the query  
location and is guaranteed that the URI work anywhere within the  
polygon, then the polygon could be a small subset of the overall  
region where the URIs are valid. This combined with some constraints  
on how the polygons were generated might  help deal with complexity  
and size issues. Depending on what this data is used for, there might  
be other ways to solve this too - for example, the response providing  
a distance from the query location with a guarantee that any place  
with that distance of the query point was within the region with the  
same service URI. This approach would have problems near the edge of  
the PSAP boundary but I'm just tossing out ideas.

I also wonder about how much of the GML polygon you really want - for  
example - do you want to deal with interior holes. Would you allow  
reference links (i.e. points instead of pos) to define the polygon.

Cullen

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 2 Jul 2006 19:29:56 -0400

On Jul 2, 2006, at 5:44 PM, Cullen Jennings wrote:

> Polygon gets used for. I'm assuming this is so a device like a  
> mobile phone can determine when it moves outside the polygon and  
> needs to redo the query or should not use the service URI provided  
> in that response. I'm a little worried about the geographic size  
> and accuracy of these polygons, the size of the response on the  
> wire,  and the complexity on the device of determining if a point  
> is inside the polygon. I realize I may have mistaken assumptions here.

This probably can be explained better, but the idea is that the  
polygon does not have to be terribly accurate. For example, you could  
embed a square or octagon in the county and do reasonably well until  
you reach the edges. At that point, the system may need to provide a  
more accurate rendition.

Doing a point-in-polygon computation is relatively low cost, even for  
very large polygons.

We have looked at typical county boundaries for the US, as provided  
by the US Census, and found that they are too large for a UDP packet,  
but not unreasonably large. In almost all circumstances except cross- 
country driving, the client would cache these in any event, as these  
boundaries are unlikely to change. (We took county boundaries as an  
approximation, realizing that PSAP and county boundaries may or may  
not coincide, but the properties should be somewhat similar.)

> region where the URIs are valid. This combined with some  
> constraints on how the polygons were generated might  help deal  
> with complexity and size issues. Depending on what this data is  
> used for, there might be other ways to solve this too - for

This sounds similar to the notion discussed above.

> example, the response providing a distance from the query location  
> with a guarantee that any place with that distance of the query  
> point was within the region with the same service URI. This  
> approach would have problems near the edge of the PSAP boundary but  
> I'm just tossing out ideas.

The distance computation you mentioned can be done at the client, if  
desired. You can do other optimizations; for example, if you move  
along a relatively straight line (common while driving on a highway,  
say), the distance to the border of the polygon can be computed  
fairly accurately so that you do not have to do the point-in-polygon  
computation every few seconds and only have to re-check once you get  
close to the boundary.

>
> I also wonder about how much of the GML polygon you really want -  
> for example - do you want to deal with interior holes. Would you  
> allow reference links (i.e. points instead of pos) to define the  
> polygon.

I think we have to deal with interior holes. These are not common,  
but apparently occur; the example I've been given is airports that  
have their own PSAP, surrounded by the county.