-- "Normal part": location with low enough precision to include the
intended location
-- "Relative part": further granularity for the reference point, plus
the offset
That way, entities that don't understand get a less precise, but still
correct location.
So for example, if we wanted to refer to an ellipse offset from an
<LMK> in a building...
In Civic:
-- Normal: country, A1, A3, PC, HNO, RD, STS, FLOOR
-- Relative: LMK, offset shape
In Geodetic:
-- Normal: outline of the building
-- Relative: point inside building, offset shape
It's still a little wasteful in the geodetic case, but it's not that
bad.
--Richard
On Apr 9, 2010, at 3:29 PM, James M. Polk wrote:
> At 07:16 PM 4/8/2010, Thomson, Martin wrote:
>> Thanks James, that's pretty much what I've been proposing.
>
> I know we aren't too far apart but what I am proosing is not what
> you have been proposing - as I don't agree with your proposal to
> include both
>
> USA->Florida->Miami->BuildingA->Floor4
>
> and
>
> USA -> Florida -> Miami -> Building A -> Floor 4 ->
> Elevator -> Polygon Offset
>
> in the same message. I am personally in favor of just having any one
> <element> in the PIDF-LO once, such as this:
>
>> > Civic: USA->Florida->Miami->BuildingA->Floor4
>> > Relative: (ref-point=) <some point on 4th floor>->offset from
>> that point
>
> but I know Brian is the one who adamantly opposes the idea of
> indicating which is the reference point/element - and I think that
> is flawed. I believe my offering above is the one that
> interoperates perfectly with existing implementations, given that
> any LR that doesn't understand this particular extension can't
> confuse any of its ref-point= or offset elements (in XML or in
> binary).
>
> We also can't expect that an LR that does understand this extension
> to somehow not understand the <ref-point=> element, so that argument
> goes out the window in this proposal.
>
> The key to the above proposal is to uniquely identify each
> "Relative" <element>. You can call this another location type, you
> can call this variations of the <INT> element type. I don't care as
> a practical matter, just so long as they are uniquely identified so
> any LR that doesn't understand this extension CAN'T misinterpret the
> information (which is a fear you've stated over and over again).
>
> There also needs to be MUST NOT level text about not allowing the
> offset to be very far away from the perimeter of the property that
> is understood within RFCs 4119 and 5139. If we agree on that idea,
> we can then work on the distance that should be allowed, and what is
> too far - as guidance. An example of this in urban areas is
> nothing outside the parking lot perimeter surrounding the building
> in the PIDF-LO. I'm not sure what is viable in rural areas, but
> perhaps the property line in the PIDF-LO is good there too.
>
> James
>
>>
>> > I think it should like this:
>> >
>> > Civic: USA->Florida->Miami->BuildingA->Floor4
>> > Relative: (ref=) Elevator->offset
>> >
>> > where the reference <element> is identified, and everything in the
>> > relative part is separately indicated to ensure there is no
>> confusion.
>> >
>> > This both reduces the data to its minimum set, and for
>> > interoperability - only what's understood will be used, with the
>> > possibility that the recipient doesn't understand this extension,
>> > meaning they don't understand the whole "Relative" part, leaving
>> that
>> > entity to believe the target is on <Floor>4</Floor>. We just
>> have to
>> > have firm text saying the target must be within x distance of floor
>> > 4. An easy example of somewhere outside floor 4 that still needs
>> to
>> > be valid is a parking lot outside the building, or a window cleaner
>> > hanging outside the windows of floor 4.
>> >
>> > 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
