Minutes 16 June 2011 POIWG Teleconference

Hi all,

The minutes for today's teleconference are here:

And as text below.

Most of our discussions centered around ISSUE-31 and ISSUE-19, but first we talked about the f2f and have tentatively decided to have a real working session at MIT on 12-14 July, rather than a full blown WG meeting.

The issue discussion is best summarized in the minutes, rather than trying to recap here.  I think we'll see further discussion in the two threads on these issues.  (Reminder: reply to those, not to these minutes!)  

The sole action was (poorly described):
	Alex to find where he saw what lat/long means if it is in meters

We had one big resolution:
We will use GML 3 without schema requirement (as resolved before) to describe points, polygons, etc. and we will not require additional support for a more verbose form of point that includes separate latitude, longitude and altitude elements


      [1] http://www.w3.org/

                               - DRAFT -

            Points of Interest Working Group Teleconference

16 Jun 2011


      [2] http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0014.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/16-poiwg-irc


          Andy, Ronald, Raj, Robman, Christine, Matt, Karl




     * [4]Topics
         1. [5]F2F
         2. [6]Relative points and point encoding
     * [7]Summary of Action Items

   <trackbot> Date: 16 June 2011

   <ahill2> hey matt


   <trackbot> ISSUE-19 -- How should we represent points? -- raised

   <trackbot> [8]http://www.w3.org/2010/POI/track/issues/19

      [8] http://www.w3.org/2010/POI/track/issues/19

   <scribe> scribe: Matt


   matt: Seems like very little f2f traction

   -> [9]http://www.w3.org/2002/09/wbs/45386/POI-F2F-2011-2-MIT/results
   Poll results

      [9] http://www.w3.org/2002/09/wbs/45386/POI-F2F-2011-2-MIT/results

   <cperey> hi

   <cperey> maybe

   <robman> hey christine - sessions looked like they were going really

   <cperey> echo better?

   matt: If we could get myself, karls, rsingh2, Ronald, Jonathan in
   the same room for two days we can get a lot done.
   ... Let's do this, make it just a working session, rather than a
   full WG meeting, we can be flexible about things.

