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

From: Cliff Behrens <[email-masked]>
Date: Wed, 07 Sep 2011 17:13:21 -0400

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:  [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Sep 2011 14:51:25 +0800

Hi Cliff,

I think that we've understood each other on most of the hard points.  Some responses inline.  I've been fairly brutal editing my response; let me know if you think I've missed something important.

On 2011-09-08 at 07:13:21, Cliff Behrens wrote:
> When is this URI added to the PIDF-LO, and how?  If the facility that 

The specifics of how the PIDF-LO is created is largely out of scope for the work that we are doing, but there's a general expectation that the document will be created by a machine.

In the most common cases, I imagine that there will be some sort of network service that creates the PIDF-LO.  Perhaps this a server somewhere in the local access network (a LIS in the nomenclature).  If you are talking about an office space in a building somewhere, then the local network administrator 

> I'm not suggesting that the IETF specify geospatial catalog services.
> 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.
> locations for these metadata.  I am thinking of "call before you dig"
> as an outdoor example.

That's an interesting example - you mean that you might want to consult the maps for water, electric, gas, etc...  all for the same location.  The great advantage of punting on this problem (which you do when you use a URI) is that people invent ways of dealing with limitations that far exceed your expectations.

Imagine that you could use HTTP content negotiation to retrieve different maps.  Or maybe the "map" is instead a reference to a catalogue.

> 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.

"All" sounds scary to me.
 
> 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?

It is implied rather than explicit.

> 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.

The shapes we use are fairly commonplace approximations.  In practice, a "localization technique" can produce a result that either fits the shape, or something that is quite inconvenient to represent.  In the latter case, some data is lost when a shape is fit to it.

> I guess that I imagined something like velocity being computed by 
> In other words, this struck me as derivative information.

Velocity can be measured in other ways.  For instance, the Doppler of a satellite signal can be used to get a (crude) estimate of velocity for a GPS receiver.

> 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?

That's a perpetual struggle.  There is always some application for more data, but adding data always has a cost.  Any representation (PIDF-LO included) represents a compromise.  In my limited experience, the IETF tends to be quite sensitive to complexity, because experience has shown that complexity has a lot of non-obvious costs.  That's one reason that generic pointers (e.g., the "map" URI) are favoured: you can get emergent complexity without necessarily burdening those who care little for your more complex applications.
 
> Interesting.  In fact, after reviewing 5491 I thought that 
> 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 range of technologies available for 
> automatic methods such as wire mapping, radio timing, and GPS."

Indeed.  The <method> element is a much-requested element that carries very little useful information.  It is provided, and it can be useful, but I've found that too much weight is attributed to the value.

> > The actual location is (Baseline ∩ Reference) + Relative.
>
> 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.

I don't know a lot about CityGML, but I'm happy to help you work out the implications.

One thing that I found helps: think of the reference location as establishing a new CRS (the location identifies 0,0,0 and the orientation of the axes).

> whether they could actually use a map document.

The only metadata we currently provide is the "type" attribute of the map.  That might be exactly what you are looking for, assuming of course that your BIM has a MIME media type (application/citygml+xml perhaps?).  A processor can use this as a hint about what the identified resource might be able to produce for them.

> 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?

That would be reasonable.  More likely, however, that the PIDF-LO is created at the time that you ask for one.  In the simplest case, the LIS identifies the WiFi access point you are attached to, works out where that access point is (using a database that might be cross-referenced to your BIM, though that depends entirely on your LIS implementation) and provides that information in the form(s) that it knows best.

If it knows where the access point is in WGS84 terms, then you might get that.  On the other hand, if it uses a local reference frame, then it uses the reference frame to populate the baseline/reference locations and provides your location based on that.

> choose from.  But might it be possible to use an existing standard if 
> one wanted to interoperate with other BIM users and providers?

Certainly.  Though when you choose a standard, you also choose a set of peers with which you will then interoperate.

I think that we covered all the hard questions. :)

--Martin

---

From: Cliff Behrens <[email-masked]>
Date: Thu, 08 Sep 2011 10:38:06 -0400

Brian,

