Martin,
Thanks for this clarification. I have responded using italics inline below.
Cliff
------------------------------------------------------------------------------------------------------------------
Hi Cliff,
Thanks for taking the time to look at this.
Glad to help in anyway I can. On 2011-08-27 at 03:21:55, Cliff Behrens wrote:
> All,
>
> Can someone please tell me what the status is of
>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-relative-
> location
> -01.txt? It seems that the last revised draft was submitted on March
> 28, but there has been no follow-on activity or discussion related to
> it.
We're still expecting an updated version.
> I would be happy to pick-up this thread, if it is proper for me to do
> so, not having any previous involvement with this group.
Please do. Fresh eyes are always welcome. And valuable.
> I guess what still seems most mysterious to me at this point is how
> (and
> when) a target location is placed in the context of a World Coordinate
> Reference System. I suppose the map document reference used for this
> could be put in the PIDF-LO by the localization application, assuming
> that all of this was planned in advance. But I wonder about the case
> where a team must respond to an address for an emergency, so must
> discover whether a map document or BIM exists for it, along with the
> method of localization used (if one exists).
Discovery shouldn't really be necessary - the document includes the means to provide a link (URI) to a map or BIM resource. We haven't nailed down exactly what it is that is identified by the URI, simply because we haven't seen any clear indications that any one solution is going to be chosen.
When is this URI added to the PIDF-LO, and how? If the facility that does this is impaired during an emergency, then it may be necessary to determine whether another copy or source is available. Or, if all you get from a caller is a civic address, then it may be desirable to determine whether a map doc, e.g., BIM or floorplan, exists for this location. > In other words, it seems
> like search of a catalog or registry might be required.
I for one, am against the building of a catalogue. I suspect that such a thing would be outside the IETF's remit.
I'm not suggesting that the IETF specify geospatial catalog services. The OGC and others have already provided this. I am merely trying to anticipate situations like the ones I mentioned above, and recognize as others in the geospatial data community already have that geospatial objects, e.g., maps, images and BIMs, can be very large. So it makes sense to search a catalog/registry of their metadata rather than parse the object itself. This idea is consistent with OGC architecture. Also, in many situations it is desirable to search one or a few locations for these metadata. I am thinking of "call before you dig" as an outdoor example. > In either
> case, I think that instantiation of a PIDF-LO requires localization
> and contextualization applications that retrieve information and
> perform computations with it, and while these applications are
> implicit in the current draft, I'm not sure that the PIDF-LO as
> specified facilitates this data flow. Is it others' understanding
> that the secondary map data/metadata would be provided by the localization service?
See above - the <map> element provides this capability. It's crude, sure, but it's at about the level we thought would work. Anything more complete is also likely to be more complex - and that complexity has to be justified. We couldn't justify anything more than what we have. Feel free to disagree.
These metadata may be sufficient from some purposes. But it seems to me that other information in the PIDF-LO (and applications that use it) may require additional information. For example, uncertainty is likely tied to localization technique or resolution of an image. Guess what I am looking for here is a mechanism whereby one can find all the metadata needed for an application without necessarily expecting to find in in the PIDF-LO or having to parse the entire map object, e.g., BIM, to get it. > Then there's that huge "hairball" related to "shapes of uncertainty."
> My feeling on this is that, if you feel the need to include some
> measure of location uncertainty in the PIDF-LO, then you should either
> provide the shape and the location of its boundary for an agreed-on
> uncertainty value (e.g., 5% error), or provide a shape (and the
> location of its
> boundary) with its uncertainty value.
We use the term "confidence" when referring to probabilities of that sort.
The draft already has that capability (the latter). See the expression of uncertainty regions - and the implied 95% confidence - in RFC 5491. Those same capabilities are used here.
What I found in RFC 5491 is, "It is RECOMMENDED that uncertainty is expressed at a confidence of 95% or higher. Specifying a convention for confidence enables better use of uncertainty values. What wasn't clear is how this is expressed in the PIDF-LO. Is the implicit assumption that the probability of finding a target in the shape provided is 0.95? Even if this is the case, I didn't see mention of this in the March 28 revision. Here again, computation of this uncertainty is a function of data accuracy and precision, and these are intimately related to attributes of the map document and localization technique. Having said all of this, I find it difficult to imagine point sampling of locations provided by a localization technique might yield the regular shapes specified in this draft...but if this it what some want, I guess it is up to them to figure it out. It seems to me that it would be easier to specify an uncertainty value for a shape, rather than a shape for an uncertainty value. > However, if all you are trying
> to convey is that a target is located somewhere within a space bounded
> by well-known building features, e.g., an office, presumably the
> coordinates of the boundary would be derived from a map document,
> e.g., a floorplan or BIM, and these would convey location uncertainty,
> e.g., I am only certain that Joe is in the main conference room but I
> can't tell you exactly where he is in it.
How is that distinction important? Whether I am uncertain about the location or whether you are uncertain about the location ultimately makes little difference if you are the consumer of the location information.
Here is an example. If I'm delivering a pizza to Joe, it is sufficient to know that he is in the conference room, with the shape provided by the BIM. In this case, the probability may well exceed 0.95, I really don't care. I only need to find the right room. > Section 1
>
> (1) The reference location can also have dynamic components such as
> velocity. The relative offset is specified in meters using a
> Cartesian coordinate system.
>
> Does this belong in the object? If so, should it have orientation
> (and in Cartesian coordinates)? Does this make sense indoors?
Yes. Depends on your "indoors". Think of a cruise ship or any other "building" that moves. It's actually a case where relative location is most useful.
OK. I guess that I imagined something like velocity being computed by an application that uses location information in a series of PIDF-LOs. In other words, this struck me as derivative information. > (2) Applications could use this information to display the relative
> location. Additional fields allow the map to be oriented and scaled
> correctly.
>
> Shouldn't this be data or metadata either stored with the referenced
> document or in a catalog that references it?
Catalogue?
Yes, this is metadata, but we don't have the luxury of a consistent and controlled context into which we can reliably place such metadata. Thus, we populate the object with metadata. See also: usage rules for location objects, timestamps, method, etc...
Again, other metadata and catalog standards (and their implementations) exist for doing this. Why not leverage them? The issue I am struggling with is, how much information should actually be "stuffed" into a PIDF-LO, and how much should be derived by applications/services that can use locations conveyed by it? > (3) ...and the reference location could specify a point within the
> building from which the offset is measured.
>
> If one were to determine location in this manner, then wouldn't it be
> desirable to also specify how localization was determined and its
> accuracy? (See localization generator or LG in GML 3.1.1 PIDF-LO
> Shape Application Schema for use by the Internet Engineering Task
> Force.)
That would be nice - but in order to do so would require restructuring the syntax. Being able to convey more information about the reference point was not considered important enough to warrant the added complexity.
(As an aside, the idea that you can concisely state _how_ location is generated is - in my opinion - a poor idea. Whenever someone asks how, either not answering or answering "magic" is the best way to handle it. With anything more specific, you run the risk of a recipient inferring things - and I've learned that such inferences have a dangerously high probability of being wrong. For instance, if I tell you that I determined where you are based on the identity of the cell tower you are using, would you infer that the location that I've given you is poor? Because you'd be wrong occasionally, especially if that cell is a Femtocell.)
Interesting. In fact, after reviewing 5491 I thought that <gp:method>GPS</gp:method> was at least providing some of this information. Moreover, it seems that the need/uses for this information was already anticipated the GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF):
"The LI that forms the core of a PIDF-LO document originates in the Location Generator (LG). Depending on the specific circumstances, particularly the type of access network, the LG can use any number of methods to determine LI. The range of technologies available for determining LI are numerous and range from user-provided LI, to automatic methods such as wire mapping, radio timing, and GPS." > (4) The baseline location SHOULD be general enough to describe both
> the reference location and the relative location (reference plus
> offset).
> In particular, ....., etc.
>
> This is kind of murky...a figure would help.
Agreed.
Here's how it works:
Relative Location = { Baseline, Reference, Relative }
The actual location is (Baseline ∩ Reference) + Relative.
The reason is that old recipients don't understand Reference and Relative and need to only see the Baseline. Because the (Baseline ∩ Reference) might identify a very specific location - one that is potentially very wrong - we needed to ensure that they only saw something very general.
In practice, this is only really useful for Civic Addresses, where the intersect operation has a hope of working.
I need to think more about this. I am hoping to get some clarification from the OGC folks on how one might discover baseline and reference locations in a CityGML model. > (5) If the baseline location was expressed as a geodetic location,
> the reference MUST be geodetic. If the baseline location was
> expressed as a civic address, the reference MUST be a civic. Baseline
> and reference locations MAY also include dynamic location information [RFC5962].
>
> Seems this constraint is unnecessary if a detailed BIM were obtained
> for a civic address, and then used to determine geodetic locations
> from BIM
> + localization. Why would the baseline location ever change?
Yeah, but in order to have that interoperate, we'd also have to specify which BIM, how that BIM is acquired, etc... That's a big problem.
Feel free to ignore the MUST if you know better within your application, but please don't expect someone random on the Internet to be able to use the BIM.
I believe this gets to my last point. I would also assume that no one would bother searching for a BIM unless they had the means to actually make sense of it. Here again, metadata would help one quickly decide whether they could actually use a map document. > (6) The relative location can be expressed using a point (2- or 3-
> dimensional), or a shape that includes uncertainty: circle, sphere,
> ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of these
> shapes can be found in [RFC5491].
>
> Seems a red-herring if you don't quantify it. Again, this might be
> determined based on localization technique.
Does not parse. Perhaps it's a nomenclature problem.
My problem with this had to do with the fact that a placeholder was created for uncertainty, but it didn't appear that
an attribute was created for it for all shapes. > (7) Optionally, a reference to a 'map' document can be provided. The
> reference is a URI.
>
> How/when is this association made?
Outside of the confines of a protocol specification, by someone who knows (or works out) that link.
What I was also hoping for was support for a URI to find the map doc. I am also trying imagine all of the data bases and applications
required to create this association, and whether some co-location or "shared context" is required for these. For example, when I enter
a building, does this send a request to a local LIS which choses a localization technique, computes a location, then creates a PIDF-LO
with the relative location information and references to a map document? > (8) The document could be an image or dataset that represents a map,
> floorplan or other form. The type of document the URI points to is
> described as a MIME media type.
>
> Including a CityGML BIM.gml.
As you please. As long as you have a MIME media type for your BIM you can use it.
Yep. > (9) Metadata in the relative location can include the location of the
> reference point in the map as well as an orientation (angle from
> North) and scale to align the document CRS with the WGS-84 CRS.
>
> Again, wouldn't this alignment best be made with metadata stored with
> the referenced document? If all of this look-up and alignment is
> driven by an application, then can't it also get the metadata for the
> document and use these to align it and locate the reference point in
> it?
Certainly, though JPEG images don't have a standardized metadata framework for expressing the metadata we need.
It might pay to include a statement along the lines of (the referenced document might include metadata that overrides these values).
Yes, some images, e.g., GeoTIFF, have spatial reference information in their header, while other don't. A GIS or CAD catalog could also
provide these if a URI to them was provided. > (10) The document is assumed to be useable by the application
> receiving the PIDF with the relative location to locate the reference
> point in the map. This document does not describe any mechanisms for
> displaying or manipulating the document other than providing the
> reference location, orientation and scale.
>
> It shouldn't have to. It should only provide the URI to the
> application which uses the PIDF-LO.
Agreed. But we'd like to make that very clear. Clear scope is very important in a specification like this. People have all sorts of unreasonable expectations.
OK > (11) xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
>
> This needed for localization or Location Geneator?
RFC 4119 defines this structure.
> (12) xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
>
> Why is IETF using own specification for civic addresses rather than
> OASIS xNAL standard, as used by OGC?
http://www.xkcd.com/927/
OK...the nice thing about standards is there are so many good ones to choose from. But might it be possible to
use an existing standard if one wanted to interoperate with other BIM users and providers? > (13) xmlns:gs=
"http://www.opengis.net/pidflo/1.0";
>
<http://www.opengis.net/pidflo/1.0> >
> Is all of this still relevant given revisions to this draft?
Indeed, still relevant.
As I recall, my reason for this comment had to do with whether these ns references presented the current view? > (14) <rel:map>
...
> </rel:map>
>
> I can well imagine a use case where all of this is discovered through
> an application using civic or geodetic address and knowledge of LG.
Absolutely. The map is optional.
> Datum, baseline location, reference location, relative location...need
> to be more carefully defined and distinguished, along with the
> implications for each when applied to civic and geodetic addresses.
> Isn't "elevation" a better term since it refers to height above geoid
> (or sea level) rather than height above ground?
These are terms of art. There's an expectation that they are understood. We are fairly careful when defining how the Cartesian space is defined, but if that is not clear enough, please let us know.
Actually, I think a glossary and figure would really help here, at least as these pertain to the draft protocol. And careful with "height above geoid". We've been stung on that one before. Not everyone carries an EGM. We use WGS84, and height above ellipsoid is altitude.
OK...don't want to confuse matters. > (16) Dynamic location information [RFC5962] in the baseline or
> reference location alters relative coordinate system. The resulting
> Cartesian coordinate system axes are rotated so that the 'y' axis is
> oriented along the direction described by the <orientation> element.
> The coordinate system also moves as described by the <speed> and
> <heading> elements.
>
> Not sure this makes sense. Shouldn't the baseline location, at least,
> remain fixed since it may be the only datum stored for a building
> through which one can associate WRS and LCS?
That's only true if the building is stationary, or your reference point is a building.
Got it. > (17) Shape data is used to represent regions of uncertainty for the
> reference and relative locations. Shape data in the reference
> location uses a WGS84 [WGS84] CRS. Shape data in the relative
> location uses a relative CRS.
>
> This makes little sense unless either (a) an uncertainty value is used
> to compute a shape, or (b) an uncertainty measure is provided for a
> shape. Otherwise, if a shape is used to provide an approximate
> location for a target, e.g., somewhere in an office room, then
> presumably a floorplan or BIM (with the proper shape and coordinate
> values) would be used to provide the geospatial context for target
> location.
RFC 5491 describes the term "shape" as it is used in this context.
I addressed this point above. > (18) A circle or sphere describes a single point with a single
> uncertainty value in meters.
>
> Don't see where uncertainty value is provided in the example below
> (i.e., 4.9.2.1).
Look for <gs:radius>.
My comment regarding this point and the one below had to do with the fact that I
saw no attribute for uncertainty value supplied for these shapes, only
values for their geometric properties. Now I understand these are implicit. > (19) A ellipse or ellipsoid describes a point with an elliptical or
> ellipsoidal uncertainty region.
>
> Why doesn't this shape also have associated with it an uncertainty
> value (like the circle), especially if this is the reason for
> providing a shape?
I think that we use very different definitions for uncertainty. See above. The same applies to your comments (20, 21).
> (22) Maps can be simple images, vector files, 2-D or 3-D geospatial
> databases, or any other form of representation understood by both the
> sender and recipient.
>
> I would include a BIM, e.g., a CityGML model, in this list of
> representations.
As implied by the statement, you are free to use any map form that you like.
Great. > But how is this reference added to the PIDF-LO? I
> would also like to provide a link to a catalog service that provides a
> map or model for a civic or geodetic location. The catalog service
> would supply appropriate metadata, e.g., CRS, publication data, datum
> or "baseline location", etc. for the document.
Is a URI insufficient for this purpose?
It may be sufficient, if an application can determine whether this is a URI for a
data service, e.g., a OGC Web Map Service (WMS), or a catalog service, e.g., an
OGC Catalog Service (CSW). Regards,
Martin
> --
> Clifford Behrens, PhD
> Senior Scientist & Director
> Information Analysis
> Applied Research
> Telcordia Technologies, Inc.
> Phone: 732-699-2619
> FAX: 732-336-7015
> Email: cliff at
research.telcordia.com -- Clifford Behrens, PhD Senior Scientist & Director Information Analysis Applied Research Telcordia Technologies, Inc. Phone: 732-699-2619 FAX: 732-336-7015 Email: cliff@research.telcordia.com