Relative points and point encoding


   <trackbot> ISSUE-31 -- How do we establish a relative relationship
   between two points? -- raised

   <trackbot> [10]http://www.w3.org/2010/POI/track/issues/31

     [10] http://www.w3.org/2010/POI/track/issues/31


   <trackbot> ISSUE-19 -- How should we represent points? -- raised

   <trackbot> [11]http://www.w3.org/2010/POI/track/issues/19

     [11] http://www.w3.org/2010/POI/track/issues/19

   ahill2: Lots of talk around these two issues lately.
   ... Sounds like we're ready to resolve that the GeoRSS GML encoding
   of points is the de facto way to describe points, but that there
   should be an extension to represent them in other ways.

   rsingh2: There's a proposal on the table for 2 encodings. That
   clients would have to support both formats.

   ahill2: What was the main argument for the element based one?
   ... That it's easier to write these things without getting confused.

   rsingh2: Yes, that's the gist.

   matt: It lowers confusion to have elements, even though it is more

   rsingh2: Having 2 sounds wishy washy.

   ahill2: One of the proposals was to have both, but in different

   rsingh2: My proposal was two different options for points, and then
   use the more compact for lines and polys.

   <robman> you are multiplying the data size by 10 or more minimum

   rsingh2: My understanding is that you have to include everything in
   streaming parsers into memory.
   ... If you have all those coordinates, you have no way to stream.

   karls: What's the relative size comparison?

   rsingh2: ABout a quarter size difference.
   ... People are used to seeing it in GML, so why do it in yet another

   ahill2: I can see both arguments, but would side with rsingh2 that
   it doesn't seem right to support both.

   <robman> latitude:-31,longitude:151,altitude:0 vs -31 151 0 = 37 vs
   9 chars for example

   karls: I'm surprised to see people are going to write this with
   editors, and not software.

   ahill2: In my case we do.

   <cperey> ditto, I find it DIFFICULT to imagine that anyone will
   write by hand

   [[SVG example: <path id="path_1" stroke-width="1" stroke="blue"
   fill="yellow" fill-rule="evenodd" d="M150,150 L200,100 H250 V170
   Q350,90 375,150 T400,150 C500,100 575,300 560,150 S650,160 550,300 Z
   M500,200 A25,35 -80 1,1 450,220 Z"/>]]

   <cperey> ... I agree that it is difficult to imagine anyone will
   write by hand

   ahill2: If we don't care about hand writing, then I don't see the
   issue for having verbose.

   karls: I think it's useful to have something readable.

   <robman> readability on first use is key to adoption

   karls: I would speculate that the issue is that it's error prone if
   it's pithy is not all that much of a problem.

   ahill2: Matt's example was people hand editing these things. Not
   sure that's a justification for making a change.

   <robman> but terseness for high volume is also important after

   ahill2: Also, for readability, a comment line saying what the points
   are would probably be more lightweight than the lat/long elements.

   matt: Also there's the space separation, rather than comma separated
   like SVG.

   rsingh2: KML has a comma too.
   ... In GML you can define what separates your coordinates.
   ... Going to commas would keep GML purists happy.
   ... It'd better harmonize with KML too.
   ... If we're trying to appeal to not-GIS professionals, that'd be
   good too.

   karls: In KML can people embed line breaks to give it a
   tabular/readable sense?
   ... One complex string for a poly wouldn't be very readable, but put
   in breaks you'll see a nice table of it.

   ahill2: This technique of putting in line breaks to clarify has been
   used before.

   matt: I'd suggest that we list that as a best practice.

   karls: I can see people copy and pasting in a point, but complex
   polys is a big list and hard to imagine people are going to manually
   edit those puppies.

   ahill2: I hope we've moved beyond that. I don't think this is for
   the common person.

   Ronald: I have another argument against the verbose version. Tied
   into the relative points that we'll discuss later. There we added a
   different meaning to the coordinates. Having lat/long names in there
   will hurt that.

   ahill2: In KARML, we had to deal with two of these issues: 1. the
   point by itself didn't describe enough information -- not where but
   also how it was oriented -- so we had an optional element that
   overrode the point essentially. So, we may need to consider those
   types of additional data.
   ... 2. We extended our data to allow different units, lat/long plus
   meters for instance. I've seen documentation where they've allowed
   people to do meters. I think in CityGML where it was assumed that
   latitude meant north and lat meant positive east direction.
   ... I think there is some precedent to handling that.

   Ronald: I hadn't seen that.

   ahill2: I was surprised too, but got over it. I think it's possible
   to do that.

   karls: This linked list of x,y, and z could be lat/long and alt or
   some other x,y,z system? That we don't care?

   ahill2: I'd like to see us try to get our heads around how to
   accommodate something like that without bending over backwards.

   karls: The rub seems to be the complex calculation that binds the
   ... If everything is relative to WGS84 and it's offset from that,
   it's a complex calculation.



   <trackbot> ISSUE-19 -- How should we represent points? -- raised

   <trackbot> [12]http://www.w3.org/2010/POI/track/issues/19

     [12] http://www.w3.org/2010/POI/track/issues/19

   <rsingh2> [13]http://www.w3.org/2010/POI/track/issues/19

     [13] http://www.w3.org/2010/POI/track/issues/19


   <trackbot> ISSUE-31 -- How do we establish a relative relationship
   between two points? -- raised

   <trackbot> [14]http://www.w3.org/2010/POI/track/issues/31

     [14] http://www.w3.org/2010/POI/track/issues/31


   <trackbot> ISSUE-22 -- How should we represent polygons? -- raised

   <trackbot> [15]http://www.w3.org/2010/POI/track/issues/22

     [15] http://www.w3.org/2010/POI/track/issues/22

   <robman> rsingh2 does the ogc use a common formal crs for relative
   (e.g. in meters)

   ahill2: Is each triplet inside it's own coordinates element?

   rsingh2: In KML? No.
   ... KML is based on GML version 2, so coordinates are all in there.
   ... It's made more readable with line breaks.




   ahill2: My perception is that GML has more legitimacy than KML. The
   point element in KML is almost the same.

   rsingh2: **something about version numbers**

   ahill2: Why KML and not GML?

   rsingh2: KML is an OGC standard now, based on GML version 2. Lots of
   communities around KML.
   ... You get the benefits of GML and the existing GIS community.

   ahill2: No resistance from me.

   rsingh2: The lack of clarity is addressed by "KML does this already
   and people understand it"


   rsingh2: I think you specify what character separates the tuples and
   what separates the elements in the tuples?

   matt: If you put a space after the comma, what happens?

   karls: I think that would be a problem. It would break as if it were
   the tuple.


   <trackbot> ISSUE-22 -- How should we represent polygons? -- raised

   <trackbot> [16]http://www.w3.org/2010/POI/track/issues/22

     [16] http://www.w3.org/2010/POI/track/issues/22

   karls: The tuple breaker in there is space, and the coordinate
   separator is a comma.
   ... So: [-122.0848938459612,37.42257124044786,17] if written as
   [-122.0848938459612, 37.42257124044786,17], would be two tuples.

   rsingh2: Maybe, but I think the parser is probably very lax.

   matt: I'm not against pithy, I just wanted to point out gotchas.

   ahill2: Let's talk about this over email.

   rsingh2: I think this is just an opinion thing.

   matt: I think we should be flexible to avoid gotchas, not sure we
   can do that in GML.

   rsingh2: Write it down and I'll ask.
   ... You can also do inner boundaries with in the poly.

   karls: Real common thing in building footprints.

   rsingh2: The poly is closed by having the last coord be the same as
   the first.
   ... Not sure you have to have that.


     [17] http://code.google.com/apis/kml/documentation/kmlreference.html#linearring

   ahill2: As you can see in linerarring the last element they describe
   is coordinates. It says: "Do not include spaces between the three
   values that describe a coordinate."
   ... If there were significant differences from GML, it is unlikely
   that it'd be a show stopper today.
   ... If there's a problem with KML we could have stricter schema.

   rsingh2: With KML the problem is the same as it's strength: it's
   popular. If people see meters in there, people will freak out and be


     [18] https://research.cc.gatech.edu/kharma/content/karml-reference

   <robman> ogc seem to have a wealth of crs definitions for us to look

     [19] http://schemas.opengis.net/gml/3.1.1/base/coordinateReferenceSystems.xsd

   [[ <location> <latitude units="meters">6.0</latitude>
   <longitude>0.0</longitude> <altitude>0.0</altitude> </location>]]

   ahill2: Not saying this is how we should do this, but you can see
   how we do relative stuff.
   ... We model a thing called the balloon after the existing model
   element in KML. Models in KML can be positioned and oriented and
   ... We felt things were going to be positioned, and have us say more
   than just where it is.
   ... We had both a pithy and a more verbose expression. The verbose
   ones could use meters.

   <scribe> ACTION: ahill2 to find where he saw what lat/long means if
   it is in meters [recorded in

   <trackbot> Created ACTION-90 - Find where he saw what lat/long means
   if it is in meters [on Alex Hill - due 2011-06-23].

   robman: Where is the point of origin on that placemark example.

   [[ <locationMode targetHRef=”#user”>relative</locationMode> <!--
   fixed (default), relative -->]]

   ahill2: The targetHRef is what we are relative to. Default is #user.
   ... The #user could be another placemark.
   ... Could be outside of the file.
   ... Our intent wasn't that we'd go open the fil that is referenced.
   It does show some of the problems inherent to this.

   robman: I think in GML it would have been more like a CRS that
   defines the relative location?

   ahill2: When I wrote this spec I was ignorant of CRS, so I didn't
   incorporate it.
   ... Lack of lat/lng crs stuff is a limitation of KML.

   <ahill2> Specifies the exact coordinates of the Model's origin in
   latitude, longitude, and altitude. Latitude and longitude
   measurements are standard lat-lon projection with WGS84 datum.
   Altitude is distance above the earth's surface, in meters, and is
   interpreted according to <altitudeMode> or <gx:altitudeMode>.

   rsingh2: We have: GML v3 pithy, KML/GML 2.2 pithy and we have

   ahill2: I think it's possible that extensions could be added like
   we've added that would allow for more verbose descriptions.

   <robman> e.g. <gml:Point gml:id="p1" srsName="#srs36">

   <robman> <gml:coordinates>100,200</gml:coordinates>

   <robman> </gml:Point>

   <robman> with a default srs/crs but able to define a custom one if
   you want

   karls: I think we're trying to decide on format of absolute points,
   and then figure out how to define relative.

   rsingh2: Can we say we have both pithy or verbose or both for
   ... That's easier to do in points than in polys.
   ... In our model we have a bunch of ways to describe a point, so
   it's not going to be expanding the point element in a way that we
   hadn't already pursued.

   ahill2: I argue in favor of pithy version of GML, don't care if it's
   KML, doesn't matter to me. Obviously GML comes with conventions
   already for changing coord systems, and that seems like a valuable
   thing. If people want to argue for both pithy and verbose in point,
   that's fine.

   rsingh2: I'm not a huge believer in supporting standards for their
   own sake, but GML 3 is an ISO standard. Some people care and are
   mandated by law to use GML.

   <Ronald> +1 for pithy only

   ahill2: That's part of why we are respecting GML. As long as it
   doesn't fall into being too laborious, as people have complained
   about GML.
   ... I don't see an obvious advantage of KML over GML.

   rsingh2: One thing that makes GML hard to use is the requirement to
   import the schema, which if we get rid of namespaces then that
   reduces the burden on developers a lot.

   ahill2: I'm in favor of that approach.
   ... People are going to have to change their code, we won't be
   supporting GML/KML outright.

   rsingh2: As OGC person I would say GML version 3. A lot of this is
   going to be subjective, not sure there's an objective way through

   ahill2: The question then comes down to: "Do we want to resolve to
   support a verbose format in addition to the GML 3 point

   karls: Seems ...

   ahill2: Agree.
   ... It works for KML. Throw in a comment if you like.

   <ahill2> <!-- lat, lon, alt -->

   matt: I think we can agree that we're going to do pithy and not
   verbose, but now argue what pithy means.

   ahill2: I think that serves the person for the lay person to work
   with it.

   <karls> sorry have to go

   <karls> i am in favor

   matt: My understanding of GML 3 is if you had "x,y,z <!--..." that
   it screws up.
   ... That space is significant.

   <cperey> got to go! thank you!

   <robman> gotta go - bye

   <rsingh2> </coords><!-- lon lat alt -->

   <ahill2> resolution: we will use GML 3 without schema requirement
   (as resolved before) to describe points, polygons, etc. and we will
   not require additional support for a more verbose form of point that
   includes separate latitude, longitude and altitude elements

   <rsingh2> <coords>5 4 0,3 5 3<!-- this is a bad place for a comment

   -> [21]http://poi.womer.org:9000/hWoVIFBRY5 scratchpad

     [21] http://poi.womer.org:9000/hWoVIFBRY5


   <trackbot> ISSUE-22 -- How should we represent polygons? -- raised

   <trackbot> [22]http://www.w3.org/2010/POI/track/issues/22

     [22] http://www.w3.org/2010/POI/track/issues/22

Summary of Action Items

   [NEW] ACTION: ahill2 to find where he saw what lat/long means if it
   is in meters [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [24]scribe.perl version 1.136
    ([25]CVS log)
    $Date: 2011/06/16 15:40:18 $

     [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [25] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [26]http://dev.w3.org/cvsweb/~checkout~/2002

     [26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ahill2/rsingh2/
Succeeded: s/ahill2/rsingh2/
Succeeded: s/rsingh2/karls/
Succeeded: s/both/both for points/
Found Scribe: Matt
Inferring ScribeNick: matt
Default Present: Matt, +1.312.894.aaaa, Alex, robman, karls, +1.617.764
.aabb, rsingh2, Ronald, +1.919.439.aacc, Andy, cperey
Present: Andy Ronald Raj Robman Christine Matt Karl
Agenda: [27]http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/00
Found Date: 16 Jun 2011
Guessing minutes URL: [28]http://www.w3.org/2011/06/16-poiwg-minutes.ht
People with action items: ahill2

     [27] http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0014.html
     [28] http://www.w3.org/2011/06/16-poiwg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   End of [29]scribe.perl diagnostic output]

     [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 16 June 2011 16:17:14 UTC