- From: Alejandro Llaves <allaves@fi.upm.es>
- Date: Fri, 10 Jul 2015 10:54:02 +0200
- To: Ed Parsons <eparsons@google.com>
- Cc: Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CABTzy2Tx3B1XdAPnKP1avWB29xJPKJs-cUndAy7b7WXs5cjSdw@mail.gmail.com>
Thanks, Ed. Alejandro On 10 July 2015 at 09:12, Ed Parsons <eparsons@google.com> wrote: > HI Frans - I hope I can *clarify*... > > > On Thu, 9 Jul 2015 at 14:25 Frans Knibbe <frans.knibbe@geodan.nl> wrote: > >> Hello Alejandro, >> >> The meeting at 2015-07-01 was used to discuss some UCR issues. I was not >> present at the meeting and now I am trying to make sense of the minutes. I >> am especially looking for decisions that should lead to changes in the UCR >> document. I hope you can help on the following points: >> >> >> 1) First there was the issue of the CRS definition requirement. A >> proposal was to rephrase it to "There should be a recommended way of >> referencing a CRS with a HTTP URI, and to get useful information about >> the CRS when that URI is dereferenced.". As far as I can tell, this >> phrasing did not make it to a proposal that could be voted on at the >> meeting. I think this means that ISSUE-10 >> <http://www.w3.org/2015/spatial/track/issues/10> will have to be >> discussed again at a next meeting. Can we do anything to help the group to >> make a decision? >> > > *It was my understanding that the revised phrasing was accepted with the > removal of the term "recommended"* > > > >> >> 2) An issue was raised regarding the default CRS requirement >> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DefaultCRS>: >> ISSUE-28 <https://www.w3.org/2015/spatial/track/issues/28>. I have just >> created a new list thread to discuss this issue. Personally I don't >> understand the problem yet, but I did see some evidence of mixing the >> requirement (a default CRS) with possibilities of meeting the >> requirement. I think the UCR document should be strictly about specifying >> what is needed, without looking at possible ways of making that happen. >> > > *I agree, this is not a requirement.* > > > >> >> 3) Then there is ISSUE-29 >> <https://www.w3.org/2015/spatial/track/issues/29>: should we add a >> requirement for being able to relate geometry to CRS? It looks that >> something has been decided on this issue, but it is not clear to me what >> that is. The proposal was "There should be a recommended way of linking a >> CRS to a vector geometry". Was that ever considered? An alternative >> phrasing I see is "all geometries shall be associated with a CRS", but I >> don't see how that can be a requirement. Perhaps it is best to create a >> separate e-mail thread for issue 29 too? >> > > *I agree this is a new separate issue that needs more discussions perhaps.* > > > >> >> 4) For the discussion in the 'Use of the word 'standard' in the UCR >> document >> <https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0211.html>' >> thread a new option has been suggested: "advice". I wonder how we can bring >> this discussion to an end. I propose we raise an issue about this subject >> in the tracker so that we can put making a group decision in the agenda for >> a next meeting. >> > > *Easy - Use the term advice rather than the specific terms "standard" or > "recommended way" - this allows the BP document to use what is appropriate > to fulfil each requirement.* > > > >> >> >> Greetings, >> Frans >> >> >> >> >> >> >> 2015-07-01 16:06 GMT+02:00 Phil Archer <phila@w3.org>: >> >>> The minutes of today's call are at >>> http://www.w3.org/2015/07/01-sdw-minutes. A snapshot is provided below. >>> >>> Thanks to Josh for scribing. >>> >>> >>> Spatial Data on the Web Working Group Teleconference >>> >>> 01 Jul 2015 >>> >>> See also: [2]IRC log >>> >>> [2] http://www.w3.org/2015/07/01-sdw-irc >>> >>> Attendees >>> >>> Present >>> eparsons, jtandy, MattPerry, Alejandro_Llaves, >>> joshlieberman, ahaller2, kerry, SimonCox, LarsG, Rachel, >>> IanHolt, cory, Cory, ThiagoAvila, PhilA >>> >>> Regrets >>> Andrea_Perego, Bart_van_Leeuwen, Chris_Little, >>> Clemens_Portele, Frans, Rachel_Heaven, payam, Bill >>> >>> Chair >>> Ed >>> >>> Scribe >>> joshlieberman >>> >>> Contents >>> >>> * [3]Topics >>> 1. [4]Approve Minutes >>> 2. [5]Patent Call >>> 3. [6]Combined CRS Issues >>> 4. [7]ANOB >>> * [8]Summary of Action Items >>> __________________________________________________________ >>> >>> <trackbot> Date: 01 July 2015 >>> >>> preent+ joshlieberman >>> >>> <phila> scribe: joshlieberman >>> >>> Approve Minutes >>> >>> <eparsons> [9]http://www.w3.org/2015/06/24-sdw-minutes.html >>> >>> [9] http://www.w3.org/2015/06/24-sdw-minutes.html >>> >>> <eparsons> PROPOSED: Accept last weeks minutes >>> >>> <eparsons> +1 >>> >>> <MattPerry> +1 >>> >>> <Alejandro_Llaves> +1 >>> >>> joshlieberman wasn't on the call >>> >>> <kerry> +1 >>> >>> <eparsons> RESOLVED: Accept last week's minutes >>> >>> <SimonCox> SimonCox not present >>> >>> Patent Call >>> >>> <eparsons> [10]https://www.w3.org/2015/spatial/wiki/Patent_Call >>> >>> [10] https://www.w3.org/2015/spatial/wiki/Patent_Call >>> >>> Combined CRS Issues >>> >>> <eparsons> 1)The CRS Definition requirement currently in the >>> UCR document should be rephrased. This is what ISSUE-10 is >>> about. The proposal for new wording is "There should be a >>> recommended way of referencing a CRS with a HTTP URI, and to >>> get useful information about the CRS when that URI is >>> dereferenced." >>> >>> <SimonCox> Do we need the word 'recommended'? >>> >>> jtandy: good to avoid parse-able URI >>> >>> <phila> phila: Notes that Frans' proposal was made at >>> [11]https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/ >>> 0228.html >>> >>> [11] >>> https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0228.html >>> >>> <SimonCox> +1 >>> >>> <SimonCox> +1 >>> >>> SimonCox: we don't need the "recommended" part >>> >>> <eparsons> There should be a way of referencing a CRS with a >>> HTTP URI, and to get useful information about the CRS when that >>> URI is dereferenced." >>> >>> <jtandy> +! >>> >>> <jtandy> +1 >>> >>> +q >>> >>> <SimonCox> There are multiple existing sources of CRS >>> definitions. Most of them are good. Do we intend to single out >>> one of them as 'recommended'? >>> >>> <ThiagoAvila> Hi for all. >>> >>> MattPerry: there should be "one" way >>> >>> <MattPerry> I can live with removal of "recommended" >>> >>> <Alejandro_Llaves> Me too >>> >>> <Zakim> phila, you wanted to show his ignorance >>> >>> <SimonCox> OGC does, but so do others >>> >>> <Alejandro_Llaves> +q >>> >>> jtandy: phila: doesn't OGC provide CRS URL's >>> >>> phila: should requirement also include what the URI returns? >>> >>> <Rachel> [made it after all, sorry a bit late!] >>> >>> <eparsons> Hi Rachel :-) >>> >>> Alejandro: OGC provides URI's but requirement can cover >>> problems "already solved" >>> >>> <eparsons> 2)In the course of discussing CRS requirements a new >>> BP requirement was introduced: Default CRS. No issues have been >>> raised with regard to this requirement yet. >>> >>> <SimonCox> [12]http://epsg.io [13]http://spatialreference.org >>> [14]http://www.opengis.net/def/crs/EPSG/0/ all good >>> >>> [12] http://epsg.io/ >>> [13] http://spatialreference.org/ >>> [14] http://www.opengis.net/def/crs/EPSG/0/ >>> >>> MattPerry: GeoSPARQL sets a default of WGS84 as represented in >>> OGC CRS84 >>> >>> <Alejandro_Llaves> The req. under discussion is described here >>> [15]http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirement >>> s.html#DefaultCRS >>> >>> [15] >>> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DefaultCRS >>> >>> <jtandy> joshlieberman: we need to decide what that default >>> would be >>> >>> <kerry> we do hav e issue-28 on this topic >>> >>> <jtandy> ... looking at usage, wgs84 is by far most common >>> >>> joshlieberman: the prevalence of CRS84 recommends the >>> practicality of a default >>> >>> <kerry> +q >>> >>> <kerry> yes >>> >>> kerry: WGS84 is most common, but not applicable to some use >>> cases. >>> ... prefer a simple reference over a default >>> >>> <jtandy> +1 >>> >>> <Rachel> +1 to Kerry >>> >>> <SimonCox> 'no default' would immediately invalidate all >>> GeoJSON (which _does_ have a default in fact) >>> >>> eparsons: many user communities do not include a reference and >>> a clear default might have helped with clarity >>> >>> <eparsons> 3)In the course of discussing CRS requirements a >>> possible new BP requirement has come up. ISSUE-29 (Add a >>> requirement for linking geometry to CRS) was raised to enable >>> further discussion and/or decision-making. >>> >>> SimonCox: no clear practice. GeoSPARQL inherits WKT and GML. >>> GeoJSON doesn't support geometry CRS's >>> >>> joshlieberman: geometry-level CRS anticipates multiple possible >>> geometries per spatial entity >>> >>> <jtandy> "all geometries shall be associated with a CRS" >>> >>> <Alejandro_Llaves> +1 >>> >>> <eparsons> +1 >>> >>> <MattPerry> +1 >>> >>> <SimonCox> +1 >>> >>> +1 >>> >>> <kerry> +1 >>> >>> <IanHolt> +1 >>> >>> <SimonCox> (what I meant was we need to say something about the >>> predicate, as well as the CRS resource ...) >>> >>> <eparsons> 4)Whether 'a recommend way' is the best expression >>> to be used in requirements is something that is discussed in >>> the thread Use of the word 'standard' in the UCR document. >>> >>> <kerry> itis documented in the tracker >>> >>> <phila> RESOLVED: That at the highest level, the BP doc will >>> say that "all geometries shall be associated with a CRS" >>> >>> <kerry> + >>> >>> joshlieberman: BP should strive to recommend "specification" >>> that at some times will be accepted standards >>> >>> <Alejandro_Llaves> +q >>> >>> kerry: prefer "advice" >>> >>> Alejandro: do the terms need to be in the requirements? >>> >>> <kerry> +1 >>> >>> kerry: term "advice" works for requirements. BP can then use >>> other terms for its "advice" >>> >>> <jtandy> +1 >>> >>> <MattPerry> +1 >>> >>> <SimonCox> Did we finish the 'default CRS' question? >>> >>> <Alejandro_Llaves> I can do that >>> >>> jtandy: we seem to have ducked the default CRS question and not >>> yet agreed whether to make it a requirement or not. >>> >>> <eparsons> Topic : Best Practices Skeleton >>> >>> <eparsons> >>> [16]https://www.w3.org/2015/spatial/wiki/Notes_for_Context#Sugg >>> ested_Skeleton >>> >>> [16] >>> https://www.w3.org/2015/spatial/wiki/Notes_for_Context#Suggested_Skeleton >>> >>> phila, not remembering how to create an action. Please >>> demonstrate... >>> >>> <phila> ACTION: Llaves to highlight that the default CRS issue >>> is unresolved, when next editing the UCR doc [recorded in >>> [17]http://www.w3.org/2015/07/01-sdw-minutes.html#action01] >>> >>> [17] http://www.w3.org/2015/07/01-sdw-minutes.html#action01] >>> >>> <trackbot> Created ACTION-55 - Highlight that the default crs >>> issue is unresolved, when next editing the ucr doc [on >>> Alejandro Llaves - due 2015-07-08]. >>> >>> <Alejandro_Llaves> thanks! >>> >>> jtandy: not sure that UCR content has sufficiently been >>> analyzed to create an appropriate skeleton / outline. >>> >>> joshlieberman: how do you characterize the "things" to form the >>> outline? >>> >>> jtandy: that should fall out of the analysis. >>> >>> joshlieberman: should we say "common practices" to cover? >>> >>> phila: there was analysis in Barcelona as far as the >>> requirements extraction. Question may be "is the list of >>> requirements complete?" >>> >>> joshlieberman: some examples of "dangling requirements" would >>> help. >>> >>> <Alejandro_Llaves> Well, there are some reqs. waiting to be >>> discussed and raised as issues. >>> >>> ANOB >>> >>> joshlieberman: is it initially a process of scrubbing the >>> requirements? >>> >>> <Alejandro_Llaves> That I assume will be discussed in >>> forthcoming calls. >>> >>> <Zakim> phila, you wanted to talk about TPAC >>> >>> jtandy: process for providing UCR draft feedback? >>> >>> phila: there is a comments tracker tool that can be used to >>> extract from email feedback (as part of WG review) >>> >>> joshlieberman: for OGC public documents (standards or other) >>> the public can provide feedback either on a mailing list or >>> through the Change Request mechanism. Members of the WG will >>> then need to review and transfer to W3C list / tool >>> >>> phila: working document only lists the W3C list (needs to be >>> corrected). >>> >>> <phila> ACTION: phila to update UCR snapshot with >>> public-comments list ASAP [recorded in >>> [18]http://www.w3.org/2015/07/01-sdw-minutes.html#action02] >>> >>> [18] http://www.w3.org/2015/07/01-sdw-minutes.html#action02] >>> >>> <trackbot> Created ACTION-56 - to update ucr snapshot with >>> public-comments list asap [on Phil Archer - due 2015-07-08]. >>> >>> <scribe> ACTION: ed to monitor OGC channels for feedback on the >>> UCR draft once released as an OGC document [recorded in >>> [19]http://www.w3.org/2015/07/01-sdw-minutes.html#action03] >>> >>> [19] http://www.w3.org/2015/07/01-sdw-minutes.html#action03] >>> >>> <trackbot> Created ACTION-57 - Monitor ogc channels for >>> feedback on the ucr draft once released as an ogc document [on >>> Ed Parsons - due 2015-07-08]. >>> >>> <LarsG> bye, thanks >>> >>> <Alejandro_Llaves> thanks, bye! >>> >>> <Rachel> bye >>> >>> <eparsons> bye ! >>> >>> bye, thanks >>> >>> <IanHolt> bye >>> >>> <SimonCox> Regrets for next week >>> >>> <SimonCox> school holidays >>> >>> Summary of Action Items >>> >>> [NEW] ACTION: ed to monitor OGC channels for feedback on the >>> UCR draft once released as an OGC document [recorded in >>> [20]http://www.w3.org/2015/07/01-sdw-minutes.html#action03] >>> [NEW] ACTION: Llaves to highlight that the default CRS issue is >>> unresolved, when next editing the UCR doc [recorded in >>> [21]http://www.w3.org/2015/07/01-sdw-minutes.html#action01] >>> [NEW] ACTION: phila to update UCR snapshot with public-comments >>> list ASAP [recorded in >>> [22]http://www.w3.org/2015/07/01-sdw-minutes.html#action02] >>> >>> [20] http://www.w3.org/2015/07/01-sdw-minutes.html#action03 >>> [21] http://www.w3.org/2015/07/01-sdw-minutes.html#action01 >>> [22] http://www.w3.org/2015/07/01-sdw-minutes.html#action02 >>> >>> >> >> >> -- >> Frans Knibbe >> Geodan >> President Kennedylaan 1 >> 1079 MB Amsterdam (NL) >> >> T +31 (0)20 - 5711 347 >> E frans.knibbe@geodan.nl >> www.geodan.nl >> disclaimer <http://www.geodan.nl/disclaimer> >> >> -- > > > *Ed Parsons* Geospatial Technologist, Google > > Mobile +44 (0)7825 382263 > www.edparsons.com @edparsons > -- Alejandro Llaves Ontology Engineering Group (OEG) Artificial Intelligence Department Universidad Politécnica de Madrid Avda. Montepríncipe s/n Boadilla del Monte, 28660 Madrid, Spain http://www.oeg-upm.net/index.php/phd/325-allaves allaves@fi.upm.es
Received on Friday, 10 July 2015 08:54:35 UTC