Subject: Re: [Ecrit] Location information in emergency session initiation, need for time and accuracy?

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Sep 2006 11:46:00 -0500

Vesa

comments in-line

At 10:57 AM 9/7/2006 +0300, [email-masked] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6D253.3D9266A5"
>
>Hi all,
>
>When establishing an emergency session, a SIP UA may insert its location 
>information into SIP INVITE as PIDF-LO object.

correct

>  The location information is used to route emergency session to correct 
> PSAP and if the location is accurate enough,

"accurate enough"? What at this point would determine if it is accurate enough?

>it can be used to advise the rescue team where needed. Delay of the 
>emergency session establishment needs to be minimized and therefore UA may 
>have to use old location information or provide it later during the call.

The phone may not have moved in a while, so the old location info may still 
be good, as much as some believe "the world has gone mobile, most phones 
are not mobile, so it shouldn't be assumed every phone has moved since last 
receiving location information.

>Would it be beneficial to provide some kind of time stamp and accuracy 
>information for the location?

there is a timestamp (when the tuple was created), there is (on purpose) no 
accuracy. Please see the old archives within the Geopriv WG mailing list 
for this reasoning - that discussion was long and extensive, and seems to 
be rehashed every once in a while.

>RFC 4119 (PIDF-LO) does not define accuracy of the location information.

nope

For example, take a typical phone off an Ethernet connection. How would 
accuracy be measured in this common scenario? Would it look like this:

         "I'm within 3 streets of Main st"?
or
         "I'm within 3 cities of NYC"?

Is the accuracy for Ethernet connected phones always the same? If not, what 
informs the phone it is different (since the phone is the generator of the 
PIDF-LO)?

BTW - RFC3825 has resolution as part of its solution.  This creates a GML 
defined Linear Ring, which is 100% accurate 100% of the time that the 
target is within that ring.  This concept can be taken out to a cell 
tower's coverage area too (i.e. provide the polygon - regardless of shape - 
the target is within in the PIDF-LO).

>It defines timestamp for presence tuple, which indicates the time of the 
>last change in the tuple. Maybe that timestamp is enough when geopriv is 
>the only status element of the tuple but could there be other status 
>elements in the future? I guess this would be relevant not just for 
>emergency calls but also for location services in general, where time and 
>accuracy of the location could be used for many purposes.
>
>How do you people see the relevancy of this kind of additional information 
>for emergency calls? Would it be worth investigating how to extend PIDF-LO?

Geopriv chose not to have accuracy in the PIDF-LO, including the lack of 
uniformity and the lack of a means of measuring it

>There has been some discussion about this also in 3gpp but no real 
>conclusions.
>
>Br,
>         Vesa Hakkarainen
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 07 Sep 2006 13:23:53 -0400

James M. Polk wrote:
> there is a timestamp (when the tuple was created), there is (on purpose) 
> no accuracy. Please see the old archives within the Geopriv WG mailing 
> list for this reasoning - that discussion was long and extensive, and 
> seems to be rehashed every once in a while.

Perhaps an Informational RFC on this specific topic is in order... one that 
discusses the problem and explains the consensus... and one that we can use 
to say "see RFC 5001".

> BTW - RFC3825 has resolution as part of its solution.  This creates a 
> GML defined Linear Ring, which is 100% accurate 100% of the time that 
> the target is within that ring.  This concept can be taken out to a cell 
> tower's coverage area too (i.e. provide the polygon - regardless of 
> shape - the target is within in the PIDF-LO).

It's good that you bring this up.  I'm beginning to think that we need to 
tightly define the GML used for LoST.  I don't know what a LoST server is 
suppose to do if a Linear Ring is bisected by multiple PSAP boundaries.

Perhaps LoST input should only be a point and the service boundary should 
only be a polygon.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 7 Sep 2006 13:53:46 -0400

> discusses the problem and explains the consensus... and one that we can
Agree.  I nominate James Winterbottom as editor.  If I can help (I don't
know much) I will.

> suppose to do if a Linear Ring is bisected by multiple PSAP boundaries.
Agree we need text for this
 
> Perhaps LoST input should only be a point and the service boundary should
I would oppose this; I think the server should be free to accept a more
complex shape, say a polygon, and intersect it with the boundaries.  

The service boundary has to at least be a SET of polyhedrons (3D polygons).
I think it would be acceptable to limit to that.

I think we could say that if the LoST server can't do anything better than
point in polygon, it should take a location specified as a polygon and
determine the centroid, and use that point to intersect with the service
boundaries.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Thu, 07 Sep 2006 14:02:35 -0400

> Agree.  I nominate James Winterbottom as editor.  If I can help (I don't

I was actually thinking of Mr. Polk.  But whatever...

> determine the centroid, and use that point to intersect with the service

What you are asking might be ok for a LoST authoritative server.  But just 
what is a LoST resolver suppose to do with a set of polyhedrons?  And what 
happens when PSAP service boundaries bisect these areas?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Sep 2006 14:03:02 -0400

There are two issues:

- service boundaries; I don't know why we need 3 dimensions as a 
requirement. I have no objection to allowing such shapes from a protocol 
perspective, although the use cases so far have been non-existent or 
fanciful.

- point of query; having more than a point is both useless and 
dangerous. Otherwise, you have to be able to return all service 
providers that intersect that area, which means that the querier can 
specify a polygon encompassing the continental boundaries of all of 
North and South America and somehow get back every single PSAP in dozens 
of countries. This makes the backend system very much more complex, as 
ensuring that you indeed obtained all such information, with complete 
coverage, is rather difficult. You've just asked for a depth- or 
breadth-first exploration of the whole LoST server space. Kind of like 
asking for a recursive zone transfer for DNS...

Thus, for the practical uses we care about, having a restriction to 
simple points-in-polygon avoids a rather dramatic increase in 
complexity, without impinging the legitimate uses. The client can 
compute that point at least as well as the server can and the client can 
decide whether it cares that different points in the polygon might have 
different service providers.

I'm for simplicity and the 80/20 rule.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 7 Sep 2006 14:37:11 -0400

I thought I heard you giving use cases.  As I recall, it was something like
a university with a local EMS responder occupying some number of floors of a
building.

Agree that the important part is to allow it in the protocol.

The way you use a polygon or polyhedron as a query location I think is
called "best fit".  If I have, to take an example, a set of tower faces, and
set of service boundaries the server would do a best fit comparison of the
tower face and the available service boundaries.  Best fit is not all that
hard to compute (intersection area).

I don't want to force everyone to do this.  I want to allow it.

I never want to return a set of possibilities.  You always get one.  To me
this is the same as not putting the LoST server in the position of choosing
which of several reported locations to use to choose a route.  The client
chooses ONE.  The same argument applies in reverse here: the LoST server
never says "well, it could be this or it could be that", and lets the client
try to figure out what to do.  It always sends THE answer.

The answer I would expect you would get if you send the boundary of the U.S.
as the query location would be the same you would get if you sent a civic
with only a country: some default PSAP.  Or an error (but then what does the
client do?).

Brian  

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 2:03 PM
> To: Brian Rosen
> Cc: 'Andrew Newton'; 'James M. Polk'; [email-masked]
> Subject: Re: [Ecrit] Location information in emergency session initiation,
> need for time and accuracy?
> 
> There are two issues:
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Sep 2006 13:39:22 -0500

At 01:23 PM 9/7/2006 -0400, Andrew Newton wrote:
>Perhaps an Informational RFC on this specific topic is in order... one 
>that discusses the problem and explains the consensus... and one that we 
>can use to say "see RFC 5001".

I think this is a good idea.  This topic keep coming up over and over 
again.  Having an answer of "see RFC 5001" seems great as a complete answer 
to future inquiries of this

---

From: Andrew Newton <[email-masked]>
Date: Thu, 07 Sep 2006 15:50:16 -0400

> asking for a recursive zone transfer for DNS...

I'm ok with an OPTIONAL altitude to accompany both the point in the query 
and the result service boundary.  Apparently, it is quite common with 
Interstate junctions where the land beneath the overpass (the local road) is 
county/city jurisdiction but the actual overpass (40 ft above) is the 
jurisdiction of the state police.  So I've been told.

But allowing just any GML to appear in LoST seems to be a mistake.  The 
protocol is the point of interoperability.  So what if we did the following:

o Do not restrict the protocol or schema to any particular shape.
o Define a "basic GML profile" for LoST consisting of an X, Y, and optional 
Z for input and 2D polygon and optional Z for output.  This is a MUST implement.
o Create an error code to hand back to clients when a shape is not 
understood.  Also instruct servers to return the basic profile in this case.
o Require other shape usages to have a defined profile published as an RFC.

This way we have a basic profile and a way forward to use additional 
profiles without a flag day.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Sep 2006 17:41:06 -0400

> I'm ok with an OPTIONAL altitude to accompany both the point in the 
> query and the result service boundary.  Apparently, it is quite common 
> with Interstate junctions where the land beneath the overpass (the local 
> road) is county/city jurisdiction but the actual overpass (40 ft above) 
> is the jurisdiction of the state police.  So I've been told.

As far as I know, the altitude certainty, if any, in Phase II wireless 
would not not allow you to distinguish those. Plus, many overpasses only 
have a clearance of 12' or 15', so the difference is probably 
significantly below 40'. I very much doubt that any existing Phase II 
system can usefully distinguish those cases.

> o Define a "basic GML profile" for LoST consisting of an X, Y, and 
> optional Z for input and 2D polygon and optional Z for output.  This is 
> a MUST implement.

[Not sure what you mean by 'basic profile' here.]

> o Require other shape usages to have a defined profile published as an RFC.

That approach sounds reasonable.

> profiles without a flag day.

It might also be nice to be able to discover the shape capability of the 
server, without having to do stepwise downgrading or trial-and-error. I 
think simply naming each such shape profile and returning the list of 
tokens would be sufficient.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 07 Sep 2006 17:51:33 -0400

> tokens would be sufficient.

But there is no single server.  This is a series of servers: LoST resolvers, 
LoST forest guides, and LoST authoritative servers.  Each could have a 
different capability set.

In the end, what is important is the set of capabilities of a specific query 
path.  I was trying not formulate a set reduction algorithm at every LoST 
hop, and specifically I don't know how it helps a proxy acting as a LoST seeker.

I'm also not convinced that anybody will write any client code that will opt 
for anything other than the basic profile if the one they wish to use is 
rejected.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Sep 2006 17:55:16 -0400

> But there is no single server.  This is a series of servers: LoST 
> resolvers, LoST forest guides, and LoST authoritative servers.  Each 
> could have a different capability set.

Very good point.

> 
> In the end, what is important is the set of capabilities of a specific 
> query path.  I was trying not formulate a set reduction algorithm at 
> every LoST hop, and specifically I don't know how it helps a proxy 
> acting as a LoST seeker.
> 
> I'm also not convinced that anybody will write any client code that will 
> opt for anything other than the basic profile if the one they wish to 
> use is rejected.

I agree. Maybe some closed deployments will universally implement 
something beyond that.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Sep 2006 18:14:50 -0400

> a university with a local EMS responder occupying some number of floors of a

If I said it, consider it in the "fanciful" category :-)

