Re: Issue-10 unresolved in meeting today

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>