From rjsparks@nostrum.com Mon Aug 1 07:24:10 2011 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E727921F8E7D for ; Mon, 1 Aug 2011 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuAcPYak+z36 for ; Mon, 1 Aug 2011 07:24:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D821F8E7C for ; Mon, 1 Aug 2011 07:24:09 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p71EOEpI034472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Aug 2011 09:24:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-215-1041488964 Date: Mon, 1 Aug 2011 09:24:14 -0500 References: <1CD4A8C5-37F1-43F7-ABE7-6BAD6399AD95@w3.org> To: GEOPRIV Message-Id: <1A2071AF-927B-4201-ADB6-25CE3035C6FF@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Geopriv] Fwd: [new-work] Proposed W3C Charters: Tracking Protection Working Group, Privacy Interest Group (until 2011-08-29) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:24:11 -0000 --Apple-Mail-215-1041488964 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi Begin forwarded message: > From: Ian Jacobs > Date: August 1, 2011 8:39:35 AM CDT > To: new-work@ietf.org > Subject: [new-work] Proposed W3C Charters: Tracking Protection Working = Group, Privacy Interest Group (until 2011-08-29) >=20 > Hello, >=20 > Today W3C Advisory Committee Representatives received a Proposal to = revise the Privacy Activity [0] (see the W3C Process Document = description of Activity Proposals [1]). This proposal includes draft = charters for two groups: >=20 > Tracking Protection Working Group=20 > http://www.w3.org/2011/tracking-protection/charter-draft=20 >=20 > Privacy Interest Group: > http://www.w3.org/2011/07/privacy-ig-charter >=20 > As part of ensuring that the community is aware of proposed work at = W3C, this draft charter is public during the Advisory Committee review = period. >=20 > W3C invites public comments through 2011-08-29 on the proposed = charter. Please send comments to public-new-work@w3.org, which has a = public archive:=20 > http://lists.w3.org/Archives/Public/public-new-work/ >=20 > Other than comments sent in formal responses by W3C Advisory Committee = Representatives, W3C cannot guarantee a response to comments. If you = work for a W3C Member [2], please coordinate your comments with your = Advisory Committee Representative. For example, you may wish to make = public comments via this list and have your Advisory Committee = Representative refer to it from his or her formal review comments. >=20 > If you should have any questions or need further information, please = contact Nick Doty, Privacy Analyst . >=20 > Thank you, >=20 > Ian Jacobs, Head of W3C Communications >=20 > [0] http://www.w3.org/Privacy/Activity > [1] > http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation > [2] http://www.w3.org/Consortium/Member/List >=20 > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 >=20 > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work --Apple-Mail-215-1041488964 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Ian Jacobs <ij@w3.org>
Date: August 1, 2011 = 8:39:35 AM CDT
Subject: [new-work] = Proposed W3C Charters: Tracking Protection Working Group, Privacy = Interest Group (until = 2011-08-29)

Hello,

Today W3C = Advisory Committee Representatives received a Proposal to revise the = Privacy Activity [0] (see the W3C Process Document description of = Activity Proposals [1]). This proposal includes draft charters for two = groups:

 Tracking Protection Working Group
 http://w= ww.w3.org/2011/tracking-protection/charter-draft

=  Privacy Interest Group:
 http://www.w3.org/20= 11/07/privacy-ig-charter

As part of ensuring that the = community is aware of proposed work at W3C, this draft charter is public = during the Advisory Committee review period.

W3C invites public = comments through 2011-08-29 on the proposed charter. Please send = comments to public-new-work@w3.org, which = has a public archive:
 http://lists= .w3.org/Archives/Public/public-new-work/

Other than comments = sent in formal responses by W3C Advisory Committee Representatives, W3C = cannot guarantee a response to comments. If you work for a W3C Member = [2], please coordinate your comments with your Advisory Committee = Representative. For example, you may wish to make public comments via = this list and have your Advisory Committee Representative refer to it = from his or her formal review comments.

If you should have any = questions or need further information, please contact Nick Doty, Privacy = Analyst <npdoty@w3.org>.

Thank = you,

Ian Jacobs, Head of W3C Communications