This is very helpful.  So if I understand you correctly, one could use 
the location information in a PIDF-LO to build a query to a LoST server, 
and it would provide a pointer to the object one wanted, e.g., a 
floorplan or BIM.  This works for me, but seems so straightforward that 
it also makes me wonder why relative location information belongs in the 
PIDF-LO.  Why not merely use the services provided by LoST to get 
relative location and other information?

Most applications may not require BIMs, but some like CityGML provide 
enough detail that one should be able to derive many products, e.g., a 
floorplan, from them.  And there is an active group within the OGC, 
i.e., the IndoorML folks, who are working on a standard for representing 
navigation routes derived from CityGML.  As for information other than a 
BIM required for emergency services, some of it may actually be provided 
by references in the BIM.  For example, from the latest version (1.1.0) 
of the OGC® City Geography Markup Language (CityGML) Encoding Standard:

/3D objects are often derived from or have relations to objects in other 
databases or data sets. For example, a 3D
building model may have been constructed from a two-dimensional 
footprint in a cadastre data set, or may be
derived from an architectural model (Fig. 5). The reference of a 3D 
object to its corresponding object in an
external data set is essential, if an update must be propagated or if 
additional data is required, for example the
name and address of a building’s owner in a cadastral information system 
or information on antennas and doors
in a facility management system. In order to supply such information, 
each _CityObject may refer to external
data sets ... using the concept of ExternalReference. Such a reference 
denotes the external information system
and the unique identifier of the object in this system. Both are 
specified as a Uniform Resource Identifier (URI),
which is a generic format for references to any kind of resources on the 
internet. The generic concept of external
references allows for any _CityObject an arbitrary number of links to 
corresponding objects in external information
systems (e.g. ALKIS, ATKIS, OS MasterMap®, GDF, etc.)./

Thanks again for your input.

Cliff