> hard to compute (intersection area).

I'm not a GIS expert, but I took a quick look at the capabilities of 
PostGIS, one of the better open-source geo-capable databases out there.

http://postgis.refractions.net/docs/ch06.html describes the 
capabilities. I don't see anything that would make such a query easy or 
efficient, but I probably haven't looked hard enough.

Unless common geo-databases support this functionality, I would argue 
that this is unlikely to be practical and likely to be of extremely 
limited use. In almost all cases, taking the centroid of the shape will 
yield the same result. Particularly given that the probability of you 
being in various points of the wireless polygon is distinctly 
non-uniform (as you get to the edges, relatively few people will be 
there, even for uniform population density, since you'll likely be 
associated with another tower that's stronger there), going for some 
overlap percentage is completely pointless accuracy - it's numerically 
better, but meaningless.

> I don't want to force everyone to do this.  I want to allow it.

Like Andy suggested, if there's a concrete need, another profile can be 
written later, once we better understand real "customer" demand and have 
some operational experience. In particular, we need to consider the 
impact on a *distributed* system, not think of LoST as one big server 
that has every PSAP in one database.

> with only a country: some default PSAP.  Or an error (but then what does the

This isn't quite the same. At least with civic, you general have a 
hierarchy that is one-to-many. If a poor LoST resolver gets a polygon 
that spans two states, handled at the county level by different LoST 
servers, it now needs to make two queries, to both states, and then 
what? Should this query be routed to the national or state PSAP, just 
because my coverage region spans a state boundary? Let's just say that 
the police and fire departments in NY and NJ are not going to be happy, 
given that roughly 20 million people live within a few miles of that 
boundary.

The much better answer is to take the centroid of the coverage polygon 
and return one answer, in a county in one of the states. (The client 
should do that operation, as it is trivial and only the client might be 
able to do fancier versions, such as weighted centroids.)

I'm sure you can special-case any of these, but you're now talking about 
writing custom code for each LoST server, rather than a database lookup.

In this particular case, the custom code would need to be in the 
resolver, since it needs to make the decision about which state should 
be contacted. Once it forks the query, each state LoST server will just 
have to pretend that the query is wholly within its service area.

The more of these cases, the more testing, corner cases and surprises. 
Not exactly what one might want in a system critical to emergency response.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 18:49:46 -0500

Okay, I don't mind picking this up.

I agree with Brian, the whole purpose of the GeoShapes draft was to
specify what shapes would be acceptable. These shapes should form the
acceptable types for LoST.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 8 September 2006 3:54 AM
> To: 'Andrew Newton'; 'James M. Polk'
> Cc: [email-masked]
> Subject: RE: [Ecrit] Location information in emergency session
> initiation,need for time and accuracy?
> 
> > that
> > discusses the problem and explains the consensus... and one that we
can
> > use
> > > the target is within that ring.  This concept can be taken out to
a
> cell
> > It's good that you bring this up.  I'm beginning to think that we
need
> to
> > tightly define the GML used for LoST.  I don't know what a LoST
server
> is

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 18:44:35 -0500

> BTW - RFC3825 has resolution as part of its solution.  This creates a
GML
> tower's coverage area too (i.e. provide the polygon - regardless of
shape
> -

Absolutely NOT POSSIBLE!!

Conversion to and from the format specified by RFC-3825 can introduce
large errors and it is not suitable around the lines of meridian. Please
see PIDF-LO profile for a rationale of the mathematics.

If I have a 100 metre Ethernet cable attached I am not going to be at
the point specified by RFC-3825.
Care to try again?

RFC-3825 gives you a high confidence level, but its specification for
uncertainty as it pertains to location representation and accuracy is
not good. Until such time as the mechanism for specifying uncertainty is
improved I would not recommend RFC-3825 for use in emergency
applications.

Cheers
James

---

From: Andrew Newton <[email-masked]>
Date: Thu, 7 Sep 2006 21:06:41 -0400

> If I said it, consider it in the "fanciful" category :-)

I've got one...
A well placed WiFi AP in Washington, D.C.'s Dupont Circle could  
probably have a service area of 5 separate countries... given that  
each embassy is sovereign soil.  A cell tower or WiMAX AP could  
probably service 40 or 50 separate countries.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 7 Sep 2006 21:09:15 -0400

> acceptable types for LoST.

Can you please describe the LoST resolution algorithm for them?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Sep 2006 21:13:58 -0400

I'm sure the Indian Embassy in DC has the civic address

2107 Massachusetts Ave NW
Delhi-West
India

instead of the address reported by http://www.indianembassy.org/

2107 Massachusetts Avenue,  N.W.,
Washington D.C.
USA - 20008

The latter must be a mistake.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 20:16:54 -0500

Andy,

As I understand LoST, a LoST server has a database of shapes that define
service boundaries. You take the shape specified, and see which boundary
fits best. Anything other than a point may span more than one boundary.
The problem is though, anything that measures location in geodetic form
today measures it with a certain amount of uncertainty, this ranges from
quite small, several metres, to quite large kms. When you define a
shape, the host can reside anywhere with in it, and any point is equally
likely to contain the host regardless of how the shape is defined. So
picking an arbitrary point is a bad thing to do.

LoST will need to support these shapes as the end-point may obtain its
location from any number of sources, and it will have to do the best it
can do to map them, and yes, sometimes it will get it wrong.

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, 8 September 2006 11:09 AM
> To: Winterbottom, James
> Cc: Brian Rosen; James M. Polk; [email-masked]
> Subject: Re: [Ecrit] Location information in emergency session

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Sep 2006 20:16:55 -0500

At 06:44 PM 9/7/2006 -0500, Winterbottom, James wrote:

>large errors and it is not suitable around the lines of meridian.

"lines of meridian"?  errr, how many meridian lines are there?  You state 
this "fact" as if there are many - as if user will encounter them everywhere.

North America is not NEAR one...
Neither is your continent (Australia).
Europe has only one, and and that's only in Britain.
Asia doesn't have any meridian lines near them either...

Now, how much of the world is 3825 unsuitable for?

>Please

... well... that draft has math in it, as does the appendix of 3825

3825 doesn't need rationale, it has numbers. pure and simple numbers. Every 
one of the examples in that appendix is an example of a linear ring. Every 
one is 100% accurate, 100% of the time.

I'm sorry if you still do not understand the mechanism in 3825.

>the point specified by RFC-3825.

dude, 3825 can measure a point to 2.62mm by 3.11mm at the equator (and 
smaller rectangles above or below the equator)... I'd say that's within a 
100m cable ... *any* 100m cable *anywhere*. Care to tell me how it isn't?

Here's a test: take a 100m cable and lay it out anywhere on the planet, and 
I can get not just one, but hundreds of 3825 LIs within the length of that 
100m cable. Heck, you can probably point the cable straight up and I can 
still get a 3.11mm by 2.62mm position on the cable in 2D...

>not good.

James, James, James.... as I've said (Marc has too, and so has John S.) - 
"uncertainty" and "accuracy" are not precise enough to go into 3825, nor 
were they precise enough to go into 3693.  BTW - the Geopriv WG seemed to 
agree too

hehe

>Until such time as the mechanism for specifying uncertainty is

Fine, you go right ahead and don't recommend it.

;-)

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 20:31:56 -0500

You seem to have forgotten about the equator, It goes straight through
the middle of quite a number of countries.
Which map are you looking at for the longitudinal meridian?
I see it going through the middle of France, Spain and a big chunk of
Africa, I guess these countries don't count?

Nothing either you, Marc or JS has said has addressed the problems
described in the appendix of the PIDF-LO profile draft. Until you can
explain EXACLTY why these are not problems, and how you would perform
the same conversions using RFC-3825 to end up with results that do not
exhibit these errors.

