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.
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. I will be
attending the OGC CityGML SWG in Sept., so was hoping to learn more
about how they are modeling relative location with the objective of
using some of their thinking to inform the specification of relative
location in PIDF-LO. Guess what I am struggling with a bit at the
moment is how much information is proper for the PIDF-LO, and how much
should be provided by services referenced in the object.
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). In other words, it seems
like search of a catalog or registry might be required. 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?
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. 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.
At any rate, I have provided more detailed comments below to 22
excerpts, referenced by section in the current draft. I would gladly
engage others in clarifying these points, and would be happy to talk to
people at the OGC meetings in Sept. about any questions or outstanding
issues related to this draft.
Regards,
Cliff Behrens
=============== Comments Follow Below
===============================================
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?
(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?
Section 3
(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.)
(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.
(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?
(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.
(7) Optionally, a reference to a 'map' document can be provided. The
reference is a URI.
How/when is this association made?
(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.
(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?
(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.
(11) xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
This needed for localization or Location Geneator?
(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?
(13) xmlns:gs="http://www.opengis.net/pidflo/1.0"
Is all of this still relevant given revisions to this draft?
(14) <rel:map>
<rel:url type="image/png">
http://example.com/location/map.png
</rel:url>
<rel:offset>20. 120.</rel:offset>
<rel:orientation>29.</rel:orientation>
<rel:scale>20. -20.</rel:scale>
</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.
Section 4
(15) Relative location is a shape (point, circle, ellipse...). The
shape is defined with a CRS that has a datum defined as the reference
(which appears as a civic address or geodetic location in the tuple),
and the shape coordinates as meter offsets North/East of the datum
measured in meters (with an optional Z offset relative to datum
altitude). An optional angle allows the reference CRS be to rotated
with respect to North.
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?
4.2
(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?
4.9
(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.
4.9.2
(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).
4.9.3
(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?
4.9.4
(20) A polygon or prism include a number of points that describe the
outer boundary of an uncertainty region.
...and what is its value?
4.9.5
(21) A arc-band describes a region constrained by a range of angles and
distances from a predetermined point. This shape can only be provided
for a two-dimensional CRS.
Why is uncertainty not a property of this shape?
4.10
(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. 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.
-- 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Fri, 26 Aug 2011 13:21:55 -0400
This archive was generated by hypermail 2.1.8 : Fri Aug 26 2011 - 13:22:39 EDT