On 9/7/2011 6:17 PM, Brian Rosen wrote:
> I'd like to comment on one aspect of this.
>
> In the North American 9-1-1 system, there is a way to pass a BIM to 
> the PSAP (9-1-1 call center).   We call that "Additional Data 
> associated with a location".  The notion is that the information in 
> the BIM is not tied to a PIDF, it's tied to the location the PIDF 
> refers to.  The mechanism used for this is LoST (RFC5222).  You query 
> a LoST server with the location and a designated service URN, and you 
> get back a URI to an XML data structure, which includes a pointer to a 
> BIM.
>
> This isn't the map referred to here, and I think the generic notion 
> that a large variety of applications will be able to use a BIM to 
> create some kind of useful (to a user) map, along with relative 
> location, seems unlikely, but possible.  Instead, I think there will 
> be much simpler maps that have more immediate use than a BIM.
>
> Emergency services on the other hand would appreciate an accurate BIM, 
> although they need more than the BIM.
>
> Brian
>
> On Sep 7, 2011, at 5:13 PM, Cliff Behrens wrote
>
>> Martin,
>>
>> 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
>> 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
>> 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.  
>> object, e.g., BIM, to get it./
>>
>> 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.
>>
>> 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./
>>
>> /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
>> >
>> "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./
>>
>> > Shouldn’t this be data or metadata either stored with the referenced
>> 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 
>> 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?/
>>
>> > If one were to determine location in this manner, then wouldn’t it be
>> 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.
>>
>> 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.)
>>
>> Application Schema for use by the Internet Engineering Task Force (IETF):
>>
>> Relative and need to only see the Baseline.  Because the (Baseline ∩ 
>> In practice, this is only really useful for Civic Addresses, where 
>> the intersect operation has a hope of working.
>> /
>> and reference locations in a CityGML model./
>>
>> > and reference locations MAY also include dynamic location 
>> information [RFC5962].
>> >
>> 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./
>>
>> > Seems a red-herring if you don’t quantify it.  Again, this might be
>> /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
>> As you please.  As long as you have a MIME media type for your BIM 
>> you can use it.
>>
>> /Yep./
>>
>> > Again, wouldn’t this alignment best be made with metadata stored with
>> > driven by an application, then can’t it also get the metadata for the
>> 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
>> > It shouldn’t have to.  It should only provide the URI to the
>> 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>
>> >
>> > Isn’t “elevation” a better term since it refers to height above geoid
>> understood.  We are fairly careful when defining how the Cartesian 
>> space is defined, but if that is not clear enough, please let us know.
>>
>> > Not sure this makes sense.  Shouldn’t the baseline location, at least,
>> That's only true if the building is stationary, or your reference 
>> point is a building.
>>
>> /Got it./
>>
>> > Don’t see where uncertainty value is provided in the example below
>> > (i.e., 4.9.2.1).
>>
>> Look for <gs:radius>.
>>
>> > Why doesn’t this shape also have associated with it an uncertainty
>> > or “baseline location”, etc. for the document.
>>
>> /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
>> > Email:  cliff at research.telcordia.com <http://research.telcordia.com>
>> -- 
>> Clifford Behrens, PhD
>> Email:[email-masked]
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Cliff Behrens <[email-masked]>
Date: Thu, 08 Sep 2011 12:49:36 -0400

Martin,

Not so brutal, really. My thoughts are copied inline.

Cliff

> The specifics of how the PIDF-LO is created is largely out of scope for the work that we are doing, but there's a general expectation that the document will be created by a machine.
What I am trying to imagine is how a PIDF-LO might evolve and certain
dependencies that its content entails. For example, a location value
assumes the existence of some localization technique, which in turn
assumes a spatial context. In the case of WiFi localization this might
involve search of a database of signal strength signatures sampled at
spatially-referenced grid points in a building, i.e., one kind of map.
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?
> Imagine that you could use HTTP content negotiation to retrieve different maps.  Or maybe the "map" is instead a reference to a catalogue.
I just want to determine whether a map object exists for a location. I
think that Brian provided a means to do this using LoST. As for finding
other map data layers, its seems to me that location provided in a
PIDF-LO could be used to query other spatial databases, or one might
exploit information referenced in the map or data object itself, e.g.,
as provided in CityGML.

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?
> "All" sounds scary to me.
In this case, "all" was used in the context of providing derived
information in the
PIDF-LO, e.g, uncertainty and relative location information.
> It is implied rather than explicit.
So why not make it explicit in the current draft?
> Velocity can be measured in other ways.  For instance, the Doppler of a satellite signal can be used to get a (crude) estimate of velocity for a GPS receiver.
OK...but strikes me as the kind of application-specific complexity you
caution against below. If velocity, then why not acceleration, etc.?
> The only metadata we currently provide is the "type" attribute of the map.  That might be exactly what you are looking for, assuming of course that your BIM has a MIME media type (application/cityg…
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.
> If it knows where the access point is in WGS84 terms, then you might get that.  On the other hand, if it uses a local reference frame, then it uses the reference frame to populate the baseline/refe…
OK...this sounds doable.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Sep 2011 15:15:00 +0800

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.

> [...] 
> 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 

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.

> 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.

> > Velocity [...]

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.

---

From: Cliff Behrens <[email-masked]>
Date: Fri, 09 Sep 2011 11:14:21 -0400

On 9/8/2011 9:52 PM, Brian Rosen wrote:
> You need location to query the LoST server, so you can't get location 
> (of any kind) from the LoST server.
Understood.  I was thinking that one could use the location reported in 
a PIDF-LO, e.g., a geodetic location, to query LoST for a map or map 
catalog service (but see next comment).
>
> LoST is a Location to Service Translation protocol.  You send location 
> and the kind of service you want to the server, and it sends you a URI 
> to the service back.  We use it for emergency calling = which 
> emergency call center (PSAP) serves a given location.  Location plus 
> service (urn:service:sos) in, URI to PSAP out.
>
> So you could send LoST a relative location, but you can't get relative 
> location from LoST.
After taking a look at RFC5222 I came to realize that LoST really only 
registers human services, not IT services.  So maybe the easiest way to 
do this would be to use PIDF-LO location, e.g., a geodetic location, to 
query a geospatial catalog for a "map doc," e.g., a floorplan or BIM.  
As I mentioned in an earlier exchange, there already exist standards for 
coding geospatial metadata and for building catalog services with it.  
With this object, and location provided by a localization technique, I 
could then determine relative location, compute indoor routes, and many 
other things.  Or, I might merely want to pass the URI for this object 
to another service by putting it in the PIDF-LO.
>
> Otherwise, yes, it's simple.  That's why we did it that way :)
>
> Brian
>
> On Sep 8, 2011, at 10:38 AM, Cliff Behrens wrote:
>
>> Brian,
>>
>> This is very helpful.  So if I understand you correctly, one could 
>> use the location information in a PIDF-LO to build a query to a LoST 
>> server, and it would provide a pointer to the object one wanted, 
>> e.g., a floorplan or BIM.  This works for me, but seems so 
>> straightforward that it also makes me wonder why relative location 
>> information belongs in the PIDF-LO.  Why not merely use the services 
>> provided by LoST to get relative location and other information?
>>
>> enough detail that one should be able to derive many products, e.g., 
>> a floorplan, from them.  And there is an active group within the OGC, 
>> i.e., the IndoorML folks, who are working on a standard for 
>> representing navigation routes derived from CityGML.  As for 
>> information other than a BIM required for emergency services, some of 
>> it may actually be provided by references in the BIM.  For example, 
>> from the latest version (1.1.0) of the OGC® City Geography Markup 
>> Language (CityGML) Encoding Standard:
>>
>> /3D objects are often derived from or have relations to objects in 
>> other databases or data sets. For example, a 3D
>> name and address of a building’s owner in a cadastral information 
>> system or information on antennas and doors
>> data sets ... using the concept of ExternalReference. Such a 
>> reference denotes the external information system
>> which is a generic format for references to any kind of resources on 
>> the internet. The generic concept of external
>>> refers to.  The mechanism used for this is LoST (RFC5222).  You 
>>> query a LoST server with the location and a designated service URN, 
>>> and you get back a URI to an XML data structure, which includes a 
>>> pointer to a BIM.
>>>
>>> Emergency services on the other hand would appreciate an accurate 
>>> BIM, although they need more than the BIM.
>>>
>>> Brian
>>>
>>>> Thanks for this clarification.  I have responded using italics 
>>>> inline below.
>>>>
>>>> Cliff
>>>>
>>>> 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.
>>>>
>>>> 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
>>>> 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
>>>> 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.
>>>>
>>>> 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./
>>>>
>>>> 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 
>>>> 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./
>>>>
>>>> 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.
>>>>
>>>> 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
>>>> >
>>>> 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./
>>>>
>>>> (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 
>>>> 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, 
>>>> particularly the type of access network, the LG can use any number 
>>>> of methods to determine LI. The range of technologies available for 
>>>> Relative and need to only see the Baseline.  Because the (Baseline 
>>>> ∩ Reference) might identify a very specific location - one that is 
>>>> /My problem with this had to do with the fact that a placeholder 
>>>> was created for uncertainty, but it didn't appear that
>>>> required to create this association, and whether some co-location 
>>>> or "shared context" is required for these.  For example, when I enter
>>>> /Yes, some images, e.g., GeoTIFF, have spatial reference 
>>>> information in their header, while other don't.  A GIS or CAD 
>>>> catalog could also
>>>> 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/
>>>>
>>>> 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?/
>>>>
>>>> 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>
>>>> >
>>>> 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.
>>>>
>>>> /My comment regarding this point and the one below had to do with 
>>>> the fact that I
>>>> I think that we use very different definitions for uncertainty.  
>>>> See above.  The same applies to your comments (20, 21).
>>>>
>>>> <http://research.telcordia.com/>
>>>> -- 
>>>> Clifford Behrens, PhD

---

From: Cliff Behrens <[email-masked]>
Date: Fri, 09 Sep 2011 15:12:25 -0400

On 9/9/2011 3:15 AM, Thomson, Martin wrote:
> 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.
> 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 a…
Yeah...I too am now thinking along these lines.
> 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 w…

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?

> 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 
PIDF-LO.