As we have continually pointed out, where these errors will creep in for
other places is indeterminate, making it unsuitable. You could resolve
this issue easily by modifying to the way in which the precision bits
are interpreted to be inline with what JS proposed right back at the
start of this debate. Doing this would resolve the issues with regards
to format and error. Continuing to debate that accuracy, precision and
confidence are 100% absolutely correct all the time is ludicrous and
simply isn't worth the effort to continue.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, 8 September 2006 11:17 AM
> To: Winterbottom, James
> Cc: [email-masked]
> Subject: RE: [Ecrit] Location information in emergency
sessioninitiation,
> Here's a test: take a 100m cable and lay it out anywhere on the
planet,
> and

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Sep 2006 21:45:54 -0400

Unfortunately, due to its distributed nature, LoST service areas are  
*not* stored in a single database. Please see my NY/NJ example.

Plus, we're not picking an "arbitrary" point, but rather the centroid  
of the region of uncertainty.

Given that we don't know the precise probability distribution across  
the region of uncertainty, but know that it is not uniform, computing  
the likelihood of a "wrong" decision is probably fairly difficult.  
One would assume that, on average, the probability of being closer to  
the centroid is higher than towards the edge.

At best, we might be able to say that there is some larger  
probability that the wrong PSAP will be contacted, but the details  
depend greatly on the shape of the service areas. You'd likely only  
get a divergence of centroid vs. max-area if the "wrong" area juts  
out into the main area and the centroid happens to fall on this "tip"  
of that jutting-out service area. For the much more common case of a  
(piecewise) linear coverage boundary and a circular area of  
uncertainty, the two methods will provide exactly the same answer.

Thus, "errors" (quoted, since they are probabilistic) thus only occur:

- if the coverage region spans many PSAP jurisdictions (unlikely,  
since large coverage areas occur mostly in rural areas with low  
population density)

- if the centroid of the coverage area happens to fall into a highly  
"jagged" border line between two PSAPs

Somehow, given that routing in Phase II wireless is typically done on  
tower/face only, this doesn't strike me as a major problem, compared  
to the complexity incurred in fixing it.

Finally, if a client really cared about this, it can determine  
whether there is a problem by comparing the service area returned to  
its own area of uncertainty.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Thu, 7 Sep 2006 21:53:21 -0400

On Sep 7, 2006, at 9:16 PM, Winterbottom, James wrote:

> service boundaries.

LoST is not 'A' server.  It is a series of servers, some having  
varying roles.  This system is essentially a distributed database.  A  
resolution algorithm must specify much more than how a LoST  
authoritative server with a set of service boundaries is to resolve  
shapes.  It MUST also describe how the LoST resolvers are to go about  
asking the various authoritative servers how to find that  
information, and how the LoST resolvers cache the information when  
shapes overlap multiple service boundaries.  Once you move beyond a  
simple point, that becomes exceedingly complex.

> You take the shape specified, and see which boundary

What's to be done?  Return four PSAP URIs and ask the user to pick  
one?  And what is SIP proxy to do if it is acting as the LoST  
seeker?  Randomly pick one of the 4?

> can do to map them, and yes, sometimes it will get it wrong.

You are more than welcome to try and devise the LoST resolution  
algorithm for these shapes.  The proposal I made would allow you to  
do that.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 20:53:49 -0500

Just closing on the last point there Henning.
Most of the current Wireless Phase-II results in a 30% misrouting of
calls, which is what prompted the latest version of J-STD-036 which
introduces fast fix XY routing from the GMLC. I don't have figures for
the new deployments yet, but the expected misrouting figure is likely to
go right down.

Solutions here will not be based on centroid, but certainly this does
not have to be the case, and in our solution will likely not be.

We have a chance to improve over existing cellular systems here it would
be a pity if we didn't at least try.

Cheers
James

> Sent: Friday, 8 September 2006 11:46 AM
> To: Winterbottom, James
> Cc: Andrew Newton; [email-masked]
initiation,

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 7 Sep 2006 21:04:12 -0500

So the user gets an arcband because his location was determined from a
timing advance measurement.

In its base form, this is defined as lat, long, radius inner, radius
outer, offset angle and inclusion angle.

What are you expecting each thing in the communication path to do?

I understand that the resolver problem is complex, but a point
restriction is also a pretty serious shortcoming.

________________________________

Sent: Friday, 8 September 2006 11:53 AM

service boundaries. 

LoST is not 'A' server.  It is a series of servers, some having varying
roles.  This system is essentially a distributed database.  A resolution
algorithm must specify much more than how a LoST authoritative server
with a set of service boundaries is to resolve shapes.  It MUST also
describe how the LoST resolvers are to go about asking the various
authoritative servers how to find that information, and how the LoST
resolvers cache the information when shapes overlap multiple service
boundaries.  Once you move beyond a simple point, that becomes
exceedingly complex.

What's to be done?  Return four PSAP URIs and ask the user to pick one?
And what is SIP proxy to do if it is acting as the LoST seeker?
Randomly pick one of the 4?

You are more than welcome to try and devise the LoST resolution
algorithm for these shapes.  The proposal I made would allow you to do
that.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Sep 2006 22:07:45 -0400

Glad to hear that they'll introduce fast-fix routing. This presumably  
reduces the coverage region to much smaller areas, making the problem  
that much less likely, regardless of how the PSAP is picked.

I very much doubt that cell/face with max-area would have improved  
the routing accuracy above 70%, so this seems largely orthogonal.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Sep 2006 22:10:31 -0400

Easy: Either the client or the first server computes the centroid of  
the arcband.

If the area of the arcband is large (square miles), it will have  
large misroute probabilities, regardless of how the match is computed.

On Sep 7, 2006, at 10:04 PM, Winterbottom, James wrote:

> So the user gets an arcband because his location was determined  
> from a timing advance measurement.
>
> In its base form, this is defined as lat, long, radius inner,  
> radius outer, offset angle and inclusion angle.
>
>
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 7 Sep 2006 21:47:49 -0500

If we provide the additional information to the LoST server (I am not
talking about the system, just one specific node in that network), then
the server can make the centroid calculation.  This gives the LoST
server the option of taking uncertainty into consideration.

When you pick a point, there is a significant chance that you pick the
wrong point.  After all the centre of a circle that represents a
Cellular tower is probably the spot where you _wont_ find the target.

I showed a picture before, and without a picture, it's hard to
illustrate, so refer to my example on the geopriv list:

http://www1.ietf.org/mail-archive/web/geopriv/current/msg01552.html

If the device performs a conversion, this information is lost.  This
information could be used to reduce the chance of misroutes.

I'd prefer that the target provides the same information that it
receives from the LIS to the LoST network.  If the LoST server wants to
do a simple conversion to a point, then it assumes the responsibility
for the loss of information.

Cheers,
Martin

---

From: Andrew Newton <[email-masked]>
Date: Thu, 7 Sep 2006 22:57:44 -0400

> restriction is also a pretty serious shortcoming.

Regardless of the complexity, the resolver algorithm MUST be  
specified.  Without that specification, the restriction is much, much  
worse than a point restriction.  As I said before, you are more than  
welcome to work on this specification.  And my proposal will allow  
you to introduce that specification into the LoST system without a  
flag day, and without your having to have it finished when LoST is  
ratified.  It will even let you come back later on and revise your  
specification.  Do you find this objectionable?

-andy

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 8 Sep 2006 08:33:35 +0100

James M. Polk said:
> "lines of meridian"?  errr, how many meridian lines are there?

An infinite number.

A "line of meridian" is the set of points with the same longitude (a
semi-circle) *or* the union of two such sets that form a planar circle.

> You state 

They're unavoidable.

> Europe has only one, and and that's only in Britain.

If you're talking about the Prime Meridian, then this passes through
the land masses of three European countries, and I haven't attempted to
verify whether it crosses territorial claims of any others - it passes
between parts of at least two other countries.

> I'm sorry if you still do not understand the mechanism in 3825.

3825 does not explain in normative text:
- that the encoding is twos complement (sign and magnitude would probably
  be more sensible in this context);
- how to construct a rectangle that crosses the Prime Meridian or the
  equator;
- what is the meaning of a value that is, or includes cases, outside the
  +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it, here).

It's also a bad encoding because it requires boundaries to be aligned to
units of the same size as the boundary. For example, if I want to define an
area 2 degrees high, I have to use boundaries that are even numbers of
degrees; there's no way to encode a square, 2 degrees on a side, centred
on 52N 2W.

In fact, the *only* encoding I can do for an area centred on that point is
a rectangle 4 degrees east-west and 8 degrees north-south. For *any* point,
there's only one rectangle with that point at its centre that can be
encoded.

> 100m cable ... *any* 100m cable *anywhere*. Care to tell me how it isn't?

Completely missing the point. How do I specify "I'm within 100m of the
termination point of the cable"? There's no 3825 LI for this, and any LI
that includes all of this circle will include some random area around it.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: Andrew Newton <[email-masked]>
Date: Fri, 8 Sep 2006 07:27:36 -0400

> server the option of taking uncertainty into consideration.

Ok.  How do I know which server to ask?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 8 Sep 2006 08:13:21 -0400

I am not an expert here.  James may have to correct me, but I believe you
use "best fit", which I believe is max area of overlap.

With points and polygons, you find the polygon which contains the point.
With polygons (or other area figures like circles) and polygons, you
intersect the location polygons (areas) with each candidate service
boundaries and choose the one that has the largest intersection area.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 07:17:53 -0500

That is what I had in mind.