[0] http://www.w3.org/Privacy/Acti= vity
[1]
http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreati= on
[2] http://www.w3.org/Consortium/Member/List

--
Ian = Jacobs (ij@w3.org) =    http://www.w3.org/People/Jacobs/
Tel: =             &n= bsp;           &nbs= p;            = +1 718 260 = 9447

_______________________________________________
new-work = mailing = list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-wor= k

= --Apple-Mail-215-1041488964-- From rjsparks@nostrum.com Thu Aug 4 12:12:07 2011 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6A21F87F0; Thu, 4 Aug 2011 12:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OARj2LQOCc5; Thu, 4 Aug 2011 12:12:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A49DA21F88B7; Thu, 4 Aug 2011 12:12:05 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p74JCJPi082324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 14:12:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-21--829509233 Date: Thu, 4 Aug 2011 14:12:19 -0500 Message-Id: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> To: ecrit@ietf.org, GEOPRIV Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) Subject: [Geopriv] Verifying errata 2511 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ecrit@ietf.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:12:07 -0000 --Apple-Mail-21--829509233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (note the crosspost - please reply only to ecrit@ietf.org) Please see and thread on the Ecrit list titled Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service = Translation Protocol) which started Nov 23, 2010. Given the subsequent discussion of draft-ietf-geopriv-local-civic, I = plan to mark this errata as Verified. If you don't think this is the correct thing to do, please let = me know ASAP. If there are no replies, I will verify that errata next Thursday (11Aug)= --Apple-Mail-21--829509233 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
(note the crosspost - please reply only to ecrit@ietf.org)

Please see <http://www.rfc-editor.org/errata_search.php?eid=2511>
and thread on the Ecrit list titled

Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol)

which started Nov 23, 2010.

