Subject: [Geopriv] Fwd: I-D Action:draft-marjou-geopriv-avt-geoloc-00.txt

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 26 Jun 2008 10:32:29 +0200

For information, I've just submitted a new draft about transporting
GPS-like data in RTP. Though the final target is the AVT working
group, I think that the first discussions should be done in the
GEOPRIV WG.

Cheers,
Xavier

-----Message d'origine-----
De : [email-masked]
[mailto:[email-masked]] De la part de
[email-masked]
Envoyé : jeudi 26 juin 2008 09:15
À : [email-masked]
Objet : I-D Action:draft-marjou-geopriv-avt-geoloc-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : RTP Payload Format for Geographical Location.
       Author(s)       : X. Marjou, J. Jestin
       Filename        : draft-marjou-geopriv-avt-geoloc-00.txt
       Pages           : 10
       Date            : 2008-06-26

This memo presents some use-cases and requirements related to the
real-time transport of geographical location information.  It also
defines a Real-time Transport Protocol (RTP) packet payload format to
carry real-time geographical location information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-marjou-geopriv-avt-geoloc-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Thu, 26 Jun 2008 14:03:16 -0400

Hi Xavier,

Thanks for letting us know about this draft.

My first question is what the motivating use case is for this draft? 
What are the locations that are being conveyed?  (And why would you need 
1000 per second?)

Also, given that there are several existing formats for location 
information, it shouldn't be necessary for this document to create a new 
one.  My suggestion is:
1. If you want to convey raw location information, use the Geospatial 
Markup Language (GML) format [1], and
2. If you want to convey location information that is tied to an 
identity, use the PIDF-LO format [2].

--Richard

[1] <http://portal.opengeospatial.org/files/?artifact_id=4700>
[2] RFC 4119 <http://tools.ietf.org/html/rfc4119>

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 26 Jun 2008 16:01:23 -0600

Xavier -

Just did a quick read of the document.

Several suggestions and comments and observations. The majority of my 
comments have to do with consistency of expression of terms as well as 
alignment of the point geometry information model with other industry work.

1. Minor change suggestion, but KML 2.2 is now an OGC standard and should be 
referenced as such. Google has turned over all IPR related to KML to the OGC 
so that KML can be an international open standard. However, you are spot on 
in terms of the intended use cases for KML.

2. Comment: PIDF-LO - geodetic - references an OGC Geography Markup Language 
(GML) application schema. GML is also an ISO standard. The GML Geometry 
model is grounded in ISO 19107 - Features

3. As an observation, the KML geometry model is based on GML 2.1.1, although 
Keyhole changed the coordinate order to long-lat. Coordinate order in GML is 
defined by the coordinate reference system (CRS) being used.

4. Comment: So, your document does need to define the CRS. I would suggest 
the following (From the PIDF-LO GML application schema):

A coordinate reference system (CRS) specifies how coordinates are 
interpreted. For the point geometry defined in this document, the default is 
either the two- and three-dimensional WGS84 coordinate reference systems 
(latitude, longitude, and perhaps altitude). The parameters for these CRS 
are documented in the European Petroleum Survey Group (EPSG) Geodetic 
Parameter Dataset entries:

  a.. 3D: WGS 84 (latitude, longitude, altitude), as identified by the URN 
urn:ogc:def:crs:EPSG::4979. This is a three dimensional CRS.
  b.. 2D: WGS 84 (latitude, longitude), as identified by the URN 
urn:ogc:def:crs:EPSG::4326. This is a two dimensional CRS.
Of course, you will not be using URNs in RTP. But the essense of the 
required wording is in the above. Also, please note, that axis order (also 
known as coordinate order) is specified by the EPSG entries for 4979 and 
4326 (2d = lat, long and 3d = lat, long, altitude). I would also look at the 
location extension to DHCP for additional guidance and harmonization. I 
mention DHCP because it is also a binary format.

5. Have you looked at GeoRSS? www.georss.org . GeoRSS has become the defacto 
standard for expressing location as a component of an RSS feed. There is an 
information model which (surprise) is also grounded in ISO 19107. There is 
GeoRSS simple and GeoRSS GML. The latter has been implemented by a number of 
vendors (Google, Microsoft, ESRI, others) and numerous aggregators.

The main reason for all of my comments is that we should use a consistent 
approach that is aligned with all the existing work in the IETF, the OGC and 
other organizations. This consistent approach is the information model. 
Interestingly enough, from an info model perspective, PIDF-LO geodetic, KML, 
GML, GeoRSS, and even DHCP are well aligned.

Hope this helps!

Regards

Carl Reed
CTO
OGC

---

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 27 Jun 2008 11:13:11 +0200

On Thu, Jun 26, 2008 at 8:03 PM, Richard Barnes <[email-masked]> wrote:
> My first question is what the motivating use case is for this draft? What
> are the locations that are being conveyed?  (And why would you need 1000 per
> second?)

The motivating use case is similar to what's written in the draft: to
be able to have a multimedia session between two users, which is made
of different media (audio, video, and GPS coordinates). GPS data needs
to be transmitted several times per minute, but not 1000 per second.
1000 is the RTP clock rate: we took this value as a value below 1000
is not recommended in RTP.

> 1. If you want to convey raw location information, use the Geospatial Markup
> Language (GML) format [1], and
> 2. If you want to convey location information that is tied to an identity,
> use the PIDF-LO format [2].

With regards to the current requirements, GML or PIDF-LO seems to be
too much though it would offer "easy" compatibility with existing
standards. An open-point for me is then that RTP payloads are usually
optimized and not verbose: I don't know whether XML content would be
acceptable. In any case having an RTP size that is under the MTU size
would be desirable.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 27 Jun 2008 11:15:43 +0200

Thank you for your feedback. See my answer inline.

> in terms of the intended use cases for KML.

[Xavier] I concur. We'll change this and mention OGC standard in the
next version

> model is grounded in ISO 19107 - Features

[Xavier] Yes. We will also indicate that.

> mention DHCP because it is also a binary format.

[Xavier] I agree that CRS topic must absolutely be taken into
consideration in the draft.
Thank you for pointing on the work done for DHCP: We haven't thought about it.

> vendors (Google, Microsoft, ESRI, others) and numerous aggregators.

[Xavier] We haven't considered GeoRSS. I need to have a look at it
before answering on this point.

> GML, GeoRSS, and even DHCP are well aligned.

[Xavier] Again, I agree. I think this comment can be a new requirement
for the draft, something like the solution MUST be consistent with the
existing work in the IETF, in the OGC, and in other organizations.

> Hope this helps!

[Xavier] Yes, definitely