> Sent: Friday, 8 September 2006 10:13 PM
> To: 'Andrew Newton'; Thomson, Martin
> Cc: [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Fri, 8 Sep 2006 09:17:48 -0400

> boundaries and choose the one that has the largest intersection area.

I think I understand your point.  A point in polygon algorithm is  
just a type of best-fit.  Regardless, I still think that is far more  
complex than we need out of the gate.  Of course, I think it would be  
short-sighted for us not to have a means to provide for better than  
points in polygons.  That is why I have proposed a means for having  
profiles and the necessary protocol mechanics to deal with them.   
Since I have seen no objection to this, I can only assume that nobody  
minds if we specify it.

Regarding best-fit for shapes upon shapes, I'm no expert either.  And  
I expect many of the implementers will be more versed in marshalling  
XML across the wire and managing connection pools, etc... than in  
these geometry skills.  So, can you provide the algorithms for "best  
fit" upon which each shape intersects every other shape?  I assume  
you do not mean an indefinite list of shapes but are strictly  
limiting this to the shapes in Martin's document.  Otherwise, I'd  
like to see an explanation of how the data store and lookup mechanism  
is to work.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 08 Sep 2006 10:36:50 -0400

I think there are three somewhat separable problems:

(1) What location information types are permissible in LoST queries and 
as service areas.

(2) How matches are computed within each server. Since it is likely that 
many LoST implementations will use standard GIS-enabled databases, 
matches that work with spatial SQL are highly desirable, as implementors 
may otherwise have to develop either custom databases or sequentially 
scan a potentially large number of shapes. Anything that requires custom 
per-server programming is unacceptable.

We know that such databases, such as PostGIS, can handle 
"point-in-polygon" and "boolean intersect", at least for some shapes. So 
far, it remains unclear whether they support more complicated geometric 
operations, and at what computational cost. Requiring O(N^2) algorithms 
is clearly a really bad idea; point-in-polygon is trivially O(N) or 
O(log N) and can be sped up by indexing.

http://www.acm.org/pubs/tog/editors/erich/ptinpoly/ provides some 
benchmarks on ancient hardware for different algorithms. If you'd want 
really fast, just run the algorithm on the GPU - it's designed to do 
this type of stuff hundreds of thousands of times a second...

For each shape in (1), we need to at least define how to compute the 
centroid for that shape, to allow point-in-polygon matches. Assuming 
that implementors can figure this out for shapes such as arc bands is 
unrealistic.

(3) Most importantly, some non-centroid algorithms would require 
"forking", i.e., a server for a particular area would have to issue 
several queries, gather the results and compute the best fit. This 
forking could be recursive and introduces significant system complexity 
and failure modes.

Henning

Andrew Newton wrote:
> I think I understand your point.  A point in polygon algorithm is just a 
> type of best-fit.  Regardless, I still think that is far more complex 
> than we need out of the gate.  Of course, I think it would be 
> profiles and the necessary protocol mechanics to deal with them.  Since 
> I have seen no objection to this, I can only assume that nobody minds if 
> we specify it.
> 
> Regarding best-fit for shapes upon shapes, I'm no expert either.  And I 
> expect many of the implementers will be more versed in marshalling XML 
> across the wire and managing connection pools, etc... than in these 
> geometry skills.  So, can you provide the algorithms for "best fit" upon 
> which each shape intersects every other shape?  I assume you do not mean 
> an indefinite list of shapes but are strictly limiting this to the 
> shapes in Martin's document.  Otherwise, I'd like to see an explanation 
> of how the data store and lookup mechanism is to work.
> 
> -andy
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 14:10:19 -0400

Could someone please identify any/all application(s) where geo coordinates
are used to describe the location of a fixed (e.g. non-mobile) entity where
uncertainty/polygons are expressed?  I've reviewed many aviation/marine
charts/data (very pervasive use of geo coordinates) that express geo
locations for fixed objects and I've yet to find any expressed with
uncertainty.  (I'm 70% confident you'll find a runway at x,y,z)

RFC3825:

- is NOT intended to advise a mobile client of it's location (as suggested
in the text, it could possibly convey the location of the access point)
- is NOT a mechanism for expressing polygons
- is capable of conveying a 3 dimensional geo point from one entity to
another via dhcp
- is capable of expressing the resolution of the shown value
- is capable of allowing the creator of the object to express resolution
values other than what is actually known
- is an efficient mechanism for passing geo point location values via dhcp

...............snip....................

>   be more sensible in this context);

As seen in the quote below, it certainly specifies twos complement.  In the
1960s problems with this representation were identified and resolved with
twos complement representation.
http://en.wikipedia.org/wiki/Signed_number_representations

"Within the LCI described here, Latitude and Longitude are represented in
fixed-point 2s-complement binary degrees, for the economy of a smaller
option size compared to a string encoding of digits in [7].  The integer
parts of these fields are 9 bits long to accommodate +/- 180 degrees.  The
fractional part is 25 bits long, better than the precision of 7 decimal
digits.  The length of each field is 40 bits, 34 of which is the sum of the
integer (9) and fractional (25) bits, plus 6 bits of resolution."

> - how to construct a rectangle that crosses the Prime Meridian or the

RFC 3825 is not about representing arbitrary rectangles, but about
representing a geographic location, with explicit indication of the
resolution of the point.

>   +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it, 

One could extrapolate many meanings from values expressed that are outside
the SHOULD of the RFC.  One of those meanings may be that the value
expressed is an error.  Or a value outside the specified range could be an
alias (wrapping the globe) for a value within the specified ranges.  The
"SHOULD" allows those who understand the complications to violate this
specification, but warns of unintended consequences. 

> 
> It's also a bad encoding because it requires boundaries to be aligned 
> to units of the same size as the boundary. For example, if I want to 
> define an area 2 degrees high, I have to use boundaries that are even 
> numbers of degrees; there's no way to encode a square, 2 degrees on a 
> side, centred on 52N 2W.
> 
> In fact, the *only* encoding I can do for an area centred on that 
> point is a rectangle 4 degrees east-west and 8 degrees north-south. 
> For *any* point, there's only one rectangle with that point at its 
> centre that can be encoded.

Since there is no arbitrary rectangle specified in RFC 3825, it does not
require anything about boundaries of any rectangle.

..................snip............................

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 16:47:05 -0500

Marc,

I would like you and James to get your arguments in synch and come back
with a cohesive, uncontradictory response to the concerns that are being
raised here.

You say " is NOT a mechanism for expressing polygons" and have said
before that you see it as a mechanisms for expressing single points
only.

James said " RFC3825 has resolution as part of its solution.  This
creates a GML defined Linear Ring.."

These are in direct conflict.
The moment you use the resolution bits to describe a linear ring, you
are specifying a polygon, which by its very definition defines the area
of uncertainty for the host. The coding mechanism described in RFC-3825
for doing this introduces the problems that we have described.

So, either it is a point, in which case the resolution for the most part
should be ignored and a Biz to RFC-3825 is required to say this. Or, it
is an area which is described by the resolution bits, in which case you
need to find a way to eliminate the problems described or accept that it
should not be used in emergency applications.

I am only interested in location representation, and so far I see
conflict amongst the authors of that RFC with regards to what RFC-3825
represents and I see confusion over how the authors are interpreting the
terms uncertainty and confidence with regards to their usage in the
expression to areas.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Saturday, 9 September 2006 4:10 AM
> To: 'Clive D.W. Feather'; Winterbottom, James
> Cc: [email-masked]; [email-masked]
> sessioninitiation,need for time and accuracy?
> 
> As seen in the quote below, it certainly specifies twos complement.
In
> the
> digits.  The length of each field is 40 bits, 34 of which is the sum
of
> the

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 18:02:16 -0400

James,

> 
> So, either it is a point, in which case the resolution for 
> the most part should be ignored and a Biz to RFC-3825 is 
> required to say this. Or, it is an area which is described by 
> the resolution bits, in which case you need to find a way to 
> eliminate the problems described or accept that it should not 
> be used in emergency applications.

Please explain why emergency applications are different from other
applications that describe fixed locations using the geo coordinate system.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 17:11:05 -0500

Marc,

Perhaps the statement should have been, is not suitable for any
application that require a deterministic degree of accuracy, something
to that effect.
I am quite sure that in some circumstances that the encoding scheme is
fine, but I wouldn't want to be my life on it in an emergency, would
you?

James

> Sent: Saturday, 9 September 2006 8:02 AM
> To: Winterbottom, James

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 18:29:12 -0400

> 
> Marc,
> 
> Perhaps the statement should have been, is not suitable for 
> any application that require a deterministic degree of 
> accuracy, something to that effect.
> I am quite sure that in some circumstances that the encoding 
> scheme is fine, but I wouldn't want to be my life on it in an 
> emergency, would you?

I suggest emergency responders would have no problem finding locations
described by RFC3825, it's the same data expressions used by aviation and
marine everyday.  So, unless you travel exclusively by rail, you've probably
already placed you life in the hands of such data representation, I know I
have.

-Marc-

---

From: John Schnizlein <[email-masked]>
Date: Fri, 8 Sep 2006 18:36:10 -0400

Are you saying that the 5 embassies would each actually have their own 
PSAPs?  Or is this "use case" in the "fanciful" category?

But Brian's point was really about separate floors rather than 
autonomous regions in close lateral proximity.  Is there a non-fanciful 
real-world use case that implies that the routing of an emergency call 
should depend on the floor where the call originates?

As a case that might combine these fancies, it happens that the Swedish 
Embassy leases suites on other floors of its building on M Street.  Do 
you know that emergency calls from these floors are routed differently 
than emergency calls from the floors the Swedish diplomats occupy?

