Re: [Geopriv] Latest on draft-ietf-geopriv-relative-location-01.txt?

From: Cliff Behrens ^lt;>
Date: Fri Sep 09 2011 - 15:12:25 EDT

On 9/9/2011 3:15 AM, Thomson, Martin wrote:
> On 2011-09-09 at 02:49:36, Cliff Behrens wrote:
>> Martin,
>> [...] For example, a location value
>> assumes the existence of some localization technique,
> Gotta pull you up here: a location value is agnostic of how it is determined. How you got it is highly specific, but the value itself is completely divorced from its method of acquisition.<method> says something about that process, but - as I've explained - it's not all that good or reliable in providing usable information.
Not entirely agnostic, if one of it's attributes is "uncertainty," but I
won't beat on this anymore.
>> [...]
>> However, this isn't to say that this grid map is the same document
>> that one would want to reference for purpose of determining relative
>> location, though the location value provided by localization would be
>> useful for finding such a document. But who knows where it is, or
>> whether one referenced in a PIDF-LO is actually useful?
> Those sorts of decisions are usually accomplished by what might as well be magic. I have some ideas, but from a standardization perspective, they aren't that interesting. Basically read that as an opportunity to provide your own marvelous ideas.
Yeah...I too am now thinking along these lines.
>> HTTP content negotiation sounds like a nice idea. I'm less familiar
>> with how this actually works. If a catalog is referenced rather than a
>> map, does the URI have to be typed to distinguish the difference
>> between them to facilitate negotiation?
> The URI isn't inherently typed. Content negotiation allows you to negotiate with the authority for the URI over what content they provide you. You can say: "I'd like a CityGML BIM please (maybe with some other stuff)", and they say "here, have a jpeg". Or they actually have something approximating what you want and you can get that.

The RFC specifies map type, e.g., <map type="image/png"> followed by a
URI. Might not another type be added, e.g., "catalog," along with the
URI to it?

>>> Velocity [...]
>> OK...but strikes me as the kind of application-specific complexity you
>> caution against below. If velocity, then why not acceleration, etc.?
> Velocity was deemed to be valuable, in and of itself. Acceleration was not.
>>> The only metadata we currently provide is the "type" attribute of
>>> the map [...]
>> Other metadata may be important. For example, CityGML BIMS come in
>> five levels of detail (LOD) ranging from something as simple as a
>> digital terrain model to a detailed, walkable indoor model. Merely
>> knowing that a CityGML BIM exists wouldn't be sufficient for deciding
>> whether it might be useful if I needed the higher LOD. Even with more
>> simple floorplans, it may be useful to know what floor in a building
>> is involved.
> Other metadata might be better sourced from places that have better knowledge about what metadata is applicable.
I agree. This is the reason I think it is important to provide a
pointer that associates a source for these metadata with a location in a

Clifford Behrens, PhD
Senior Scientist&  Director
Information Analysis
Applied Research
Telcordia Technologies, Inc.
Phone:  732-699-2619
FAX:    732-336-7015
Geopriv mailing list
Received on Fri, 09 Sep 2011 15:12:25 -0400

This archive was generated by hypermail 2.1.8 : Fri Sep 09 2011 - 15:13:17 EDT