"
This extension effectively allows the creator of a location object to
include two location values plus an offset. The "baseline" location
that is given outside of the <relative> element is what will be
visible to a client that does not understand that extension (i.e., one
that ignores the <relative> element). A client that does understand
this extension will interpret the location within the relative element
as a refinement of the baseline location, which gives the reference
location for the relative offset.
Creators of location objects with relative location thus have a choice
of how much information to put into the "baseline" location and how
much to put into the "reference" location. For example, all location
information could be put inside the <relative> element, so that
clients that do not understand relative location would receive no
location information at all. Alternatively, the baseline location
value could be precise enough to specify a building that contains the
relative location, and the reference location could specify a point
within the building from which the offset is measured.
In any case, it is RECOMMENDED that the baseline location be general
enough to describe both the reference location and the relative
location (reference plus offset). In particular, while it is possible
to put all location information into the "reference" location (leaving
an universally broad "baseline"), location objects SHOULD NOT have all
location information in the "baseline" location. Doing this would
cause clients that do not understand relative location to incorrectly
interpret the baseline location (i.e., the reference point) as the
actual, precise location of the client.
"
On Apr 16, 2010, at 12:44 PM, Brian Rosen wrote:
> So, just making sure I understand what I'm doing to the text:
> A) I'm leaving the basic location alone, but probably changing the
> name of
> it, because it's not the reference location
> B) I'm adding an element to the offset, or adding some new element
> at the
> same level as the offset, that can have some fields that are in a PIDF
> civic, specifically, CAtypes, or a new geo location that is as
> general as
> the original (point or shape, WGS84 CRS, ...)
> C) This refinement of the reference point for a civic is constrained
> to be
> more specific -- that is the CAtypes have to be more specific then
> the last
> one in the initial location
> D) With a geo, the only way to make any use of this is to specify a
> location
> with a large uncertainty in the original location, and then specify
> the same
> location with a smaller uncertainty in the extension. We would
> probably
> want to constrain the implementation to that. This means that it's
> Option
> A for geo.
> E) I imagine there is no reason to require the second location --
> that is,
> if you just have the original location, and an offset, it's fine.
>
> Brian
>
>
> On 4/16/10 10:10 AM, "Alissa Cooper" <acooper@cdt.org> wrote:
>
>> There are still some details to be worked out, but I think we are
>> very
>> near to consensus on "Option C." I'd like to suggest that Brian in
>> his
>> editorial role try to work this approach into the current draft and
>> share it back with the design team and then the list.
>>
>> Alissa
>>
>>
>> On Apr 11, 2010, at 8:20 PM, Thomson, Martin wrote:
>>
>>> James Polk writes:
>>>>> In Geodetic:
>>>>> -- Normal: outline of the building
>>>>
>>>> we should discuss this - as I think this (point "outline of the
>>>> building") is problematic. What if you are at Yankees stadium or
>>>> Soldier's Field. Where is the point "outline of the building"?
>>>> that
>>>> still means Yankees stadium or Soldier's Field?
>>>
>>> That depends. It might be reasonable to use a shape that encloses
>>> either the stadium or the enclosing grounds.
>>>
>>>> I think for Geo, we
>>>> have to agree if the geo points to a property, and then there can
>>>> be
>>>> either:
>>>>
>>>> - a reference point within that property aside from the macro geo
>>>> coodinates, or
>>>> - us the exact geo as the reference point to then do an offset
>>>> from.
>>>>
>>>> I know James and Martin will balk at this latter choice, saying why
>>>> not just recalculate the external geo -- but I think that isn't so
>>>> obvious, but it may be.
>>>
>>> Not so much as you might think. While I always favour the inclusion
>>> of more information, and Richard's presentation is what I would
>>> consider ideal, this usage isn't that offensive.
>>>
>>> A recipient that receives the information is not presented with more
>>> precision than there is accuracy, since there is no claim made with
>>> respect to accuracy.
>>>
>>> --Martin
>>>
>>>> James
>>>>
>>> _______________________________________________
>>> 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
