See also: IRC log
<trackbot> Date: 16 June 2011
<ahill2> hey matt
issue-19?
<trackbot> ISSUE-19 -- How should we represent points? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/19
<scribe> scribe: Matt
matt: Seems like very little f2f traction
-> http://www.w3.org/2002/09/wbs/45386/POI-F2F-2011-2-MIT/results Poll results
<cperey> hi
<cperey> maybe
<robman> hey christine - sessions looked like they were going really well
<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.
ISSUE-31?
<trackbot> ISSUE-31 -- How do we establish a relative relationship between two points? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/31
ISSUE-19?
<trackbot> ISSUE-19 -- How should we represent points? -- raised
<trackbot> 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 verbose.
rsingh2: Having 2 sounds wishy washy.
ahill2: One of the proposals was to have both, but in different places.
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 format?
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 adoption
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 two.
... If everything is relative to WGS84 and it's offset from
that, it's a complex calculation.
ISSUE-19
ISSUE-19?
<trackbot> ISSUE-19 -- How should we represent points? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/19
<rsingh2> http://www.w3.org/2010/POI/track/issues/19
ISSUE-31?
<trackbot> ISSUE-31 -- How do we establish a relative relationship between two points? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/31
ISSUE-22?
<trackbot> ISSUE-22 -- How should we represent polygons? -- raised
<trackbot> 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.
[[<Polygon><outerBoundaryIs><LinearRing><coordinates> -122.0848938459612,37.42257124044786,17
-122.0849580979198,37.42211922626856,17
]]
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.
issue-22?
<trackbot> ISSUE-22 -- How should we represent polygons? -- raised
<trackbot> 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.
<ahill2> 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 unfamiliar.
<ahill2> https://research.cc.gatech.edu/kharma/content/karml-reference
<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
[[ <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 scaled.
... 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 http://www.w3.org/2011/06/16-poiwg-minutes.html#action01]
<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 verbose.
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 points?
... 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 this.
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?"
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 --></coords>
-> http://poi.womer.org:9000/hWoVIFBRY5 scratchpad
issue-22?
<trackbot> ISSUE-22 -- How should we represent polygons? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/22
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at 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: http://lists.w3.org/Archives/Member/member-poiwg/2011Jun/0014.html Found Date: 16 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/16-poiwg-minutes.html People with action items: ahill2 WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]