John

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 17:52:30 -0500

It is interesting that you point this out and I am certainly no expert
in aviation and marine location systems. I will however point out that
from what I have seen that searches at sea and for downed aircraft often
span many thousands of square kilometres, I scarcely think that this
would be acceptable in a domestic wired or wireless phone emergency
situation.

I would also point out that if you have used the same encoding as is
used in those industries it behoves you to have put them in the
references section of the RFC, and to have indicated that the encoding
scheme came from the there in the text somewhere, I certainly couldn't
find any.

Now back to my initial series of questions:

Point or Polygon, single answer please.
How do you intend to address the concern regarding errors.

Cheers
James

> Sent: Saturday, 9 September 2006 8:29 AM
> To: Winterbottom, James

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 8 Sep 2006 18:14:00 -0500

> Ok.  How do I know which server to ask?

I think that you missed my point; I am talking about any individual server in the entire system.

Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 8 Sep 2006 18:27:09 -0500

Can you see any problem with specifying a fast and efficient method for calculating a centroid, but also permitting the use of more sophisticated methods?  I say this because every time the performance argument is raised, up goes a little red flag.  (Yes, yes, it isn't all about performance).

For 1: I would say that the limited set of shapes in geo-shape should be permitted.

For 3: I can see that forking would be a bad idea for a number of reasons, I don't think that it should be encouraged.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sat 9/9/2006 12:36 AM
To: Andrew Newton
Cc: Brian Rosen; [email-masked]; Thomson, Martin
Subject: Re: [Ecrit] Location information in emergency session	initiation, need for time and accuracy?

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 19:41:55 -0400

James,

We are obviously talking past each other.  I used the aviation and marine
industries as examples of users of geo coordinates for their respective
navigation applications.  I used that analogy because both those
applications commonly refer to fixed locations (e.g. airport runways, marine
buoys/markers), the same non-mobile type entities served by RFC3825 (the
commonality being 'non-mobile, not the application).  I can't testify
whether these application implementations internally represent data in
binary, octal, decimal, etc.  But I can attest that these applications DO
NOT express any kind of uncertainty association in addition to the location
representations.  My experience with these applications have been with
variable length fields, hence a separate resolution parameter has not been
included.

Resolution, whether expressed in binary, octal, decimal, etc. cannot
represent an arbitrary area/shape.  Hence, RFC3825 cannot express an
arbitrary area/shape as it only includes resolution.

Would you please expand your question concerning errors?  What errors?

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Friday, September 08, 2006 6:53 PM
> To: Marc Linsner
> It is interesting that you point this out and I am certainly 
> no expert in aviation and marine location systems. I will 
> however point out that from what I have seen that searches at 
> sea and for downed aircraft often span many thousands of 
> square kilometres, I scarcely think that this would be 
> acceptable in a domestic wired or wireless phone emergency situation.
> 
> I would also point out that if you have used the same 
> encoding as is used in those industries it behoves you to 
> have put them in the references section of the RFC, and to 
> have indicated that the encoding scheme came from the there 
> in the text somewhere, I certainly couldn't find any.
> 
> > > application that require a deterministic degree of accuracy, 
> > > something to that effect.
> > > I am quite sure that in some circumstances that the 
> encoding scheme 
> > > is fine, but I wouldn't want to be my life on it in an emergency, 
> > > would you?
> > 
> > described by RFC3825, it's the same data expressions used 
> by aviation
> and
> > marine everyday.  So, unless you travel exclusively by rail, you've 
> > probably already placed you life in the hands of such data 
> > representation, I
> know I
> > have.
> > 
> > -Marc-
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 8 Sep 2006 19:53:05 -0400

I was one for the "fanciful" category.

-andy

On Sep 8, 2006, at 6:36 PM, John Schnizlein wrote:

> Are you saying that the 5 embassies would each actually have their  
> own PSAPs?  Or is this "use case" in the "fanciful" category?
>
> autonomous regions in close lateral proximity.  Is there a non- 
> fanciful real-world use case that implies that the routing of an  
> emergency call should depend on the floor where the call originates?
>
> As a case that might combine these fancies, it happens that the  
> Swedish Embassy leases suites on other floors of its building on M  
> Street.  Do you know that emergency calls from these floors are  
> routed differently than emergency calls from the floors the Swedish  
> diplomats occupy?
>
> John
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 20:08:04 -0400

fwiw.....NENA submitted a requirement for routing on the 'z' dimension.  The
use case was the top 55 floors of the Sears tower could get routed to a
different PSAP than the bottom 55 floors, reasonable since there are over
10,000 occupants of that building at certain times.  This requirement is not
'fanciful' as it is achieveble with the current PSTN 911 architecture.

I suggest we accomodate such in the 'newer, better' IP system, regression of
features doesn't bode well in marketing the Internet.

-Marc-

> Sent: Friday, September 08, 2006 7:53 PM
> To: John Schnizlein
> Cc: [email-masked]
> Subject: Re: [Ecrit] Location information in emergency 
> session initiation,need for time and accuracy?
> 
> > Street.  Do you know that emergency calls from these floors 
> are routed 
> > differently than emergency calls from the floors the 
> Swedish diplomats 
> > occupy?
> >
> > John
> >
> >>>> I thought I heard you giving use cases.  As I recall, it was 
> >>>> something like a university with a local EMS responder occupying 
> >>>> some number of floors of a building.
> >>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 8 Sep 2006 20:24:35 -0400

On Sep 8, 2006, at 7:27 PM, Thomson, Martin wrote:

> Can you see any problem with specifying a fast and efficient method  
> for calculating a centroid, but also permitting the use of more  
> sophisticated methods?  I say this because every time the  
> performance argument is raised, up goes a little red flag.  (Yes,  
> yes, it isn't all about performance).

Yes, there are problems. If a server A uses max-area and passes a  
request to the centroid-using server B that serves sub-areas, you can  
get into trouble. Let's say that the max-area points to NY, but the  
centroid to NJ. The first server passes the request to the NY server,  
which uses centroids and now discovers that the service request is  
nowhere in NY, and returns an error. Bad news.

Obviously, if the two metrics always agreed on the result, there  
wouldn't be a problem, but then there wouldn't be a reason to bother  
with the second algorithm.

So far, I have not heard a convincing argument that max-area offers  
any realistic advantages for query areas that are usefully accurate  
for routing. You have convinced me that cell/face isn't good enough  
for routing, but that can't be fixed by using sophisticated max-area  
matching algorithms. Maybe you know the likely quick-fix accuracy;  
from http://www.sirf.com/Downloads/Collateral/GSC3(f)_6.20.05.pdf, it  
sounds like you can get 10 m within 1s, assisted, but that's  
obviously marketing literature, not measurement.

> For 1: I would say that the limited set of shapes in geo-shape  

I would agree as long as somebody can convincingly point to real  
algorithms for centroid computation. No hand-waving allowed.

>
> For 3: I can see that forking would be a bad idea for a number of  
> reasons, I don't think that it should be encouraged.
>

Unfortunately, once you allow non-point matching, it's hard to avoid  
forking in a distributed system. Simple example, again using NY and  
NJ: while the state-discriminating server can determine whether a  
larger part of the query area is in NY and NJ, that says nothing  
about the county or city level. The query footprint could match all  
of a small town in NJ, while matching half a dozen towns in NY. The  
upstream server can't know that, so it has to pass the request to  
both states. You can construct arbitrarily complex scenarios along  
these lines. They will be relatively rare, but that just makes them  
harder to test for.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 20:09:41 -0500

Marc,

In all the examples used in RFC-3825 in the appendix, the way resolution
is used is to express a range in the latitude, longitude and altitude.
This expresses an area or volume, there is no other way to interpret
this. I am past believing that you can't see this.

I am not saying having a resolution parameter is not useful, just the
way that RFC-3825 stipulates it be interpreted.

As for errors please read PIDF-LO profile, it is very clear there.

Cheers
James

> Sent: Saturday, 9 September 2006 9:42 AM
> To: Winterbottom, James

---

From: John Schnizlein <[email-masked]>
Date: Sat, 9 Sep 2006 10:50:46 -0400

> this. I am past believing that you can't see this.

These illustrations are in an appendix to indicate that they are not 
normative.  The point of the appendix is to show what size regions 
different resolutions imply, including deliberately partially hiding 
location by lowering resolution.  This does not change the fact that 
the resolution is SPECIFIED as "number of valid bits in the fixed-point 
value".  As we have explained before, this represents the normal 
scientific/engineering concept of significant figures.

> way that RFC-3825 stipulates it be interpreted.

The way RFC 3825 specifies resolution is just what is necessary to 
implement the principle of significant figures when using a 
fixed-length binary number rather than a variable number (limited by 
the measurement precision) of decimal digits.

> As for errors please read PIDF-LO profile, it is very clear there.

No, it is not.  As explained in the dialog on the GeoPriv list some 
time ago, the errors are in your interpretation of the illustration in 
the appendix of RFC 3825.  RFC 3825 does not specify arbitrary 
geographic polygons, although you seem to insist it should.  Your 
invention of longest matching substrings of boundaries leads to the 
errors you report.  Please stop attributing your erroneous 
interpretation to the different purpose of RFC 3825.

John

>> From: Marc Linsner
>>
>> We are obviously talking past each other.  I used the aviation and
>> marine industries as examples of users of geo coordinates for their
>> respective navigation applications.  I used that analogy because both
>> those applications commonly refer to fixed locations (e.g. airport 
>> runways,
>> marine buoys/markers), the same non-mobile type entities served by 
>> RFC3825
>> (the commonality being 'non-mobile, not the application).  I can't 
>> testify
>> binary, octal, decimal, etc.  But I can attest that these applications
>> DO NOT express any kind of uncertainty association in addition to the
>>
>> location representations.  My experience with these applications have
>> been with variable length fields, hence a separate resolution 
>> parameter
>> has not been included.
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 9 Sep 2006 17:11:07 -0500

John,

Please!
Normal scientific measurements will say +- half the smallest unit. This
will place a point in the middle somewhere, and you yourself at the very
start of this debate came back with a proposal saying that. 

The fact of the matter is that you are starting in the normative section
of the draft that the resolutions parameters place you with in an area.
If this is what is meant, then I am sorry to say that this but the
PIDF-LO draft is correct and you are plain wrong!

James Polk has stated more than once now that the shape defined in
RFC-3825 is a linear ring polygon. If this is the case then the
calculation in PIDF-LO profile also stand.

Quite frankly what is it that RFC-3825 represents. This part of previous
question you have tactfully ignored.

So I am going to ask you. Point, or area?
If Point, then a clarification draft stipulating this is required.
If an area, then please provide a detailed explanation of how would
re-describe the examples in PIDF-LO profile with references to the
sections RFC-3825 that eliminate the inherent errors.

I am tired of you saying that this is wrong, when it clearly follows
your specification, and you do not provide through the same example
where it is wrong, or provide a reasonable alternative.

BR
James

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Sunday, 10 September 2006 12:51 AM
> To: Winterbottom, James
> Cc: [email-masked]; Marc Linsner; [email-masked]
sessioninitiation,

---

From: John Schnizlein <[email-masked]>
Date: Sat, 9 Sep 2006 20:49:09 -0400

What part of "geographic location of the client" is unclear to you?

It is beyond comprehension how this could be interpreted as a area 
rather than a point, with the resolution of the measurement of that 
point explicitly included in the location information.

Why is this old argument being rehashed in the ecrit WG when if finally 
seemed to die (mercifully) in GeoPriv?

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 9 Sep 2006 20:02:18 -0500

So you are saying that the examples in the appendix of RFC-3825 are
wrong, and that RFC-3825 cannot and never will describe an area?

It didn't die in Geopriv, I was waiting for you to actual come back with
an explanation, what you did was write back an email that was totally
irrelevant to the discussion. So I am still waiting!

> Sent: Sunday, 10 September 2006 10:49 AM
> To: Winterbottom, James
sessioninitiation,

---

From: Byron Smith <[email-masked]>
Date: Sat, 09 Sep 2006 23:21:56 -0400

James,

Your question:  "Point or Area?" as well as your other comments the past 
couple of days about RFC-3825 seem to me to revel a real confusion on 
your part about the purpose and use of this standard.

RFC-3825 is a *specification* of a standard way to *specify and code* 
geographic location information over a computer network.

RFC-3825 permits the communication of x,y, and optionally z, coordinates 
with an accuracy of a few centimeters or better, *anywhere* on the face 
of the earth, including the equator, poles, or the meridians.  RFC-3825 
will work at the equator, in France, at the South pole, in the USA or 
Australia, or anywhere at sea. This is certainly *more than adequate* 
for any emergency purpose within the scope of these discussions. 

In this regard, x, y, and z are a *point.*

Now, in the real world, anything that I specify will include some 
uncertainty or error. 

If I buy a beer, the container says:  12 fluid oz, 335 ml. 

But does the can contain *exactly* 335 ml?  Maybe it only had 334.5 ml.  
Or 335.82 ml.   Or 336.05723 ml.  And when I drink it, did I drink 
exactly what was in the can?  What about the residual drops left behind?

The beer can would tell me more if it said:  335 ml +/- 5 ml.   That 
would give me an idea if how accurately the container was filled.  If I 
even care after I drink the beer!  <smile>

The beauty of RFC-3825 is that it not only lets me specify a point on 
the surface of the earth, but that it also allows me specify how 
precisely I think that I know where that point is located.  Is the point 
accurate to within a few centimeters?  A few meters? A few kilometers?  
The RFC lets me communicate this information.

Now, some folks have been saying that this is an "area."  That might be 
one way to think about it and describe it, but I suspect this this is a 
poor description.  What is really being conveyed is some sort of 
probability distribution.

Think of it this way:  I want to specify a point on string.   I might 
say:  The point of interest is 1.5 meters from the left end of the 
string.  

This is clearly a point, but how accurately did I specify it?  Do I mean 
the point is really at 1.5003 meters but you can't measure it that 
closely anyway, so 1.5 is good enough?  Do I mean any spot on the string 
between 1.45 and 1.55 meters?  Or did I mean exactly 1.5000000 meters?   
The original statement:  "The point of interest is 1.5 meters from the 
left end of the string" doesn't speak to the issue of accuracy.

But if I said:  "The point of interest is 1.5 meters, +/- 0.05 meters"  
then you have a much better idea of where the point of interest really 
is on the string.

Now, your question:  Would you describe that point at 1.5 meters, +/- 
0.05 meters, as a "Point" or as a "Line?"  Quick, James, tell me...

*****

It is possible to think of 1.5 meters, +/- 0.05 meters, as a line.   But 
in reality, it is more of a  probability distribution. 

If I wished to specify a line (on the string) I would probably say 
something like:  The line starting at 1.4 meters and ending a 1.7 meters 
from the left end of the string.

And, as before, this specifies a line, but tells you nothing about how 
accurately I want the line to marked out on the string.

In order to specify a line with accuracy, I need to say something like 
this:  The line from 1.4 meters, +/- 0.03 meters, to 1.7 meters, +/- 
0.04 meters.

****

This is the problem with thinking of the accuracy specification in 
RFC-3825 as an "area."  That causes the confusion of "Point or Area?" 
and a whole lot of other confusions.

RFC-3825 is a great way to specify or communicate a point on the surface 
of the earth.  It also allows you to specify an accuracy associated with 
that communication.

But if you want to specify an area, you need to send several points, 
that is, several RFC-3825 messages.  Then, you can also communicate the 
accuracy of the *area* that you are communicating.

****

Byron

Winterbottom, James wrote:
>> Why is this old argument being rehashed in the ecrit WG when if
>>     
> finally
>

---

From: Andrew Newton <[email-masked]>
Date: Sat, 9 Sep 2006 23:28:38 -0400

At the risk of ending the cordial and praiseworthy correspondence of  
this thread, I would like to interject that I am fairly confused.   
Certainly (pun intended) I should have given much more attention to  
my math and statistics studies when I was younger.

First, my initial confusion about this dealt with the terminology  
being used, which is somewhat a point of contention here.  For the  
life of me, I could not understand why anybody would care to  
communicate their "uncertainty" regarding location information nor  
could I understand why a PSAP would want to know it.  "The building I  
am in is on fire, but I'm only 50% certain that it is my house.  I  
could be at work as well."  That just doesn't make sense.  So I can  
only gather that the word is being used in the context of statistical  
probability about a specific point within a shape.  Is this correct?   
And can somebody point to an actual definition of the word?  Is it  
the same as confidence as is used in probability?

At looking at RFC 3825, I think there may be an issue with  
terminology but I believe the concept is appropriate.  3825 uses the  
term "resolution".  I would have thought resolution would refer to  
the range of numbers allowed in the protocol fields.  Instead, it is  
being used to describe the resolution of the measurement.  That is  
fine.  And the take away from it is that a point in 3 dimensions is  
being expressed.

Now, if the receiver of this information is capable of understanding  
a higher "resolution", then one could start asking questions about  
the probability of where a point (at the receivers highest  
resolution) resides inside the shape that can be taken from the  
senders lower resolution point.  I guess that might be useful if  
first responders are sent to the location given by the higher  
resolution point, find nothing, and are then advised to search a  
perimeter of a specific size.

It turns out that the other document in this discussion does talk  
about this.  From Section 6 of draft-ietf-geopriv-pdif-lo-profile:

    Generally these locations are expressed as a point
    (either in two or three dimensions) and an area or volume of
    uncertainty around the point.  In theory, the area or volume
    represents a coverage in which the user has a relatively high
    probability of being found, and the point is a convenient means of
    defining the centroid for the area or volume.  In practice, most
    systems use the point as an absolute value and ignore the
    uncertainty.

Interchange "uncertainty" and "resolution" and these documents are  
saying the same thing.  Which term is correct?  At present, I'm not  
convinced either is.

All this leaves me with two very big questions.  Since 3825 is  
describing a point in 3 dimensions, why does pidf-lo-profile talk  
about 3825 LCI as being a rectangle in Appendix A?  And if 3825 is  
describing a point, how can its equivalent in GML be a linear ring?   
I would think it would be a GML point (or Position in GML speak).

-andy

---

From: Byron Smith <[email-masked]>
Date: Sun, 10 Sep 2006 00:56:50 -0400

Andrew Newton wrote:
> Certainly (pun intended) I should have given much more attention to my 
> math and statistics studies when I was younger.
>
> could be at work as well."  That just doesn't make sense.  
In the case of a house, the position of the house should have been 
determined accurately enough so that the PSAP can plot the location on a 
map and dispatch to the correct civil address. And the PSAP wouldn't 
care about any "uncertainty."

However, the position determining systems presently used by some 
wireless carriers / commercial mobile radio service (CRMS) providers 
vary considerably in their ability to render an accurate fix of the 
caller's location.  This is especially true of "network-based" angle / 
time of arrival systems.  The distance of the caller from the tower, the 
presence of objects (like large buildings) that reflect the radio 
signal, and the geometry of the location between towers in triangulation 
systems, can cause the accuracy of the fix to vary greatly. 

In these cases, it may be very helpful to the PSAP to have an estimate 
of the uncertainty of the fix.  If they dispatch to the caller's 
reported location and cannot find the caller, then the uncertainty may 
help them decide if they should search +/- 1000 feet, +/- two miles, 
etc. from the fix. So it may help them bound the search area.
> So I can only gather that the word is being used in the context of 
> statistical probability about a specific point within a shape.  Is 
> this correct?  And can somebody point to an actual definition of the 
> word?  Is it the same as confidence as is used in probability?
When an uncertainty is reported, it means there is a certain probability 
that the actual value is within the expressed interval.  The actual 
probability may be explicitly expressed:  n +/-e  with 67 % probability, 
or it may be implied by convention (typically 95%) or as a "known" 
characteristic of the system.

For example, FCC Phase II requirements for handset-based wireless 
location systems is that the reported position is accurate +/- 50 meters 
67% of the time, +/- 150 meters 95% of the time.  In such cases, only 
the lat/long need be reported. 

For those 5% of the calls that are outside of the 150 meter requirement: 
"location attempts must be made and a location estimate for each call 
must be provided to the appropriate PSAP."  (Title 47, Part 20, Sec 18 h 
(3).)

How the system would determine if the call falls into the 5% case is not 
clear.  Most systems report an "uncertainty" with every call, even 
though (in principle) it is not required 95% of the time, assuming the 
system meets the FCC requirements.
>
> At looking at RFC 3825, I think there may be an issue with terminology 
> but I believe the concept is appropriate.  3825 uses the term 
> "resolution".  I would have thought resolution would refer to the 
> range of numbers allowed in the protocol fields.  Instead, it is being 
> used to describe the resolution of the measurement.  That is fine.  
> And the take away from it is that a point in 3 dimensions is being 
> expressed.
Correct. 

The "significant digits" in the protocol fields may reflect the 
resolution of the measurement or of the report, whichever is lower.

To the receiver these are essentially equivalent views.  For example, if 
I can measure some value as xx.xx +/- 0.005, but report:  45.343612, 
everything after 45.34 is just "noise."  The sender should not report 
more than 4 significant digits, since anything more is meaningless, or, 
the receiver should ignore everything after the 45.34, if it "knows" the 
resolution is 4 significant digits.

Conversely if I measure 45.343612, but report a resolution of 4 
significant digits, the receiver must regard the measurement as no 
better than 45.34 +/- 0.005.
>
> Now, if the receiver of this information is capable of understanding a 
> higher "resolution", then one could start asking questions about the 
> probability of where a point (at the receivers highest resolution) 
> resides inside the shape that can be taken from the senders lower 
> resolution point.  I guess that might be useful if first responders 
> are sent to the location given by the higher resolution point, find 
> nothing, and are then advised to search a perimeter of a specific size.
Actually, the receiver should not assume the higher resolution initially.
> saying the same thing.  Which term is correct?  At present, I'm not 
Uncertainty is usually expressed as an "interval", e.g. +/- e.  
Resolution is usually expressed as "number of significant digits," e.g. 
3 1/2 digits.  RFC-3825 properly describes its expression of accuracy as 
"resolution," because it is telling you how many digits in the lat/long 
can be "counted."  On the other hand, most CMRS systems report 
"uncertainty" to the PSAP. 

It is fairly straightforward to convert between these two notations.  So 
these documents really are saying the same thing.
> about 3825 LCI as being a rectangle in Appendix A?
The terminology in the Appendix should probably be improved.  It isn't 
really a geometric object, it is a (derived) uncertainty range or interval
> And if 3825 is describing a point, how can its equivalent in GML be a 
> linear ring?  I would think it would be a GML point (or Position in 
> GML speak).
>
> -andy
>
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 10 Sep 2006 03:31:26 -0500

Byron,

This debate began at the GeoPriv interim meeting in May of last year.
I indicated that the DHCP representation was not a solution that would
accommodate all location representation because it only represented a
point. This argument was subsequently refuted very intensely by James
Polk that insisted that the encoding in RFC-3825 represented a rectangle
or prism.

We have subsequently shown that the encoding scheme is not suitable for
representing this is a wide degree of circumstances. I think it
perfectly acceptable for point representation. The problem with RFC-3825
is that nearly all the examples in the appendix, which are the things
that most implementers will follow, are misleading in this
interpretation at best as they all describe areas, and not points.

For RFC-3825 to be acceptable for emergency services it should be
restricted to representing what it can adequately represent and not be
used to represent location that it is quite clearly not fit for, i.e
anything that is not a simple point. The RFC on this point is far from
clear, and I am suggesting that the authors and supporters of this
specification write a clarifying proposal describing its useability and
applicability to emergency applications.

Regards
James.

> From: Byron Smith [mailto:[email-masked]]
> Sent: Sunday, 10 September 2006 1:22 PM
> Cc: [email-masked]
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 10 Sep 2006 10:00:45 -0400

This is getting more helpful, rather than just making assertions.

Without precise, accurate, and agreed-upon recognized terminology,  
we're not going to get very far in this. See

http://en.wikipedia.org/wiki/Accuracy

for one accessible treatment that seems reasonable.

To make matters worse, the probability region is often of constant  
size, even though the PSAP doesn't really care as to whether  
localization technique X has a 95% uncertainty region of 100 m when  
averaged across the United States, but rather what the likely region  
is for the caller in a very specific place. For the reasons  
mentioned, for TOA and similar techniques, errors do not have the  
same distribution everywhere. I'm not a GPS expert, but I believe  
it's a bit more uniform for GPS, but with some time-of-day  
dependencies due to ionization differences in the atmosphere.

In any specific place, you are likely to have both systematic (non- 
zero-mean) and random (zero-mean) errors, i.e., the most likely  
location may not be in the middle of the uncertainty region for most  
places. Indeed, in a specific place, the target may *always* be  
outside the region described.

Thus, without a lot of additional qualifications, the implied  
preciseness of a geometric region of whatever shape may well be more  
comforting than real.

I have to admit that I find the point vs. area discussion more in the  
spirit of scoring debating points than illuminating. May I suggest  
that the interested parties work together, behind the scenes, on a  
set of definitions that are based on common technical usage and then  
get back to the rest of us? Public email sniping in front of an  
audience of hundreds seems unlikely to produce accuracy or precision  
or confidence.

Henning

On Sep 10, 2006, at 12:56 AM, Byron Smith wrote:

> Andrew Newton wrote:
>> At the risk of ending the cordial and praiseworthy correspondence  
>> of this thread, I would like to interject that I am fairly  
>> confused.  Certainly (pun intended) I should have given much more  
>> attention to my math and statistics studies when I was younger.
>>
>> could I understand why a PSAP would want to know it.  "The  
>> building I am in is on fire, but I'm only 50% certain that it is  
>> my house.  I could be at work as well."  That just doesn't make  
>> sense.
> determined accurately enough so that the PSAP can plot the location  
> on a map and dispatch to the correct civil address. And the PSAP  
> wouldn't care about any "uncertainty."
>
> wireless carriers / commercial mobile radio service (CRMS)  
> providers vary considerably in their ability to render an accurate  
> fix of the caller's location.  This is especially true of "network- 
> based" angle / time of arrival systems.  The distance of the caller  
> from the tower, the presence of objects (like large buildings) that  
> reflect the radio signal, and the geometry of the location between  
> towers in triangulation systems, can cause the accuracy of the fix  
> to vary greatly.
> In these cases, it may be very helpful to the PSAP to have an  
> estimate of the uncertainty of the fix.  If they dispatch to the  
> caller's reported location and cannot find the caller, then the  
> uncertainty may help them decide if they should search +/- 1000  
> feet, +/- two miles, etc. from the fix. So it may help them bound  
> the search area.
>> this correct?  And can somebody point to an actual definition of  
>> the word?  Is it the same as confidence as is used in probability?
> When an uncertainty is reported, it means there is a certain  
> probability that the actual value is within the expressed  
> interval.  The actual probability may be explicitly expressed:  n  
> +/-e  with 67 % probability, or it may be implied by convention  
> (typically 95%) or as a "known" characteristic of the system.
>
> location systems is that the reported position is accurate +/- 50  
> meters 67% of the time, +/- 150 meters 95% of the time.  In such  
> cases, only the lat/long need be reported.
> For those 5% of the calls that are outside of the 150 meter  
> requirement: "location attempts must be made and a location  
> estimate for each call must be provided to the appropriate  
> PSAP."  (Title 47, Part 20, Sec 18 h (3).)
>
> How the system would determine if the call falls into the 5% case  
> is not clear.  Most systems report an "uncertainty" with every  
> call, even though (in principle) it is not required 95% of the  
> time, assuming the system meets the FCC requirements.
>>
>> terminology but I believe the concept is appropriate.  3825 uses  
>> the term "resolution".  I would have thought resolution would  
>> refer to the range of numbers allowed in the protocol fields.   
>> Instead, it is being used to describe the resolution of the  
>> measurement.  That is fine.  And the take away from it is that a  
>> point in 3 dimensions is being expressed.
> Correct.
> To the receiver these are essentially equivalent views.  For  
> example, if I can measure some value as xx.xx +/- 0.005, but  
> report:  45.343612, everything after 45.34 is just "noise."  The  
> sender should not report more than 4 significant digits, since  
> anything more is meaningless, or, the receiver should ignore  
> everything after the 45.34, if it "knows" the resolution is 4  
> significant digits.
>
>> Now, if the receiver of this information is capable of  
>> understanding a higher "resolution", then one could start asking  
>> questions about the probability of where a point (at the receivers  
>> highest resolution) resides inside the shape that can be taken  
>> from the senders lower resolution point.  I guess that might be  
>> useful if first responders are sent to the location given by the  
>> higher resolution point, find nothing, and are then advised to  
>> search a perimeter of a specific size.
>> saying the same thing.  Which term is correct?  At present, I'm  
>> not convinced either is.
> Resolution is usually expressed as "number of significant digits,"  
> e.g. 3 1/2 digits.  RFC-3825 properly describes its expression of  
> accuracy as "resolution," because it is telling you how many digits  
> in the lat/long can be "counted."  On the other hand, most CMRS  
> systems report "uncertainty" to the PSAP.
> It is fairly straightforward to convert between these two  
> notations.  So these documents really are saying the same thing.
>>
> The terminology in the Appendix should probably be improved.  It  
> isn't really a geometric object, it is a (derived) uncertainty  
> range or interval
>> And if 3825 is describing a point, how can its equivalent in GML  
>> be a linear ring?  I would think it would be a GML point (or  
>> Position in GML speak).
>>
>> -andy
>>
>>
>>

---

From: "Marc Linsner" <[email-masked]>
Date: Sun, 10 Sep 2006 12:24:06 -0400

James, 

> For RFC-3825 to be acceptable for emergency services it 
> should be restricted to representing what it can adequately 
> represent and not be used to represent location that it is 
> quite clearly not fit for, i.e anything that is not a simple 
> point. The RFC on this point is far from clear, and I am 
> suggesting that the authors and supporters of this 
> specification write a clarifying proposal describing its 
> useability and applicability to emergency applications.

You continually propose that emergency services are different wrt using geo
coordinates.  There is nothing special about emergency services, geo
coordinates describing a point IS the target technology that emergency
responders need/want.

I have little experience inside a psap, but on the occasion I have visited
one, I asked the call taker about the confidence included with Phase II
calls.  Most call takers don't know what it is, and those that do, ignore
it.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 10 Sep 2006 17:25:59 -0500

Again I think you are confusing the terms confidence and uncertainty.
Please see Martin's previous email.

In the US, almost no two PSAPs are the same, and there are certainly
PSAPs in the US that have systems capable of displaying uncertainty
areas to PSAP operators.

As I pointed out to you off the list, the key difference between
emergency services and other services is that there is legislation
requiring the degree of accuracy, consequently as an access provider you
need to make sure that you can meet them.

Cheers
James 

> Sent: Monday, 11 September 2006 2:24 AM
> To: Winterbottom, James
> Cc: [email-masked]
> You continually propose that emergency services are different wrt
using
> geo

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 11 Sep 2006 04:02:09 -0500

Hi Carl,

Thanks for the input.
I guess as far as I see it, this should go one of two ways.
Either, stipulate RFC-3825 as representing a point only, in which case a
specification is required to make this clear and unambiguous.

Or

A specification is required expressing how to interpret the encoding
scheme such that the problems around the equator, prime meridian and
other arbitrary locations are not encountered.

I don't mind which, but a problem exist and supporters of the RFC-3825
mechanism should seek to resolve it. Until such time as it is resolved
this specification should only be used with a great deal of caution.

Cheers
James

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, 11 September 2006 6:36 PM
> To: Winterbottom, James
> Cc: John Schnizlein; [email-masked]; Marc Linsner; [email-masked]
> Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency
> sessioninitiation, need for time and accuracy?
> 
> This conversation peaked my interest. I have just looked at RFC-3825.
Not
> having been privy to all the original discussions and decisions, I am
a
> fresh set of "eyes" looking at this document. I think what we have
here is
> a failure to communicate due to ambiguous semantics in 3825. I may be
> wrong in this perception, but . . .
> 
> My interpretation is that what is being defined is a uncertainty shape
in
> which the location of the device falls. As such, it is not truly a
point.
> A point in Euclidean geometry has no size, orientation, or any other
> feature except position. This is the basis of the ISO/OGC definition
for a
> point geometry.
> 
> Take the following example. We draw a point by placing a dot with a
> pencil. This dot may have a diameter of 0.2mm, but a point has no
size. No
> matter how far you zoomed in, it would still have no width.
> 
> What this discussion is really about is the fact that a point
geometry,
> whose location is defined by a lat/long coordinate, also has
properties.
> These properties include estimates of accuracy and precision. Very
simply
> stated: If the actual value is 4.321 and you say that it is 4.30, then
you
> are precise to the first decimal place but inaccurate by .021. There
are
> also properties of error and uncertainty. All these four properties
are
> very well defined in the literature. For example see:
> http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html
> 
> So, what I would suggest is that perhaps 3825 be modified to very
clearly
> disambiguate the semantics of the terms being used. I suspect that
what
> "resolution" is really referring to is a description of the
uncertainty of
> the measurement. The point being measured falls somewhere in the area
of
> certainty. The shape of this area (yes, it is an area/polygon)
actually
> has a pretty strange shape if one transforms from lat/long to some
other
> coordinate reference system, such as State Plane.
> 
> Regards
> 
> Carl
> 
> 
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> 
>

---

From: John Schnizlein <[email-masked]>
Date: Mon, 11 Sep 2006 10:19:40 -0400

On Sep 11, 2006, at 4:36 AM, [email-masked] wrote:

> having been privy to all the original discussions and decisions, I am a

Why you would claim not to have been in the discussions?

On Jan 23, 2003, at 6:20 PM, Carl Reed wrote:

> Hi Mark
>
> Very good questions and a proper concern. I will pass this question on 
> to a
> real "datum professional". One of our members is the Chairman of the 
> EPSG
> Geodesy group. We also have an entire Working Group dedicated to 
> Coordinate
> Reference Systems (which include datums - horizontal and vertical).
>
> Regards
>
> Carl
>
> ----- Original Message -----
> From: Marc Linsner <[email-masked]>
> To: Carl Reed <[email-masked]>
> Cc: John Schnizlein <[email-masked]>; James Polk 
> <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, January 23, 2003 8:16 AM
> Subject: RE: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt
>
>
>> Thank You!  Those of us working on the draft certainly have been
>> looking for a 'datum expert' to help us out!
>>
>> Now you're 'on the hook'! :^)
>>
>> If I'm correct in my intrepretation of the epsg database, it appears 
>> there
>> are 267 datums.  If we use the epsg codes, they require 2 bytes 
>> (actually 14
>> bits) to represent them in binary.  You're implying that lining up 
>> with epsg
>> is the proper thing to do, rather than creating news codes for each 
>> datum
>> under the IANA umbrella.  I'm struggling with the 'rumors on the 
>> street'
>> that some of the datums may never be used - in fact only ~100 are 
>> actively
>> used today.  The part I'm struggling with is to utilize 2 bytes when 
>> only
>> ~100 choices will be in use.
>>
>> Your thoughts one more time, please.
>>
>> -Marc Linsner-
>>
>>
>>
>>> From: Carl Reed [mailto:[email-masked]]
>>> Sent: Wednesday, January 22, 2003 6:15 PM
>>> To: Marc Linsner
>>> Subject: Re: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt
>>>
>>>
>>> Hi Marc -
>>>
>>> There is no political issue related to a datum. There is no
>>> "correct" datum for a locale. There can be many datums for a
>>> given location - all of them correct. For example, in the US
>>> many localgovernments deal with WGS 84, NAD 27, and NAD 83 datums.
>>> Many local government planimetric databases are now in NAD 83.
>>> In order for anyone to process a location and make sure that it
>>> is georeferenced with a given planimetric or cadastral database,
>>> the datum needs to be known. This is not a political issue -
>>> simply a reality in the geospatial processing world
>>> - especially one in which interoperability of
>>> spatial data source (static and real time) is required.
>>>
>>> Regards
>>>
>>> Carl Reed

---

From: Andrew Newton <[email-masked]>
Date: Mon, 11 Sep 2006 10:42:38 -0400

> Why you would claim not to have been in the discussions?

At this point, I will put my chair hat on and say that there is no need to 
go down this particular dark alley.

So far, I am only hearing one person claiming that 3825 is inadequate and 
many other voices suggesting that it merely needs clarification.  Certainly, 
3825 would not be the first RFC in IETF history needing clarification.

As part of any clarification effort, I think the community would be well 
served to have 3825 to GML conversion examples.  Not having fully digested 
the requisite amount of morning coffee, I cannot easily judge if GML can 
express uncertainty about a point.  That would "certainly" be helpful.

And as Henning has suggested, we would also be well served by documented and 
agreed upon definitions of these terms.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 11 Sep 2006 10:18:20 -0500

I am not sure that I know what Uncertainty about a point means.
GML certainly can express areas of uncertainty and that was the purpose
of the geoshapes draft.

I might point out that the problems that Martin T and I have raised with
regards to the encoding scheme in RFC-3825 have come about from exactly
doing what is proposed below. We tried to turn the elements returned by
RFC-3825 into a GML object. So to my mind I am not sure where this
leaves us.

Cheers
James

> Sent: Tuesday, 12 September 2006 12:43 AM
> To: John Schnizlein; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] RE: [Ecrit] Location information inemergency
> And as Henning has suggested, we would also be well served by
documented