Re: Issue-10 unresolved in meeting today

2015-06-29 13:29 GMT+02:00 Ed Parsons <eparsons@google.com>:

> Frans,
>
> Do you think it would be possible to present the now three? CRS related
> requirements again this week ?  I think we are actually quite close to
> agreement potentially ?
>

Yes, it seems we are close to agreement. But I can not join the meeting
this time, I have another commitment. What I could do is prepare a summary
to facilitate decision making at the meeting.

Regards,
Frans


> Thanks
>
> Ed
>
>
> On Mon, 29 Jun 2015 at 09:14 Ed Parsons <eparsons@google.com> wrote:
>
>> Hi Frans,
>>
>> I'm happy with that approach, an additional but linked requirement seems
>> to be clearer..
>>
>> Ed
>>
>>
>> On Mon, 29 Jun 2015 at 09:06 Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>>> 2015-06-29 0:37 GMT+02:00 <Simon.Cox@csiro.au>:
>>>
>>>>  Ø  I mildly dislike 3 as it is already covered by 2, so redundant.
>>>>
>>>>
>>>>
>>>> Disagree. To be able to reference a CRS description with a URI says
>>>> nothing about how such a reference would be associated with a geometry.
>>>>
>>>>
>>>>
>>>> There is a definite lack of consensus here. For example, GeoJSON had a
>>>> CRS object that applied to the file as a whole [1], though this is now
>>>> deprecated, probably in favour of a JSON-LD solution [2][3]. Meanwhile,
>>>> GeoSPARQL [4], though its adoption of WKT and GML, enables (but does not _
>>>> *require*_) a CRS to be associated with each geometry, separately. All
>>>> of these can use URIs, but the pattern for attaching the CRS to the
>>>> geometry is different.
>>>>
>>>
>>> Yes, associating a geometry with a CRS is not something
>>> straightforward. How tight the two should be coupled is prime material for
>>> debate. So how about making this a new requirement? Something like:
>>>
>>> "There should be a recommended way of linking a CRS to a vector
>>> geometry"
>>>
>>> I think a separate requirement is better than adding a new element to
>>> the existing requirement.
>>>
>>> If we adopt this extra requirement I think we should note its
>>> relationship with the Encoding for vector geometry requirement
>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#EncodingForVectorGeometry>
>>> .
>>>
>>> Regards,
>>> Frans
>>>
>>>
>>>
>>>>
>>>> Ø  4 … is already recorded as separate issue  issue-28,
>>>>
>>>>
>>>>
>>>> Good. My intention in making the list was to ensure that the CRS
>>>> requirements were gathered together. Else there is a risk that the
>>>> sum-of-the-parts don’t make a whole.
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> [1]
>>>> http://geojson.org/geojson-spec.html#coordinate-reference-system-objects
>>>>
>>>> [2] https://datatracker.ietf.org/doc/draft-butler-geojson/
>>>>
>>>> [3] https://github.com/geojson/geojson-ld/issues/27
>>>>
>>>> [4] http://www.opengeospatial.org/standards/geosparql
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Kerry Taylor [mailto:Kerry.Taylor@acm.org]
>>>> *Sent:* Saturday, 27 June 2015 9:48 PM
>>>> *To:* SDW WG Public List
>>>> *Subject:* Fwd: Issue-10 unresolved in meeting today
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  -5 from me.
>>>>
>>>> We have gone round in circles.
>>>>
>>>>
>>>>
>>>> I have no objection to 1 and 2, noting that we seem to have lost the
>>>> http uri part again, which was rather well supported.
>>>>
>>>>
>>>>
>>>> I mildly dislike 3 as  it is already covered by 2, so redundant.
>>>>
>>>>
>>>>
>>>> I dislike 4 because it puts us back where we started before the last
>>>> meeting. can we separate the concern of mandatory or not? this was quite
>>>> controversial when discussed on the email list some time ago.   This is
>>>> already recorded as separate issue   issue-28, but could certainly be
>>>> worded better.
>>>>
>>>>
>>>>
>>>> Kerry
>>>>
>>>>
>>>>
>>>>
>>>> On 26 Jun 2015, at 10:34 pm, matthew perry <matthew.perry@oracle.com>
>>>> wrote:
>>>>
>>>>
>>>> On 6/26/2015 5:06 AM, Andrea Perego wrote:
>>>>
>>>>  On Fri, Jun 26, 2015 at 10:06 AM,  <Simon.Cox@csiro.au> wrote:
>>>>
>>>>   Then, the requirement is:
>>>>
>>>>   1.
>>>>
>>>>   to be able to reference a CRS with a URI, and
>>>>
>>>>   2.
>>>>
>>>>   to get useful information about the CRS when you dereference that
>>>> URI.
>>>>
>>>>   Then there are at least two more requirements:
>>>>
>>>>   3. a mechanism to associate a CRS reference with a geometry
>>>> description
>>>>
>>>>   4. for there to be a default or implied CRS reference where it is
>>>> not explicit in the data.
>>>>
>>>>  +1
>>>>
>>>>
>>>>
>>>>  Andrea
>>>>
>>>>
>>>>
>>>> +1 from me too.
>>>>
>>>> Matt
>>>>
>>>>
>>> --
>>> 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
>>
> --
>
> Ed Parsons
> Geospatial Technologist, Google
>
> Mobile +44 (0)7825 382263
> www.edparsons.com @edparsons
>



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