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

From: Cliff Behrens ^lt;cliff@research.telcordia.com>
Date: Fri Sep 09 2011 - 11:14:21 EDT

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?
>>
>> 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,
>>>>
>>>> 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
>>>> <http://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
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> Geopriv@ietf.org <mailto:Geopriv@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>>
>> --
>> 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
>

-- 
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, 09 Sep 2011 11:14:21 -0400

This archive was generated by hypermail 2.1.8 : Fri Sep 09 2011 - 11:22:08 EDT