Re: [Minutes] 2017-07-01

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

Received on Friday, 10 July 2015 07:13:17 UTC