Re: Issue-10 unresolved in meeting today

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 ?

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