>Would another way to phrase this "Option C" be the following:
err... didn't I mention this specific layout in the previous message
within this thread (though not yet calling it "Option C")?
I'll grant you naming rights if we can agree to this... ;-)
>-- "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
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? 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.
James
>-- 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
