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.
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
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
