Points of Interest Working Group Teleconference -- 16 Jun 2011

<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

F2F

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.

Relative points and point encoding

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> ]]

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> 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.

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

<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

-> 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

- DRAFT -

Points of Interest Working Group Teleconference

16 Jun 2011

Attendees

Contents

F2F

Relative points and point encoding

Summary of Action Items

Scribe.perl diagnostic output