Given the subsequent discussion of draft-ietf-geopriv-local-civic, I plan to mark this errata as
Verified. If you don't think this is the correct thing to do, please let me know ASAP. If there are no
replies, I will verify that errata next Thursday (11Aug)
--Apple-Mail-21--829509233-- From rbarnes@bbn.com Tue Aug 16 13:37:03 2011 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9B11E80AB for ; Tue, 16 Aug 2011 13:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNUA1A8ok0O4 for ; Tue, 16 Aug 2011 13:37:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 43D1311E808F for ; Tue, 16 Aug 2011 13:37:03 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:62349) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtQOW-0006pA-2i for geopriv@ietf.org; Tue, 16 Aug 2011 16:37:52 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2011 16:37:51 -0400 References: <20110812152329.25815.3338.idtracker@ietfa.amsl.com> To: GEOPRIV WG Message-Id: <4BEF2348-C5F4-45B9-B0DA-004CB1F581C2@bbn.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] Fwd: Last Call: (Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions) to Proposed Standard X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:37:03 -0000 FYI, may be of interest to some here. --Richard Begin forwarded message: > From: The IESG > Date: August 12, 2011 11:23:29 AM EDT > To: IETF-Announce > Cc: grow@ietf.org > Subject: Last Call: (Multi-threaded = Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information = export format with geo-location extensions) to Proposed Standard > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the Global Routing Operations WG > (grow) to consider the following document: > - 'Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) > routing information export format with geo-location extensions' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document updates the Multi-threaded Routing Toolkit (MRT) = export > format for Border Gateway Protocol (BGP) routing information by > extending it to include optional terrestrial coordinates of a BGP > Collector and its BGP Peers. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From cliff@research.telcordia.com Fri Aug 26 10:20:55 2011 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3734F21F8515 for ; Fri, 26 Aug 2011 10:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Za3+j0Olo9S for ; Fri, 26 Aug 2011 10:20:48 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4401821F844C for ; Fri, 26 Aug 2011 10:20:40 -0700 (PDT) Received: from [127.0.0.1] (vpntnlA198.research.telcordia.com [128.96.58.198]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p7QHLt59013672 for ; Fri, 26 Aug 2011 13:21:56 -0400 (EDT) Message-ID: <4E57D633.4020200@research.telcordia.com> Date: Fri, 26 Aug 2011 13:21:55 -0400 From: Cliff Behrens User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: geopriv@ietf.org Content-Type: multipart/alternative; boundary="------------070704090505070505090905" Subject: [Geopriv] Latest on draft-ietf-geopriv-relative-location-01.txt? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:20:55 -0000 This is a multi-part message in MIME format. --------------070704090505070505090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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) http://example.com/location/map.png 20. 120. 29. 20. -20. 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 element. The coordinate system also moves as described by the and 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 --------------070704090505070505090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------070704090505070505090905-- From Martin.Thomson@commscope.com Mon Aug 29 00:37:43 2011 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F6921F89CC for ; Mon, 29 Aug 2011 00:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_50=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzt-MJtM+Vb7 for ; Mon, 29 Aug 2011 00:37:41 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB921F8829 for ; Mon, 29 Aug 2011 00:37:41 -0700 (PDT) X-AuditID: 0a0404e8-b7c4dae000001396-94-4e5b42186b0d Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 57.62.05014.8124B5E4; Mon, 29 Aug 2011 02:39:04 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 29 Aug 2011 02:39:04 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 29 Aug 2011 02:39:03 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 29 Aug 2011 15:39:01 +0800 From: "Thomson, Martin" To: Cliff Behrens , "geopriv@ietf.org" Date: Mon, 29 Aug 2011 15:39:18 +0800 Thread-Topic: [Geopriv] Latest on draft-ietf-geopriv-relative-location-01.txt? Thread-Index: AcxkFLnlLjdLxeuXQrC5hB3o1YfqBACASoiA Message-ID: <8B0A9FCBB9832F43971E38010638454F040F1C1179@SISPE7MB1.commscope.com> References: <4E57D633.4020200@research.telcordia.com> In-Reply-To: <4E57D633.4020200@research.telcordia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Geopriv] Latest on draft-ietf-geopriv-relative-location-01.txt? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 07:37:43 -0000 Hi Cliff, Thanks for taking the time to look at this. On 2011-08-27 at 03:21:55, Cliff Behrens wrote: > All, >=20 > 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=20 > 28, but there has been no follow-on activity or discussion related to=20 > it. We're still expecting an updated version. =20 > I would be happy to pick-up this thread, if it is proper for me to do=20 > so, not having any previous involvement with this group. =20 Please do. Fresh eyes are always welcome. And valuable. > I guess what still seems most mysterious to me at this point is how=20 > (and > when) a target location is placed in the context of a World Coordinate=20 > Reference System. I suppose the map document reference used for this=20 > could be put in the PIDF-LO by the localization application, assuming=20 > that all of this was planned in advance. But I wonder about the case=20 > where a team must respond to an address for an emergency, so must=20 > discover whether a map document or BIM exists for it, along with the=20 > method of localization used (if one exists). Discovery shouldn't really be necessary - the document includes the means t= o provide a link (URI) to a map or BIM resource. We haven't nailed down ex= actly what it is that is identified by the URI, simply because we haven't s= een any clear indications that any one solution is going to be chosen. > In other words, it seems=20 > like search of a catalog or registry might be required.=20 I for one, am against the building of a catalogue. I suspect that such a t= hing would be outside the IETF's remit. > In either=20 > case, I think that instantiation of a PIDF-LO requires localization=20 > and contextualization applications that retrieve information and=20 > perform computations with it, and while these applications are=20 > implicit in the current draft, I'm not sure that the PIDF-LO as=20 > specified facilitates this data flow. Is it others' understanding=20 > that the secondary map data/metadata would be provided by the localizatio= n service? See above - the 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 disag= ree. > 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=20 > measure of location uncertainty in the PIDF-LO, then you should either=20 > provide the shape and the location of its boundary for an agreed-on=20 > uncertainty value (e.g., 5% error), or provide a shape (and the=20 > location of its > boundary) with its uncertainty value. We use the term "confidence" when referring to probabilities of that sort. = =20 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. > However, if all you are trying=20 > to convey is that a target is located somewhere within a space bounded=20 > by well-known building features, e.g., an office, presumably the=20 > coordinates of the boundary would be derived from a map document,=20 > e.g., a floorplan or BIM, and these would convey location uncertainty,=20 > e.g., I am only certain that Joe is in the main conference room but I=20 > can't tell you exactly where he is in it. How is that distinction important? Whether I am uncertain about the locati= on or whether you are uncertain about the location ultimately makes little = difference if you are the consumer of the location information. > Section 1 >=20 > (1) The reference location can also have dynamic components such as=20 > velocity. The relative offset is specified in meters using a=20 > Cartesian coordinate system. >=20 > Does this belong in the object? If so, should it have orientation=20 > (and in Cartesian coordinates)? Does this make sense indoors? Yes. Depends on your "indoors". Think of a cruise ship or any other "buil= ding" that moves. It's actually a case where relative location is most use= ful. > (2) Applications could use this information to display the relative=20 > location. Additional fields allow the map to be oriented and scaled=20 > correctly. >=20 > Shouldn=1B$B!G=1B(Bt this be data or metadata either stored with the refe= renced=20 > document or in a catalog that references it? Catalogue? Yes, this is metadata, but we don't have the luxury of a consistent and con= trolled context into which we can reliably place such metadata. Thus, we p= opulate the object with metadata. See also: usage rules for location objec= ts, timestamps, method, etc... > (3) ...and the reference location could specify a point within the=20 > building from which the offset is measured. >=20 > If one were to determine location in this manner, then wouldn=1B$B!G=1B(B= t it be=20 > desirable to also specify how localization was determined and its=20 > accuracy? (See localization generator or LG in GML 3.1.1 PIDF-LO=20 > 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 wa= s not considered important enough to warrant the added complexity. (As an aside, the idea that you can concisely state _how_ location is gener= ated is - in my opinion - a poor idea. Whenever someone asks how, either n= ot answering or answering "magic" is the best way to handle it. With anyth= ing more specific, you run the risk of a recipient inferring things - and I= 've learned that such inferences have a dangerously high probability of bei= ng wrong. For instance, if I tell you that I determined where you are base= d 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.) =20 > (4) The baseline location SHOULD be general enough to describe both=20 > the reference location and the relative location (reference plus=20 > offset). > In particular, ....., etc. >=20 > This is kind of murky...a figure would help. Agreed. Here's how it works: Relative Location =3D { Baseline, Reference, Relative } The actual location is (Baseline =1B$B"A=1B(B Reference) + Relative. The reason is that old recipients don't understand Reference and Relative a= nd need to only see the Baseline. Because the (Baseline =1B$B"A=1B(B Refer= ence) might identify a very specific location - one that is potentially ver= y wrong - we needed to ensure that they only saw something very general. In practice, this is only really useful for Civic Addresses, where the inte= rsect operation has a hope of working. > (5) If the baseline location was expressed as a geodetic location,=20 > the reference MUST be geodetic. If the baseline location was=20 > expressed as a civic address, the reference MUST be a civic. Baseline=20 > and reference locations MAY also include dynamic location information [RF= C5962]. >=20 > Seems this constraint is unnecessary if a detailed BIM were obtained=20 > for a civic address, and then used to determine geodetic locations=20 > from BIM > + localization. Why would the baseline location ever change? Yeah, but in order to have that interoperate, we'd also have to specify whi= ch 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, bu= t please don't expect someone random on the Internet to be able to use the = BIM. =20 > (6) The relative location can be expressed using a point (2- or 3-=20 > dimensional), or a shape that includes uncertainty: circle, sphere,=20 > ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of these=20 > shapes can be found in [RFC5491]. >=20 > Seems a red-herring if you don=1B$B!G=1B(Bt quantify it. Again, this mig= ht be=20 > determined based on localization technique. Does not parse. Perhaps it's a nomenclature problem. > (7) Optionally, a reference to a 'map' document can be provided. The=20 > reference is a URI. >=20 > How/when is this association made? Outside of the confines of a protocol specification, by someone who knows (= or works out) that link. =20 > (8) The document could be an image or dataset that represents a map,=20 > floorplan or other form. The type of document the URI points to is=20 > described as a MIME media type. >=20 > Including a CityGML BIM.gml. As you please. As long as you have a MIME media type for your BIM you can = use it. > (9) Metadata in the relative location can include the location of the=20 > 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. >=20 > Again, wouldn=1B$B!G=1B(Bt this alignment best be made with metadata stor= ed with=20 > the referenced document? If all of this look-up and alignment is=20 > driven by an application, then can=1B$B!G=1B(Bt it also get the metadata = for the=20 > document and use these to align it and locate the reference point in=20 > 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 docu= ment might include metadata that overrides these values). > (10) The document is assumed to be useable by the application=20 > receiving the PIDF with the relative location to locate the reference=20 > point in the map. This document does not describe any mechanisms for=20 > displaying or manipulating the document other than providing the=20 > reference location, orientation and scale. >=20 > It shouldn=1B$B!G=1B(Bt have to. It should only provide the URI to the=20 > application which uses the PIDF-LO. Agreed. But we'd like to make that very clear. Clear scope is very import= ant in a specification like this. People have all sorts of unreasonable ex= pectations. > (11) xmlns:gp=3D"urn:ietf:params:xml:ns:pidf:geopriv10" >=20 > This needed for localization or Location Geneator? RFC 4119 defines this structure.=20 =20 > (12) xmlns:ca=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >=20 > Why is IETF using own specification for civic addresses rather than=20 > OASIS xNAL standard, as used by OGC? http://www.xkcd.com/927/ > (13) xmlns:gs=3D"http://www.opengis.net/pidflo/1.0" > >=20 > Is all of this still relevant given revisions to this draft? Indeed, still relevant. > (14) ... > >=20 > I can well imagine a use case where all of this is discovered through=20 > an application using civic or geodetic address and knowledge of LG. Absolutely. The map is optional. > Datum, baseline location, reference location, relative location...need=20 > to be more carefully defined and distinguished, along with the=20 > implications for each when applied to civic and geodetic addresses. > Isn=1B$B!G=1B(Bt =1B$B!H=1B(Belevation=1B$B!I=1B(B a better term since it= refers to height above geoid=20 > (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. 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 i= s altitude. > (16) Dynamic location information [RFC5962] in the baseline or=20 > reference location alters relative coordinate system. The resulting=20 > Cartesian coordinate system axes are rotated so that the 'y' axis is=20 > oriented along the direction described by the element. > The coordinate system also moves as described by the and=20 > elements. >=20 > Not sure this makes sense. Shouldn=1B$B!G=1B(Bt the baseline location, a= t least,=20 > remain fixed since it may be the only datum stored for a building=20 > through which one can associate WRS and LCS? That's only true if the building is stationary, or your reference point is = a building. > (17) Shape data is used to represent regions of uncertainty for the=20 > reference and relative locations. Shape data in the reference=20 > location uses a WGS84 [WGS84] CRS. Shape data in the relative=20 > location uses a relative CRS. >=20 > This makes little sense unless either (a) an uncertainty value is used=20 > to compute a shape, or (b) an uncertainty measure is provided for a=20 > shape. Otherwise, if a shape is used to provide an approximate=20 > location for a target, e.g., somewhere in an office room, then=20 > presumably a floorplan or BIM (with the proper shape and coordinate > values) would be used to provide the geospatial context for target=20 > location. RFC 5491 describes the term "shape" as it is used in this context. =20 > (18) A circle or sphere describes a single point with a single=20 > uncertainty value in meters. >=20 > Don=1B$B!G=1B(Bt see where uncertainty value is provided in the example b= elow=20 > (i.e., 4.9.2.1). Look for . =20 > (19) A ellipse or ellipsoid describes a point with an elliptical or=20 > ellipsoidal uncertainty region. >=20 > Why doesn=1B$B!G=1B(Bt this shape also have associated with it an uncerta= inty=20 > value (like the circle), especially if this is the reason for=20 > 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=20 > databases, or any other form of representation understood by both the=20 > sender and recipient. >=20 > I would include a BIM, e.g., a CityGML model, in this list of=20 > representations. As implied by the statement, you are free to use any map form that you like= . > But how is this reference added to the PIDF-LO? I=20 > would also like to provide a link to a catalog service that provides a=20 > map or model for a civic or geodetic location. The catalog service=20 > would supply appropriate metadata, e.g., CRS, publication data, datum=20 > or =1B$B!H=1B(Bbaseline location=1B$B!I=1B(B, etc. for the document. Is a URI insufficient for this purpose? 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@research.telcordia.com