See also: IRC log
<trackbot> Date: 26 May 2011
ISSUE-33?
<trackbot> ISSUE-33 -- Is the map georeference type needed? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/33
<robman> i've muted my phone
-> http://www.w3.org/TR/2011/WD-poi-core-20110512/ POI Core FPWD
<scribe> scribe: Matt
<cperey> hi
<robman> hi
ahill2: Need to resolve this. We
have a problem, as it turns out, I won't be able to make
Budapest, and neither can Andy. With that date rushing up on
us, I think we've got some consensus among matt/andy/me to have
next f2f sometime in July at MIT.
... We really appreciate your effort cperey, I know you went
through a lot to broker a place for us with OMA, but it's a
failure of matt/andy/I to know whether we could make it.
cperey: It's not my concern, but the guy who arranged it, with support for the meals, etc, talked to his bosses, etc. He's the one taking it on the chin.
matt: I'll take the hit for the miscommunication and write to him after this call.
ahill2: With Budapest off the
table, we were going to do a poll between to between meeting in
September in Denver or between now and then. It seems that
September is too long to wait.
... That leaves us with MIT.
cperey: Clarification: how sure are you about September in Denver? is that 100% nailed in?
ahill2: Logistics and coordination? No.
cperey: In all senses of the question.
ahill2: It was the top vote getter in the poll, followed by OMA and MIT.
matt: TPAC could still be done, but it's very close to September. I really want to nail down just the next F2F at this point, as it's getting late.
cperey: True, but the next one
will impact the following one.
... Late July is also close to mid-September.
... The benefit of Denver is co-locating with other SDOs. Plus,
there's less cost, for the meeting itself.
ahill2: I don't think we can
resolve today whether it's going to be TPAC or Denver OGC. We
haven't done a very good job of making this happen with polls.
This is a members decision, but we're in a position now where
we're having to make an executive decision.
... As far as Denver vs TPAC goes, that should be group-wide
decision.
... I resolve that we will meet at MIT in July. Date is TBD, as
I need Andy to chime in. He'll be chairing.
... Objections?
... None.
-> http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055 Agenda
ISSUE-33?
<trackbot> ISSUE-33 -- Is the map georeference type needed? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/33
kseiler: Do we need to go back in one of these meetings and adjust the timeline? It's starting to feel open-ended.
ahill2: let's put that in the agenda for the next meeting.
<cperey> +1
<scribe> ACTION: ahill2 to put time-line on next week's agenda [recorded in http://www.w3.org/2011/05/26-poiwg-minutes.html#action01]
<trackbot> Created ACTION-83 - Put time-line on next week's agenda [on Alex Hill - due 2011-06-02].
ahill2: It seems to me the consensus is that we don't need a map georeference.
kseiler: I'm probably the primary
representative of the map community on the call. I stewed on
this a bit, and can appreciate the complexity of it. The
problem is with geocoding, if we only care about lat/long of
various points, then that means there has to be a service in
the world that will bind that to a map.
... X/Y is not map relative. You don't know what street it's on
until you snap to a link. That function, how you best get
there, etc, is pretty complicated. Manually nuanced in many
cases.
... So in the spec, being able to hard bind to a point on the
map would relieve ambiguity.
Carl: If you have the appropriate coordinate reference system that explicitly tells you the parameters of what's being used, then you've got some measure of accuracy and certainty. Maybe not as accurate as you are talking about, but you can snap to.
kseiler: Take the case of the US: if we're carrying lat/long in the spec and someone wants to navigate to a POI -- some service is going to have to provide the translation from lat/long to map.
<ahill2> Hard to argue with the need for a map reference, but hard to incorporate it cleanly
kseiler: The complexity of
binding to a map reference is that there are all kind of maps
and vendors, etc. What we might do is not try to address it,
but make sure the spec is extensible, so that a map reference
could be added on.
... I'm going to carry a map reference either way, because
recomputing cost is too high. Maps are changing frequently, and
calculating the snap-to is very expensive. If we have to do it
as an extension, then we will do that.
ahill2: Is there value in talking about how to approach that?
kseiler: I don't know if it's part of the core spec, or a recommended model, or a soft advisory or something.
ahill2: Can a map reference be as simple as a URI?
kseiler: Yes.
ahill2: The way it's going to be implemented is going to be vendor specific.
kseiler: Make it optional, and a URI and then it could go in the core spec.
ahill2: So, is it important
enough to add to the core spec? Obviously, it'd be
optional.
... Sounds like the issue remains open.
issue-32?
<trackbot> ISSUE-32 -- Does map georeference side definition need additional info? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/32
ahill2: Anything else to say
about map georeference?
... OK, moving on.
... Move on to namespaces.
kseiler: Going back a bit. I'm
not necessarily current. Have you talked about locations that
are a little bit ambiguous?
... There are 6000 hamlets in France. It's a valuable thing for
navigating. It's not an address, it could be an x/y, but how
would the spec carry things like that?
ahill2: What kind of information do we have about where a hamlet is?
kseiler: Typically, it's X/Y is
the intersection of a main thoroughfare. It's usually got some
administrative naming associated with it.
... Name neighborhoods too.
... Is this type of thing handled by map reference, or is there
an open ended construct?
<Luca> Sorry I'm late
ahill2: I don't think anything has changed dramatically since you were last here. We want to accommodate POIs that are fuzzier, rather than very strict geospatial POIs.
<robman> things like hamlets seems more like a combination of "define as an area geometry" and an open ended discussion about international address formats 8)
ahill2: There has been a lot of
confusion about this, but that is the plan.
... For instance, we have the relationship primitive which I
believe facilitates that kind of thing.
... Somebody just recently posted an OGC thing about the kinds
of relationships.
... Talking about POIs that aren't specifically geographic
areas
[[3.3 Relationship Primitives
These section should perhaps simply reference the OGC/ISO Simple Features
Interface standard, section 6.1.15 Ð Relational Operators.]]
-> http://lists.w3.org/Archives/Public/public-poiwg/2011May/0028 OGC comments, relationships
carl: A series of POIs?
ahill2: At one point we had
discussion about having a whole bunch of POIs that could have
relationships like "contains" that establishes --
... The example was Silicon Valley. It's not a part of a city
necessarily, but is a region within it.
... We wanted to capture that kind of relationship.
carl: There's a group in ISO
called @@??@@
... In our terminology that's known as a feature collection, or
a multi-point/polygon geometry.
... At OGC we work with just the geometries. But if you want
real-world phenomenon, such as a city or a restaurant, we call
those features, they have geometry properties and properties
like "contains".
... A feature could contain a collection of features. You could
have a feature called San Jose, that contains all of the
buildings in San Jose and all of the relationships between
them.
... The question is, do you want all of that complexity in the
data model?
... Can you keep a simple core data model, but have an
extension mechanism that allows you to get to more interesting
cases without making the core data model so complex that we may
never come to agreement.
<robman> +1 for a simple point based data model with a feature collection relationship extension
kseiler: I agree with simple data model.
ahill2: How do you represent these POIs at navteq?
kseiler: In our POI spec, we have
an area that is a center point plus administrative information.
It's not a bounded poly because those are too crisp.
... We also know the administrative hierarchy.
... That suffices for consumption.
ahill2: This also deals with
LOD?
... As you zoom, you don't see all of the boundaries.
kseiler: I don't work on rendering, but on getting people to places, so something like a hamlet, if we give them a center point on a major thoroughfare, that's good enough for us.
ahill2: So we need to accommodate points that don't have geometric boundaries. That's pretty obvious, right? The question is, is the relationship you're describing, administrative types, have we made space for those types of relationships?
<cperey> this is actually a very interesting discussion (for me!) and I do not want to interrupt but I must sign off. I'll be on the call next week bye
kseiler: I think civic addresses are hierarchical.
<cperey> cperey waves to matt
<robman> bye cperey
kseiler: The administrative
hierarchy varies from country to country, culture to culture.
That's very expensive.
... I'd recommend that you have a construct for addresses, or
reference out to something, but keep it light.
[[+1 to keeping address light, or even non-existent]]
ahill2: Where in the spec do we put these administrative relationships? Carl, Raj?
Carl: I'll have to think about it
a bit. When we develop standards at OGC, they tend to be very
generic, obviously based on requirements and use cases, but
pretty much content model agnostic and application
agnostic.
... You could take our standards and code a POI fifty different
ways. We've never sat down a defined a POI, other than our
location services standard, which just has a POI as a point.
I'd have to give some thought to it.
Raj: I'm remember that on this call, we discussed that admin categories could be captured in the categorization element. That we would have a term library for administrative levels that you could then reference the administrative boundary unit for that country.
rsingh2: If you wanted to say something was province, you'd say this is "Manatoba", and you'd reference the term dictionary for Canada, and the value would be "province"
ahill2: Sounds reasonable, but in
practical matters, kseiler, are you imagining that this
administrative relationship is from POI to POI, or will
categories as rsingh2 described suffice?
... e.g. going out of the data model to define the
relationship.
... If he says "administrative area, Manitoba" he's not
referring to another POI. Is that a problem?
kseiler: It's easy for me to
imagine that people want to have POIs for features: Silicon
Valley, Theater District. Then there are the real world
administrative names for things. Do we expect the user
community to create POIs that represent say Illinois? Or can
the POI just reference the administrative metadata?
... And then, who maintains the admin data? Those things are
all in flux.
... I think we should have the spec make a POI for Illinois is
allowed, but it's a descriptive tag. But if the category covers
it, that might be the right thing to do.
<robman> surely the POIs are simply binding references to a relatively content free CRS - then POI publishers can create things like features and map content, etc
ahill2: What we came to made some
sense. If we're referring to say, McDonald's Cooperation,
that's not in the purview of the spec, not that we want to make
them impossible.
... It seems to me that we want people to use and refer to POIs
that aren't physical places. But we also want to have a POI
that is Illinois, and Chicago, and we want to have a
relationship between them.
... The WD has "contained-within" and "adjacent-to".
rsingh2: Chicago or Illinois
could be POIs, and the Chicago one could link to Illinois via
contained-within. Then Chicago could have a US category of
city.
... What we don't have is a real hierarchical taxonomy.
<ahill2> so perhaps we need is "an instance of"
rsingh2: e.g. "all cities are
children of states"
... That taxonomy is a big part of a gazetteer.
kseiler: What you just said lets
one build out that hierarchy. Our spec lets someone else build
it.
... We kind of did the same thing with civil addresses.
... It sounds like in the POI spec we've got the ability to
build these hierarchical constructs.
... I think the tinker-toy blocks are there if someone wanted
to build it out.
ahill2: Do we need an "instance-of" relationship? How do I indicate that Illinois is an instance of a state? Is it sufficient to say it's a category of state?
kseiler: I think that works.
rsingh2: One thing we don't get is automatic hierarchy building. Just because you have a relationship of Chicago to Illinois, you don't get to say it's in the US unless you put it in there.
kseiler: These things are constantly in flux at navteq.
rsingh2: Not good for an international standard.
ahill2: It might be nice if the
spec could also be used in that way.
... They will want to use it in a more flexible manner. It may
be possible to say that a POI is a country and then use the
spec to say that there are POIs that are states that are
contained within it. Maybe there's a possibility it could be
used that way.
<robman> category queries
ahill2: About tangents, I don't want this call to be about topics that no one cares about, so tangents can be good.
ISSUE-12?
<trackbot> ISSUE-12 -- Should object be a georeference? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/12
ahill2: One topic I wanted to hit was objects vs areas. Some confusion over whether this separation between representation and content -- some people thought 3d models would be defining space.
<robman> theoretically all features and extents could be externalised and just linked to a POI
ahill2: I think OGC folks would agree that their specs accommodate building geometric areas, but I think we should put a line in the sand and say that a 3d model to define an area is different than say putting a 3d model of Mickey Mouse in a football field.
robman: Inline or external?
ahill2: That's a separate discussion.
rsingh2: You're talking 3d for the physical surface vs say kinematics.
ahill2: One is representation --
I think we're getting to a future where a centroid will not
suffice anymore.
... Something like CityGML that has a detailed hierarchical
info on the area.
<robman> ahill2 I think you're right - one is a description and one is a representation
<robman> description is geometry - representation is how it should look visually
ahill2: There's going to be a collision at some point, not sure what to do about that, at some point they're going to be the same thing.
kseiler: I had this problem
around the location primitive. There's a point, and a polygon,
and then there is "the building". It's less of a wireframe, but
could become the point cloud from our lidar imagery.
... I couldn't draw a clean line. Why does it end at a 2d
polygon?
<robman> i think that's just a choice made by the POI publisher
ahill2: It is a touchy subject. You need rendering experts and animators to comment on it.
<robman> and possibly supported by content negotiation in the client apps
ahill2: it's undoubtedly true that not everyone will be satisfied by everything produced.
[[+1 to both of robman's points]]
ahill2: There is a clear distinction between the two: we're not going to propose an Amaya model as a replacement for the extent.
<robman> 8)
rsingh2: We work at OGC with the Web3D Consortium, which comes from VRML and 3d gaming.
<fons> +1 to both of robman's points also
rsingh2: They started with 3d
gaming and not real world coord models. Languages were closer
to graphics card programming.
... They don't even get into character modeling, etc.
... It all comes down to LOD.
... If you have a point for a POI, and then get more
resolution, and create a new POI and link to the old one.
... You might have different POIs that use different numbers of
coords, or different standard systems to describe it.
<robman> rsingh2 - why not use the same POI but have content negotation for resolution based representations
ahill2: Isn't this effectively what something like CityGML does? It has hierarchical relationships between structures?
Carl: Yes it does.
ahill2: Are we barking up the same tree here? We want someone to be able to say "here's a POI for the mall" and someone later submits the POI for the McDonalds and references the Mall as a coord system ref, "I am 100 feet from center of the mall" --
Carl: I also work on standards at
OASIS. There's a group there, the Emergency Management
@@something something@@.
... They've had almost identical discussions.
... They're trying to keep the base model as simple as
possible, and have extensions.
... They're basic POI is a point, line, or circle.
... If there's a relationship, they do it by URI.
[[+1 to linking such relationships!]]
<robman> +1 to that too
kseiler: We're micromapping all of the shopping malls and airports, and there are POIs in there. The shoe store points to the map of the mall. I don't think we can do much beyond reference out to those constructs.
ahill2: Does our current proposed data model accommodate this? It seems to via our relationship primitive.
<robman> a combination of relationships and geometries/features should support that
ahill2: Does it allow us to point to a URI of a mall?
[[I wonder about setting the crs to reference the mall, rather than using relationship]]
ahill2: The relationship primitive, we can say "contained within" and point to another URI.
matt: Can't we use the srs stuff?
Carl: That's a spatial reference system. e.g. WGS-84.
ahill2: Sounds like a no.
<kseiler> sorry have to run, good topics
matt: OK. How do we represent that it's 100 feet from the center of the mall?
ahill2: I think this a good stopping point and a good beginning point for next week.
<robman> +1 to wrapping up - run out of time
ahill2: Definitely we have had a
lot of discussion about relative positioning, and now that we
have the FPWD out, we need to go back and make sure we've
accommodated that.
... Those of us at the f2f agreed that there are probably many
potential descriptions of the point and we wanted to
accommodate that.
... So, you could have a location 100ft from somewhere
else.
<robman> see ya all next week
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/./?/ Succeeded: s/./?/ Succeeded: s|Topic: Actions/Issues clean up|Topic: map georeference type| Succeeded: i/So we need to accommodate/Topic: Role of the relationship primitve| Succeeded: s/primitve|/primitive/ Found Scribe: Matt Inferring ScribeNick: matt Default Present: Matt, ahill2, +1.312.894.aaaa, Karl, robman, fons, cperey, Carl_Reed, Raj, Luca Present: Matt ahill2 +1.312.894.aaaa Karl robman fons cperey Carl_Reed Raj Luca Agenda: http://lists.w3.org/Archives/Member/member-poiwg/2011May/0055 Found Date: 26 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/26-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]