Re: Wanted: feedback on UCR requirements

Hello Matt, all,

I have just created issue-70
<https://www.w3.org/2015/spatial/track/issues/70>, for further discussion
of a requirement for avoiding coordinate transformations. If the tracker
does not generate a new e-mail thread for that issue I will create one, so
we can exchange thoughts over there.

Regards,
Frans



On 14 July 2016 at 15:42, matthew perry <matthew.perry@oracle.com> wrote:

> Frans,
>
> Thanks for making the change. You make a good point about another
> requirement. I would personally like such a requirement. Something like
> "When possible, spatial data should be made available in commonly used
> spatial reference systems (e.g., CRS84) to allow for easier integration
> with spatial data from different sources". I guess my wording is more of a
> recommendation than requirement.
>
> I'm not sure if we would have majority support for this requirement though
> since it's getting close to a default CRS.
>
> Cheers,
> Matt
>
> On 7/14/2016 5:13 AM, Frans Knibbe wrote:
>
> Thank you Matt. I will solve issue 28 by changing the requirement to the
> suggested wording. And I will search for other use cases that have the same
> requirement.
>
> So you don't think that next to the requirement for always being able to
> determine the CRS another requirement is needed, calling for (a) best
> practice(s) for avoiding coordinate transformations when combining
> geometric data from different sources?
>
> Regards,
> Frans
>
>
>
> On 13 July 2016 at 20:08, matthew perry <matthew.perry@oracle.com> wrote:
>
>> Hi Frans,
>>
>> I agree that the core requirement from issue 28 is that users should
>> always be able to determine what CRS is used. Without such information,
>> there's not much hope for integration. I am fine with this new wording.
>>
>> I think suggestion #1 from Jon is a good way to promote a "default" CRS
>> without trying to assert that data without an explicit CRS should be
>> interpreted as CRS84.
>>
>> Thanks,
>> Matt
>> On 7/13/2016 12:33 PM, Jon Blower wrote:
>>
>> Hi Frans,
>>
>>
>>
>> I haven’t followed the previous discussions in detail I’m afraid, but in
>> my mind a “Best Practice” around CRS might look like this:
>>
>>
>>
>> 1.       If your goal is to make data available to mass-market web
>> users, make it available in CRS84, but be aware (and perhaps publish) the
>> limitations of doing so.
>>
>> 2.       If your goal is high accuracy, choose the best CRS for your
>> data.
>>
>> 3.       Publishing data in multiple CRSs is fine, and may help users to
>> combine your data with other sources, as well as serving multiple types of
>> user.
>>
>> 4.       Always explicitly state which CRS(s) you are using. [I don’t
>> think a default CRS should be recommended]
>>
>>
>>
>> If multiple CRS are used we may need a mechanism to communicate which CRS
>> is “preferred” in terms of accuracy.
>>
>>
>>
>> Does this help? I’ve deliberately been neutral about the mechanism by
>> which the above could be communicated, because users might get such
>> information in multiple ways.
>>
>>
>>
>> Cheers,
>> Jon
>>
>>
>>
>> *From: *Frans Knibbe <frans.knibbe@geodan.nl> <frans.knibbe@geodan.nl>
>> *Date: *Wednesday, 13 July 2016 15:13
>> *To: *Linda van den Brink <l.vandenbrink@geonovum.nl>
>> <l.vandenbrink@geonovum.nl>, matthew perry <matthew.perry@oracle.com>
>> <matthew.perry@oracle.com>
>> *Cc: *SDW WG Public List <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
>> *Subject: *Re: Wanted: feedback on UCR requirements
>> *Resent-From: *<public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
>> *Resent-Date: *Wednesday, 13 July 2016 15:14
>>
>>
>>
>> Hello Linda, Matt,
>>
>>
>>
>> Thanks to the BP editors for taking time to look at these issues. The
>> solution to issue 28 looks sensible to me, but I would like to ask Matt if
>> he agrees with the change. The requirement for a default/canonical CRS
>> comes directly from the use case Combining spatial RDF data for
>> integrated querying in a triplestore
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#CombiningSpatialRDFDataForIntegratedQueryingInATriplestore>,
>> which Matt contributed. It seems to me that if the requirement in its new
>> wording is met, the problem of having to do coordinate transformations (for
>> instance in federated SPARQL queries) still exists. So I wonder if the new
>> wording does justice to the use case.
>>
>>
>>
>> I think the problem of having to perform coordinate transformation when
>> combining datasets could also be solved by recommending using multiple CRSs
>> in data publications. A procedure for combining data from two data sets
>> would then have a higher chance of finding a CRS that both data sets have
>> in common. Having good standards for making the CRS known of course would
>> help a lot in that process, and the requirement in its new wording would
>> help there.
>>
>>
>>
>> Another way of mitigating the problem of having to transform coordinates
>> would be to have a more general lat-lon CRS than the likes of ETRS89 and
>> WGS84, which could not be used for high precision data but could aid
>> interoperabilty.
>>
>>
>>
>> So if we acknowledge that there could be different solutions for the
>> problem of having to perform coordinate transformation when combining data,
>> would that mean there is room for a new requirement that specifies the
>> problem and does not hint at possible solutions? For example
>> "Recommendations or standards are needed to avoid having to transform
>> coordinates when data from different sources are combined"?
>>
>>
>>
>> Regards,
>>
>> Frans
>>
>>
>>
>> On 12 July 2016 at 16:17, Linda van den Brink <l.vandenbrink@geonovum.nl>
>> wrote:
>>
>> Hi Frans,
>>
>>
>>
>> We (the BP editors) have discussed the BP issues and concluded:
>>
>> -          issue 23: We think this issue can be closed because in our
>> view the wording as it currently is for this requirement in the UCR is
>> fine. We will try to address the questions that are raised in the issue in
>> the BP. I created an issue in Github so we don’t forget.
>> https://github.com/w3c/sdw/issues/298
>>
>> -          issue 28: The requirement according to us three is: “that
>> clients or users must always be able to determine what CRS is used.” This
>> could be because it’s present in the data in some form, or because it’s
>> determined by the spec (and this could be that if unspecified in the data,
>> there’s some default).  In the BP we will go into the question of when a
>> more precise CRS than WGS84 is needed. We hope this helps us resolve the
>> issue.
>>
>>
>>
>> Linda
>>
>>
>>
>> *Van:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
>> *Verzonden:* woensdag 6 juli 2016 15:01
>> *Aan:* Jeremy Tandy; Linda van den Brink; Payam Barnaghi; Simon Cox;
>> Chris Little; Krzysztof Janowicz; Armin Haller; danh.lephuoc@deri.org;
>> Bill Roberts; Kerry Taylor
>> *CC:* SDW WG Public List
>> *Onderwerp:* Re: Wanted: feedback on UCR requirements
>>
>>
>>
>> Dear editors,
>>
>>
>>
>> I haven't had much response to my question so far. So as an aid, here is
>> a list of the open issues marked in the current UCR draft:
>>
>>
>> <https://www.w3.org/2015/spatial/track/issues/20>
>>
>> ISSUE-20 <https://www.w3.org/2015/spatial/track/issues/20> (SSN)
>>
>> ISSUE-23 <https://www.w3.org/2015/spatial/track/issues/23> (Best
>> Practices)
>>
>> ISSUE-24 <https://www.w3.org/2015/spatial/track/issues/24> (SSN)
>>
>> ISSUE-26 <https://www.w3.org/2015/spatial/track/issues/26> (Time)
>>
>> ISSUE-28 <https://www.w3.org/2015/spatial/track/issues/28> (Best
>> Practices)
>>
>>
>>
>> Wouldn't it be nice if we can resolve these issues before the next and
>> final PWD of the UCR document this month?
>>
>>
>>
>> Regards,
>>
>> Frans
>>
>>
>>
>>
>>
>>
>>
>> 2016-06-22 13:12 GMT+02:00 Frans Knibbe <frans.knibbe@geodan.nl>:
>>
>> Dear editors of the BP/Time/SSN/Coverage deliverable,
>>
>>
>>
>> In preparation of a next public working draft of the UCR document I would
>> like to ask you for feedback on the requirements for your deliverable as
>> specified in the UCR document. Section 6
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#RequirementsByDeliverable>
>> list requirements grouped by deliverable. By now you will have stared long
>> & hard at those requirements, and perhaps you concluded that some or not
>> clear yet, or that something else is wrong. Perhaps requirements or even
>> important use cases are missing?
>>
>>
>>
>> While we are working on a new batch of publications before TPAC, it would
>> be nice if the requirements in the UCR document are (among) the ones you
>> are actually working with. I think the public we are writing for deserves
>> that coherence. I presume your deliverables will link back to the UCR
>> document and explain how requirements are met or why requirements are not
>> met. So if you think any changes are required in the UCR document resulting
>> from your work on your deliverable, please inform me.
>>
>>
>>
>> Thanks,
>>
>> Frans
>>
>>
>>
>>
>>
>>
>>
>
>