– DRAFT –
Spatial Data on the Web Best Practices Sub Group Teleconference
01 March 2017
<jtandy> https://www.w3.org/2017/02/15-sdwbp-minutes
<jtandy> +1
<ClemensPortele> +1
+1
<AndreaPerego> +1
<joshlieberman> +1
<eparsons> +1
<BartvanLeeuwen> +1
<ByronCinNZ> +1
Resolved: meeting minutes approved
<eparsons> https://www.w3.org/2015/spatial/wiki/Patent_Call
eparsons: reads out patent call
[silence]
<jtandy> https://www.w3.org/2015/spatial/wiki/Detailed_planning_BP_document#February_-_mid_March_2017:
jtandy: sprint plan is on the wiki.
… josh, you're on BP1, do you recognize that?
joshlieberman: yes, with Andrea
jtandy: Andrea: you're on 8
… 9 is addressed to joshlieberman
joshlieberman: working on that with Christine Perey
jtandy: content of that may be merged with bp10 or 14
… I spoke with Bill, he knows he's on BP10
… I'm on 14, 16 will be merged
… section 11 will be based on work we're doing now
… bp11 is Clemens with support from Bart
ClemensPortele: yes
BartvanLeeuwen: aware
jtandy: continues going through sprint plan
<joshlieberman> BP12 ?
jtandy: payam is creating a list of comments we need to go through
… a lot of work but nothing stopping us from meeting the Delft target
… Clemens will address BP12 later in this call
jtandy: there is no expertise in the WG on non-geographic CRS, therefore add to our scope section that this is out
eparsons: agrees, unfortunately
joshlieberman: engineering coordinate systems can be tied into geographic CRS but often just relative to some structure.
… also note the egocentric perspective which comes from AR
… it's worth mentioning that this is a perspective, without offering a BP
ByronCinNZ: leans towards exclusion of non-geo
… the doc is primarily geospatial so people from other domains will not look for info here
… both for cellular positioning and engineering
jtandy: coming back to joshlieberman's comment;
… agrees we ought to mention them
joshlieberman: there would be material for an engineering CRS BP
… making engineering data sharable by tying points to geographic CRS
jtandy: this would be the place for AR info as well?
joshlieberman: yes
jtandy: proposes to ignore the cellular level in terms of spatial
… and include in the next sprint a BP about engineering CRSs and tying them back to geographic CRS
joshlieberman: it could be an addition to BP9, if we make that relative and local positioning
eparsons: and I could add a sentence or two to the intro
… something about global vs local CRS and engineering drawings being a subset of that
jtandy: please do
… joshlieberman, I encourage you to develop BP9 along the lines you've just outlined.
… do you think that's possible within this sprint?
Action: eparsons to expand intro to include CAD drawings as another type of CRS
<trackbot> Created ACTION-276 - Expand intro to include cad drawings as another type of crs [on Ed Parsons - due 2017-03-08].
joshlieberman: yes
<AndreaPerego> Current status: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0008.html
AndreaPerego: I've completed the revision based on the discussion so far.
<AndreaPerego> Preview: https://andrea-perego.github.io/sdw/bp/index.html#describe-geometry
AndreaPerego: I made a fork on my github
… new parts in yellow, I kept also the original text
… revised the why and intended outcome sections, mostly the wording
… the rest is revised more thoroughly with more structure and more actionable guidelines
… there are several notes
… trying to describe the approaches in web, LD and geospatial communities
… and added three examples
(describes the examples in more detail)
AndreaPerego: asks for feedback
jtandy: thanks AndreaPerego for the work he put in
<AndreaPerego> :)
jtandy: did you find gaps in practice about how you ask for particular geometry representation?
AndreaPerego: this is the part causing more trouble
… first you identify the users and applications
… then you provide in different ways accordingly
… I referred to what was already discussed in other parts of the BP eg about dimensions, crs, formats (the table in the appendix)
… these tables are quite useful
… referencing DWBP on conneg
… of course there is not much detail but we could provide more detail in the examples
… please let me know if more is needed
… in my examples multiple representations of a spatial thing are all embedded in the thing
jtandy: joshlieberman, you mentioned the next version of geosparql might make it easy to identify things like bbox, center point.
… is that worth referring to?
joshlieberman: coming slow. But will be something simple like georss as a core and adding more complexity from geosparql.
… but in the core there are currently no geometry role properties.
… there ARE geometry role properties in the core
… The other issue is the distinction between positions and geometry.
… important not to have just a geometry literal. A geometry has characteristics that need to be available. Type of geometry, dimensionality etc
… And there are different serialization options for the position list.
… geosparql used extended wkt for a reason
… bp should be to treat that as a position literal and provide the geometry characteristics outside the literal as well
… will look through AndreaPerego's work
<AndreaPerego> Thanks, Josh
AndreaPerego: thanks a lot joshlieberman
ClemensPortele: when we talk about multiple representations we need to recognize there's also the difference between vocabularies where you represent spatial things and the geometry is a characteristic,
… with one serialization,
… or vocabularies that have different serialization options
… e.g. GML or GeoJSON vs GeoSPARQL
AndreaPerego: was trying to take this issue into account
<joshlieberman_> GeoSPARQL: asWKT vs asGML, etc.
AndreaPerego: therefore tried to be generic
… and added this in notes instead of the running text
… to really address it you need to add a lot of detail, too much for a BP
… a review by ClemensPortele might help
<ClemensPortele> will do ...
jtandy: you are going in the right direction based on the discussion today
<AndreaPerego> Thanks, Clemens!
jtandy: all: please continue to support AndreaPerego in unpicking this topic
<ClemensPortele> New text: http://w3c.github.io/sdw/bp/#bp-exposing-via-api
ClemensPortele: I just updated the section at the link, both the intro and BP11.
… haven't touched BP12 and 13 yet
… but my feeling is we don't necessarily need these two.
… The last versions of DWBP had updated info on the API topic. I consolidated our text with this.
… making sure we build on that and focus on spatial aspects
… and SDI related topics
… the old BP11 had some ideas for examples, I deleted several of them eg WPS, WMS. These are not really convenience APIs.
… Bart should check if his content is covered correctly
… DWBP has info on subsets of large datasets. We can't add that much to it. Coverages is addressed separately.
… potentially we could do a subset example in BP11. Same goes for search.
… therefore BP12 and BP13 could go.
jtandy: BP13 is well covered by DWBP.
… I'd like to propose this to a larger group before deciding. Could you start a discussion thread about dropping BP13?
ClemensPortele: ok
<Zakim> jtandy, you wanted to ask about BP13
Action: ClemensPortele to start a discussion thread on the mailing list about dropping BP13.
<trackbot> Error finding 'ClemensPortele'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
action Clemens Portele to start a discussion thread on the mailing list about dropping BP13.
<trackbot> Created ACTION-277 - Portele to start a discussion thread on the mailing list about dropping bp13. [on Clemens Portele - due 2017-03-08].
jtandy: is search special / does it need its own BP?
joshlieberman: not sure, it could be merged into something about APIs.
… e.g. what search options would we want to recommend.
<ClemensPortele> Current text: "The API should support queries for spatial things based on user needs. For spatial data, a typical need is to support searching data located in a specific area, for example, an area shown as a map in an application. Where users often look for a particular spatial thing without knowning its identifier, a fault-tolerant free-text search on the name, label or other property may be useful."
jtandy: part of a convenience api is providing search for cases where users don't know the identifiers of spatial things.
… would that be enough?
ClemensPortele: is the current text (pasted above) enough?
joshlieberman: the other important thing is some sort of neighborhood search.
jtandy: makes sense
ClemensPortele: will add that
joshlieberman: near and within covers about 80% of spatial queries
jtandy: so we've agreed here that given the minor amendment of BP11, BP12 can go.
<joshlieberman> prese
jtandy: wrapping up, I will continue pushing discussions on sameplaceas and BP2.
… Ed, when we resolve to remove BPs, should we have minuted resolutions in a plenary call?
eparsons: yes
jtandy: then it would be useful to have those resolutions in the next plenary call.
eparsons: drop me an email to remind
jtandy: thanks everyone including demon Linda
<BartvanLeeuwen> thx
<AndreaPerego> Thanks, and bye!
<ClemensPortele> thanks and bye!
<BartvanLeeuwen> bye
<eparsons> Thanks Linda + jtandy
<jtandy> bye!
jtandy: meeting closed
<joshlieberman> bye
bye!