Re: Issue-10 unresolved in meeting today

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