- From: Matt Womer <mdw@w3.org>
- Date: Thu, 16 Jun 2011 12:17:06 -0400
- To: public-poiwg W3C <public-poiwg@w3.org>
Hi all,
The minutes for today's teleconference are here:
http://www.w3.org/2011/06/16-poiwg-minutes.html
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
-M
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Points of Interest Working Group Teleconference
16 Jun 2011
[2]Agenda
[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
Attendees
Present
Andy, Ronald, Raj, Robman, Christine, Matt, Karl
Regrets
Chair
Alex
Scribe
Matt
Contents
* [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
issue-19?
<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
F2F
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
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.
Relative points and point encoding
ISSUE-31?
<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
ISSUE-19?
<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
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> [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
ISSUE-31?
<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
ISSUE-22?
<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.
[[<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> [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.
<ahill2>
[17]http://code.google.com/apis/kml/documentation/kmlreference.html#
linearring
[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
unfamiliar.
<ahill2>
[18]https://research.cc.gatech.edu/kharma/content/karml-reference
[18] https://research.cc.gatech.edu/kharma/content/karml-reference
<robman> ogc seem to have a wealth of crs definitions for us to look
at
[19]http://schemas.opengis.net/gml/3.1.1/base/coordinateReferenceSys
tems.xsd
[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
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
[20]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>
-> [21]http://poi.womer.org:9000/hWoVIFBRY5 scratchpad
[21] http://poi.womer.org:9000/hWoVIFBRY5
issue-22?
<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
[23]http://www.w3.org/2011/06/16-poiwg-minutes.html#action01]
[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
/scribe/
[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
14.html
Found Date: 16 Jun 2011
Guessing minutes URL: [28]http://www.w3.org/2011/06/16-poiwg-minutes.ht
ml
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