Couple of observations here:
1. In many use cases, the offsets we're talking about here are not
enormous -- typically on the order of the size of a building. So
while degraded location might be inaccurate, it will often still be
accurate enough to be useful (e.g., for getting packages).
2. In cases where the offset is expected to be large, interoperability
concerns are mitigated by the fact that a lot of cases the sources and
consumers of location will be under the control of the same entity.
For example, if a cruise ship reports position relative to its GPS
receiver, then uses these location values to direct its medical staff
in emergencies, then when it purchases the medical software, it can
check that it works with relative location so that the ship's doctors
aren't running to the GPS antenna all the time.
3. In cases where the source and consumer are independent, the
consumer has an incentive to do the right thing: to implement relative
location if it's significant, since it will improve the function of
his application, or to ignore it if it's irrelevant (i.e., if the
application only needs location to a granularity coarser than the
typical offset).
4. Clients can still *recognize* the extension without *processing*
it, so they can provide a signal to users that "something may be weird
with this location value" with low cost/complexity.
5. The claim that in Option A, clients will ignore the whole location
assumes that clients will ignore GML based on CRS. This may not be
true in practice; I can easily imagine software that either assumes
the CRS is WGS84 and doesn't read the the CRS at all, or that reads
the CRS but halts processing of the location value as a whole if it's
not a CRS it understands (i.e., WGS84). So Option A could still cause
clients to think that they are where aren't (usually, off the coast of
Ghana) or that they have no location at all, even if there's another
location value in the LO.
Net of all that, it doesn't seem to me like there's a huge difference
between the two proposals. My inclination is to go with Option B
("Interpret the reference location part as the actual location (and
ignore the relative part)"), but I'm not hard over. Option A just
seems a little pedantic in light of the use cases.
--Richard
On Apr 8, 2010, at 2:57 AM, Dawson, Martin wrote:
> Hi Allan,
>
> I think the point is that going down to "elevator" is precision
> beyond the actual accuracy. The interpretation under option B
> becomes that the location is "at the elevator"; it could be at the
> far end of the fourth floor in this case.
>
> Since the application doesn't have any knowledge to understand what
> the extent of the offset is with reference to any of the other
> components of the location it can only, as Martin says, guess. In a
> general framework, that's not actually a solution.
>
> Given the location server does actually understand (yes, that's the
> assumption) the relative significance of the location and offset
> components, it's in the best position to offer both alternative
> forms. The relative form is, for example, the most precise location;
> the "standard" form is more semantically constrained such that it
> can only provide a less precise location. Nevertheless, it is
> straightforward to see how a server can do this automagically -
> whereas it's not possible to see how an arbitrary client can
> correctly disassemble the single relative form from an arbitrary
> source.
>
> Cheers,
> (the other) Martin
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of althomso
> Sent: Thursday, 8 April 2010 4:33 PM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: Re: [Geopriv] Consensus request: Relative location and
> encoding options
>
> I guess we are just talking past each other.
>
>
> On 4/7/10 7:09 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
> wrote:
>
>> The pseudo method misrepresents the problem, but that's what we
>> were arguing
>> over in the first place. What you are actually saying is:
>>
>> Polygon, relative to: USA->Florida->Miami->BuildingA->Floor4-
>> >Elevator
>>
>>
>> The problem is that "Elevator" is wrong. If this field is
>> understood, then
>> the recipient uses the wrong location.
>
> AT: How is that the wrong location? What you are suggesting is that
> they
> wouldn't use any of the location upto including Elevator if they
> just don't
> understand Polygon whereas I'm saying that if they at least understand
> Elevator (and everything up to it) then that is better/more location
> than
> they have if they discard the entire location.
>
>>
>> An offset always invalidates some parts of the reference location.
>> The
>> problem here is that the recipient is not given the information
>> necessary to
>> distinguish right parts from wrong parts.
>>
>> It's trivially possible to provide:
>>
>> Civic: USA->Florida->Miami->BuildingA->Floor4
>> Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4-
>> >Elevator
>
> AT: In what sense is it trivially possible to provide? That a server
> understands all capabilities and application needs that run on a
> device and
> provide the exact location used by each application on that device?
> If that
> is what you mean by trivial I would disagree. It is much simpler to
> provide
> a full location object and let the application /device decide what
> parts it
> can use or not. If the application or device wants to disregard the
> complete
> location if it doesn't understand part of it then the application /
> device
> can choose to do that. What you are suggesting is the protocol
> mandates that
> behavior and that is where we disagree. It is up to the application
> and
> systems using the protocol to decide how they want to treat elements
> they
> don't want or understand.
>
>>
>> And thereby provide useful information without relying on guesswork.
>>
>> --Martin
>>
>>> -----Original Message-----
>>> From: althomso [mailto:althomso@cisco.com]
>>> Sent: Thursday, 8 April 2010 11:29 AM
>>> To: Thomson, Martin; geopriv@ietf.org
>>> Subject: Re: [Geopriv] Consensus request: Relative location and
>>> encoding options
>>>
>>> Taking a more concrete indoor location example. <excuse the pseudo
>>> method
>>> for defining the loc>
>>>
>>> USA -> Florida -> Miami -> Building A -> Floor 4 -> Elevator ->
>>> Polygon
>>> Offset
>>>
>>> A device receiving this would still be able to use
>>> USA->Florida->Miami->BuildingA->Floor4
>>>
>>> If it doesn't understand the polygon/elevator part and the
>>> location is
>>> still
>>> more usable/accurate than if none were provided at all.
>>>
>>> So Option B would provide more useable information than Option A.
>>>
>>> Another example, if a device doesn't understand or care about
>>> floors in
>>> the
>>> USA->Florida->Miami->Building->Floor example does that mean it
>>> should
>>> disregard the complete location also? Even though it only cared
>>> about
>>> the
>>> location up to building granularity?
>>>
>>> I would suggest Option B is better for most systems/applications.
>>>
>>> allan
>>>
>>>
>>> On 4/7/10 6:14 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
>>> wrote:
>>>
>>>> I promised to provide a picture of relative locations so that we
>>> could resolve
>>>> the issue we have with the relative draft.
>>>>
>>>> Here it is:
>>>> <http://www.flickr.com/photos/49099289@N05/4501565914/sizes/o/>
>>>>
>>>> There is little contention on the fundamentals. The authors all
>>> agree on what
>>>> data is included, even if there are some details that haven't yet
>>> been
>>>> resolved.
>>>>
>>>> The conflict that needs resolution regards the behaviour we want
>>> existing
>>>> PIDF-LO implementations to follow:
>>>>
>>>> Option A:
>>>> Ignore relative locations.
>>>>
>>>> Option B:
>>>> Interpret the reference location part as the actual location
>>>> (and
>>> ignore
>>>> the relative part).
>>>>
>>>> Brian will argue that the impact of B is harmless and sometimes
>>> desirable,
>>>> since the offset is small anyway, and something is better than
>>> nothing.
>>>>
>>>> I will argue that option B revises the semantics of existing RFCs,
>>> which
>>>> intentionally and unnecessarily misleads existing implementations.
>>>>
>>>> It's important to note that there are separate encodings for XML
>>>> and
>>> compact
>>>> (binary). We can make a different decision for each encoding, if
>>>> we
>>> believe
>>>> that to be justified. This is already true of other aspects of the
>>> current
>>>> draft.
>>>>
>>>> Feel free to suggest your own option if these don't fit, as Jon did
>>> at the
>>>> meeting recently.
>>>>
>>>>
>>>> As stated, my personal position is that Option A must be used for
>>>> the
>>> XML
>>>> encoding. Extensions do not have a criticality indicator (in the
>>> same way
>>>> that X.509 extensions do) that would allow us to make breaking
>>> changes of this
>>>> nature.
>>>>
>>>> I also believe that Option A is correct for the binary encoding.
>>> However,
>>>> there is enough detail absent from the current proposal that it
>>>> would
>>> be
>>>> impossible to form a definitive opinion on the impact of this
>>>> choice.
>>>>
>>>> --Martin
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> Geopriv@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
