Re: Issue-10 unresolved in meeting today

Thanks so much Frans that would be great..

ed


On Mon, 29 Jun 2015 at 12:58 Frans Knibbe <frans.knibbe@geodan.nl> wrote:

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

Ed Parsons
Geospatial Technologist, Google

Mobile +44 (0)7825 382263
www.edparsons.com @edparsons