Also, there's the problem I brought up yesterday. If a server sees
this input, where a polygon has a whole in it:
Now, is the server to find the centroid of the polygon or is it
suppose to look for an exact match of the polygon?
That seems like a completely different question compared to the
profile issue, or at least I'm missing the connection.
This is indeed a real problem, but only if the location of the
querier itself has a hole. There is no problem for the case where the
service boundary has one or more holes. The location-with-hole case
only occurs in the location hiding case, as far as I can tell, and is
relatively uncommon even there.
There are two solutions, neither of which is totally satisfying.
(1) Exact match, as you indicate. In other words, a LoST server first
tries to find an exact match for the boundary. For the location-
hiding case, this will always work.
Advantage: The client doesn't have to know.
Disadvantage: LoST servers need a special case.
(2) Transformation in LIS: The carrier that wants to hide a location
creates a convex location region that has no holes and includes the
location of the UA. A very simple way to do this is to return a
triangle (square, circle, ...) that includes the caller's location
(not in the center) and whose centroid falls into the PSAP service
area. This has to be done only once (unless the PSAP boundary
changes), so the computational burden is trivial.
Advantage: No special case in LoST servers.
Disadvantage: Requires some special geometric treatment for special
I have some preference for (2), since it's a bit cleaner and it's
conceptually no different from a wireless location system with a very
imprecise location technology, such as cell-face only. It requires no
standardization as such, as long as we standardize the centroid
Ecrit mailing list