13:54:47 <RRSAgent> RRSAgent has joined #poiwg
13:54:47 <RRSAgent> logging to http://www.w3.org/2011/06/16-poiwg-irc
13:54:49 <trackbot> RRSAgent, make logs public
13:54:51 <trackbot> Zakim, this will be UW_POI
13:54:51 <Zakim> ok, trackbot; I see UW_POI(POIWG)10:00AM scheduled to start in 6 minutes
13:54:52 <trackbot> Meeting: Points of Interest Working Group Teleconference
13:54:52 <trackbot> Date: 16 June 2011
13:57:41 <ahill2> ahill2 has joined #poiwg
13:58:08 <ahill2> hey matt
13:59:11 <Zakim> UW_POI(POIWG)10:00AM has now started
13:59:18 <Zakim> +??P8
13:59:25 <robman> robman has joined #poiwg
13:59:41 <matt> issue-19?
13:59:41 <trackbot> ISSUE-19 -- How should we represent points? -- raised
13:59:41 <trackbot> http://www.w3.org/2010/POI/track/issues/19
14:01:07 <karls> karls has joined #poiwg
14:01:54 <matt> zakim, dial matt-voip
14:01:54 <Zakim> ok, matt; the call is being made
14:01:55 <Zakim> +Matt
14:01:58 <Zakim> + +1.312.894.aaaa
14:02:08 <matt> zakim, who is on the phone?
14:02:08 <Zakim> On the phone I see ??P8, Matt, +1.312.894.aaaa
14:02:11 <Zakim> +??P15
14:02:15 <matt> zakim, ??p8 is Alex
14:02:15 <Zakim> +Alex; got it
14:02:23 <matt> zakim, ??p15 is robman 
14:02:23 <Zakim> +robman; got it
14:02:33 <matt> zakim, aaaa is karls
14:02:33 <Zakim> +karls; got it
14:02:49 <Ronald> Ronald has joined #poiwg
14:03:38 <rsingh2> rsingh2 has joined #poiwg
14:03:49 <Zakim> + +1.617.764.aabb
14:04:05 <matt> zakim, aabb is rsingh2 
14:04:05 <Zakim> +rsingh2; got it
14:04:44 <Zakim> +AZ
14:04:53 <Ronald> Zakim, AZ is Ronald
14:05:05 <Zakim> +Ronald; got it
14:05:20 <matt> Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0014.html
14:06:38 <matt> zakim, who is on the phone?
14:06:38 <Zakim> On the phone I see Alex, Matt, karls, robman, rsingh2, Ronald
14:08:05 <matt> zakim, who is making noise?
14:08:15 <Zakim> matt, listening for 10 seconds I heard sound from the following: Ronald (54%)
14:08:53 <matt> scribe: Matt
14:08:55 <matt> Topic: F2F
14:08:56 <cperey> cperey has joined #poiwg
14:09:12 <matt> matt: Seems like very little f2f traction
14:09:16 <matt> -> http://www.w3.org/2002/09/wbs/45386/POI-F2F-2011-2-MIT/results Poll results
14:09:17 <Zakim> + +1.919.439.aacc
14:09:29 <matt> zakim, aacc is Andy
14:09:29 <Zakim> +Andy; got it
14:09:33 <Andy> Andy has joined #poiwg
14:09:49 <cperey> hi
14:10:35 <Zakim> +??P30
14:11:03 <matt> zakim, ??P30
14:11:03 <Zakim> I don't understand '??P30', matt
14:11:03 <cperey> maybe
14:11:10 <matt> zakim, ??P30 is cperey 
14:11:10 <Zakim> +cperey; got it
14:11:25 <robman> hey christine - sessions looked like they were going really well
14:12:25 <cperey> echo better?
14:13:20 <matt> matt: If we could get myself, karls, rsingh2, Ronald, Jonathan in the same room for two days we can get a lot done.
14:13:40 <matt> matt: Let's do this, make it just a working session, rather than a full WG meeting, we can be flexible about things.
14:14:04 <matt> Topic: Relative points and point encoding
14:14:07 <matt> ISSUE-31?
14:14:07 <trackbot> ISSUE-31 -- How do we establish a relative relationship between two points? -- raised
14:14:07 <trackbot> http://www.w3.org/2010/POI/track/issues/31
14:14:17 <matt> ISSUE-19?
14:14:17 <trackbot> ISSUE-19 -- How should we represent points? -- raised
14:14:17 <trackbot> http://www.w3.org/2010/POI/track/issues/19
14:14:29 <matt> ahill2: Lots of talk around these two issues lately.
14:15:01 <matt> ahill2: 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.
14:15:33 <matt> rsingh2: There's a proposal on the table for 2 encodings.  That clients would have to support both formats.
14:16:29 <matt> ahill2: What was the main argument for the element based one?
14:16:38 <matt> ahill2: That it's easier to write these things without getting confused.
14:17:47 <matt> rsingh2: Yes, that's the gist.
14:18:50 <matt> matt: It lowers confusion to have elements, even though it is more verbose.
14:18:57 <matt> rsingh2: Having 2 sounds wishy washy.
14:19:08 <matt> ahill2: One of the proposals was to have both, but in different places.
14:19:20 <matt> rsingh2: My proposal was two different options for points, and then use the more compact for lines and polys.
14:19:46 <robman> you are multiplying the data size by 10 or more minimum
14:20:33 <matt> rsingh2: My understanding is that you have to include everything in streaming parsers into memory.
14:20:41 <matt> rsingh2: If you have all those coordinates, you have no way to stream.
14:20:51 <matt> karls: What's the relative size comparison?
14:20:58 <matt> rsingh2: ABout a quarter size difference.
14:21:34 <matt> rsingh2: People are used to seeing it in GML, so why do it in yet another format?
14:22:04 <matt> ahill2: I can see both arguments, but would side with rsingh2 that it doesn't seem right to support both.
14:22:25 <robman> latitude:-31,longitude:151,altitude:0  vs -31 151 0   = 37 vs 9 chars for example
14:22:47 <matt> karls: I'm surprised to see people are going to write this with editors, and not software.
14:22:50 <matt> ahill2: In my case we do.
14:22:53 <cperey> ditto, I find it DIFFICULT to imagine that anyone will write by hand
14:23:00 <matt> [[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"/>]]
14:23:18 <cperey> ... I agree that it is difficult to imagine anyone will write by hand
14:23:23 <matt> ahill2: If we don't care about hand writing, then I don't see the issue for having verbose.
14:23:46 <matt> karls: I think it's useful to have something readable.
14:24:05 <robman> readability on first use is key to adoption
14:24:19 <matt> 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.
14:24:34 <matt> ahill2: Matt's example was people hand editing these things.  Not sure that's a justification for making a change.
14:24:37 <robman> but terseness for high volume is also important after adoption
14:24:55 <matt> ahill2: Also, for readability, a comment line saying what the points are would probably be more lightweight than the lat/long elements.
14:25:34 <matt> matt: Also there's the space separation, rather than comma separated like SVG.
14:25:40 <matt> rsingh2: KML has a comma too.
14:25:52 <matt> rsingh2: In GML you can define what separates your coordinates.
14:26:00 <matt> rsingh2: Going to commas would keep GML purists happy.
14:26:11 <matt> rsingh2: It'd better harmonize with KML too.
14:26:27 <matt> rsingh2: If we're trying to appeal to not-GIS professionals, that'd be good too.
14:26:42 <matt> karls: In KML can people embed line breaks to give it a tabular/readable sense?
14:27:09 <matt> karls: One complex string for a poly wouldn't be very readable, but put in breaks you'll see a nice table of it.
14:27:23 <matt> ahill2: This technique of putting in line breaks to clarify has been used before.
14:27:32 <matt> matt: I'd suggest that we list that as a best practice.
14:27:57 <matt> 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.
14:28:11 <matt> ahill2: I hope we've moved beyond that.  I don't think this is for the common person.
14:28:48 <matt> 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.
14:29:39 <matt> 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.
14:30:36 <matt> ahill2: 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.
14:30:41 <matt> ahill2: I think there is some precedent to handling that.
14:30:59 <matt> Ronald: I hadn't seen that.
14:31:15 <matt> ahill2: I was surprised too, but got over it.  I think it's possible to do that.
14:31:44 <matt> 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?
14:32:15 <matt> ahill2: I'd like to see us try to get our heads around how to accommodate something like that without bending over backwards.
14:32:17 <Luca> Luca has joined #poiwg
14:32:22 <matt> karls: The rub seems to be the complex calculation that binds the two.
14:32:35 <matt> karls: If everything is relative to WGS84 and it's offset from that, it's a complex calculation.
14:32:59 <matt> ISSUE-19
14:33:00 <matt> ISSUE-19?
14:33:00 <trackbot> ISSUE-19 -- How should we represent points? -- raised
14:33:00 <trackbot> http://www.w3.org/2010/POI/track/issues/19
14:33:03 <rsingh2> http://www.w3.org/2010/POI/track/issues/19
14:33:05 <matt> ISSUE-31?
14:33:05 <trackbot> ISSUE-31 -- How do we establish a relative relationship between two points? -- raised
14:33:05 <trackbot> http://www.w3.org/2010/POI/track/issues/31
14:33:10 <matt> ISSUE-22?
14:33:10 <trackbot> ISSUE-22 -- How should we represent polygons? -- raised
14:33:10 <trackbot> http://www.w3.org/2010/POI/track/issues/22
14:33:14 <robman> rsingh2 does the ogc use a common formal crs for relative (e.g. in meters)
14:33:44 <matt> ahill2: Is each triplet inside it's own coordinates element?
14:33:48 <matt> rsingh2: In KML?  No.
14:34:05 <matt> rsingh2: KML is based on GML version 2, so coordinates are all in there.
14:34:16 <matt> rsingh2: It's made more readable with line breaks.
14:34:40 <matt> [[<Polygon><outerBoundaryIs><LinearRing><coordinates> -122.0848938459612,37.42257124044786,17
14:34:40 <matt> -122.0849580979198,37.42211922626856,17
14:34:40 <matt> ]]
14:35:04 <matt> ahill2: My perception is that GML has more legitimacy than KML.  The point element in KML is almost the same.
14:35:09 <matt> rsingh2: **something about version numbers**
14:35:15 <matt> ahill2: Why KML and not GML?
14:35:30 <matt> ahill2: KML is an OGC standard now, based on GML version 2.  Lots of communities around KML.
14:35:41 <matt> ahill2: You get the benefits of GML and the existing GIS community.
14:35:50 <matt> s/ahill2/rsingh2/
14:35:51 <matt> s/ahill2/rsingh2/
14:35:55 <matt> ahill2: No resistance from me.
14:36:24 <matt> rsingh2: The lack of clarity is addressed by "KML does this already and people understand it"
14:36:24 <matt> \
14:37:58 <matt> rsingh2: I think you specify what character separates the tuples and what separates the elements in the tuples?
14:38:35 <matt> matt: If you put a space after the comma, what happens?
14:38:43 <matt> rsingh2: I think that would be a problem.  It would break as if it were the tuple.
14:38:52 <matt> s/rsingh2/karls/
14:39:02 <matt> issue-22?
14:39:02 <trackbot> ISSUE-22 -- How should we represent polygons? -- raised
14:39:02 <trackbot> http://www.w3.org/2010/POI/track/issues/22
14:39:26 <matt> karls: The tuple breaker in there is space, and the coordinate separator is a comma.
14:40:00 <matt> karls: So: [-122.0848938459612,37.42257124044786,17] if written as [-122.0848938459612, 37.42257124044786,17], would be two tuples.
14:40:16 <matt> rsingh2: Maybe, but I think the parser is probably very lax.
14:41:31 <matt> matt: I'm not against pithy, I just wanted to point out gotchas.
14:41:38 <matt> ahill2: Let's talk about this over email.
14:41:53 <matt> rsingh2: I think this is just an opinion thing.
14:42:01 <matt> matt: I think we should be flexible to avoid gotchas, not sure we can do that in GML.
14:42:06 <matt> rsingh2: Write it down and I'll ask.
14:42:25 <matt> rsingh2: You can also do inner boundaries with in the poly.
14:42:35 <matt> karls: Real common thing in building footprints.
14:42:42 <matt> rsingh2: The poly is closed by having the last coord be the same as the first.
14:42:47 <matt> rsingh2: Not sure you have to have that.
14:43:27 <ahill2> http://code.google.com/apis/kml/documentation/kmlreference.html#linearring
14:44:15 <matt> 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."
14:44:32 <matt> ahill2: If there were significant differences from GML, it is unlikely that it'd be a show stopper today.
14:44:45 <matt> ahill2: If there's a problem with KML we could have stricter schema.
14:45:10 <matt> 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 unfamiliar.
14:45:24 <ahill2> https://research.cc.gatech.edu/kharma/content/karml-reference
14:45:25 <robman> ogc seem to have a wealth of crs definitions for us to look at http://schemas.opengis.net/gml/3.1.1/base/coordinateReferenceSystems.xsd
14:46:18 <matt> [[       <location>                  <latitude units="meters">6.0</latitude>                      <longitude>0.0</longitude>                       <altitude>0.0</altitude>            </location>]]
14:46:33 <matt> ahill2: Not saying this is how we should do this, but you can see how we do relative stuff.
14:47:10 <matt> ahill2: We model a thing called the balloon after the existing model element in KML.  Models in KML can be positioned and oriented and scaled.
14:47:25 <matt> ahill2: We felt things were going to be positioned, and have us say more than just where it is.
14:48:18 <matt> ahill2: We had both a pithy and a more verbose expression.  The verbose ones could use meters.
14:48:40 <matt> ACTION: ahill2 to find where he saw what lat/long means if it is in meters
14:48:40 <trackbot> Created ACTION-90 - Find where he saw what lat/long means if it is in meters [on Alex Hill - due 2011-06-23].
14:49:16 <matt> robman: Where is the point of origin on that placemark example.
14:49:48 <matt> [[                <locationMode targetHRef=”#user”>relative</locationMode> <!-- fixed (default), relative -->]]
14:49:59 <matt> ahill2: The targetHRef is what we are relative to.  Default is #user.
14:50:46 <matt> ahill2: The #user could be another placemark.
14:51:11 <matt> ahill2: Could be outside of the file.
14:51:56 <matt> ahill2: Our intent wasn't that we'd go open the fil that is referenced.  It does show some of the problems inherent to this.
14:52:49 <matt> robman: I think in GML it would have been more like a CRS that defines the relative location?
14:53:15 <matt> ahill2: When I wrote this spec I was ignorant of CRS, so I didn't incorporate it.
14:53:58 <matt> ahill2: Lack of lat/lng crs stuff is a limitation of KML.
14:54:10 <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>.
14:54:46 <matt> rsingh2: We have: GML v3 pithy, KML/GML 2.2 pithy and we have verbose.
14:55:02 <matt> ahill2: I think it's possible that extensions could be added like we've added that would allow for more verbose descriptions.
14:55:17 <robman> e.g. <gml:Point gml:id="p1" srsName="#srs36">
14:55:18 <robman>       <gml:coordinates>100,200</gml:coordinates>
14:55:18 <robman>     </gml:Point>
14:55:34 <robman> with a default srs/crs but able to define a custom one if you want
14:55:42 <matt> karls: I think we're trying to decide on format of absolute points, and then figure out how to define relative.
14:56:00 <matt> rsingh2: Can we say we have both pithy or verbose or both?
14:56:08 <matt> s/both/both for points/
14:56:17 <matt> rsingh2: That's easier to do in points than in polys.
14:56:42 <matt> rsingh2: 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.
14:57:33 <matt> 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.
14:57:56 <matt> 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.
14:58:12 <Ronald> +1 for pithy only
14:58:20 <matt> 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.
14:58:27 <matt> ahill2: I don't see an obvious advantage of KML over GML.
14:58:51 <matt> 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.
14:58:55 <matt> ahill2: I'm in favor of that approach.
14:59:37 <matt> ahill2: People are going to have to change their code, we won't be supporting GML/KML outright.
14:59:57 <matt> 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 this.
15:00:21 <matt> ahill2: The question then comes down to: "Do we want to resolve to support a verbose format in addition to the GML 3 point description?"
15:00:33 <matt> karls: Seems ...
15:00:35 <matt> ahill2: Agree.
15:00:42 <matt> ahill2: It works for KML.  Throw in a comment if you like.
15:01:28 <ahill2> <!-- lat, lon, alt -->
15:01:39 <matt> matt: I think we can agree that we're going to do pithy and not verbose, but now argue what pithy means.
15:01:59 <matt> ahill2: I think that serves the person for the lay person to work with it.
15:02:30 <karls> sorry have to go
15:02:53 <karls> i am in favor
15:02:54 <matt> matt: My understanding of GML 3 is if you had "x,y,z <!--..." that it screws up.
15:03:02 <matt> matt: That space is significant.
15:03:30 <cperey> got to go! thank you!
15:03:49 <Zakim> -karls
15:04:09 <Zakim> -cperey
15:06:27 <robman> gotta go - bye
15:06:50 <rsingh2> </coords><!-- lon lat alt -->
15:07:10 <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
15:07:28 <Zakim> -robman
15:07:29 <rsingh2> <coords>5 4 0,3 5 3<!-- this is a bad place for a comment --></coords>
15:07:43 <matt> -> http://poi.womer.org:9000/hWoVIFBRY5 scratchpad
15:08:03 <matt> issue-22?
15:08:03 <trackbot> ISSUE-22 -- How should we represent polygons? -- raised
15:08:03 <trackbot> http://www.w3.org/2010/POI/track/issues/22
15:14:22 <Luca> Luca has left #poiwg
15:17:18 <matt> zakim, drop me
15:17:18 <Zakim> -Andy
15:17:18 <Zakim> Matt is being disconnected
15:17:20 <Zakim> -Matt
15:17:21 <Zakim> -rsingh2
15:17:22 <matt> rrsagent, draft minutes
15:17:22 <RRSAgent> I have made the request to generate http://www.w3.org/2011/06/16-poiwg-minutes.html matt
15:17:22 <Zakim> -Alex
15:17:24 <Zakim> -Ronald
15:17:24 <Zakim> UW_POI(POIWG)10:00AM has ended
15:17:27 <Zakim> Attendees were Matt, +1.312.894.aaaa, Alex, robman, karls, +1.617.764.aabb, rsingh2, Ronald, +1.919.439.aacc, Andy, cperey
15:24:49 <robman> robman has left #poiwg
15:39:57 <matt> Chair: Alex
15:40:10 <matt> Present: Andy, Ronald, Raj, Robman, Christine, Matt, Karl
15:40:12 <matt> rrsagent, draft minutes
15:40:12 <RRSAgent> I have made the request to generate http://www.w3.org/2011/06/16-poiwg-minutes.html matt
17:38:11 <Zakim> Zakim has left #poiwg