Re: Wanted: feedback on UCR requirements

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.


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 <>
> *Date: *Wednesday, 13 July 2016 15:13
> *To: *Linda van den Brink <>, matthew perry 
> <>
> *Cc: *SDW WG Public List <>
> *Subject: *Re: Wanted: feedback on UCR requirements
> *Resent-From: *<>
> *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 
> <>, 
> 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 
> < <>> 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.
>     -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 [
>     <>]
>     *Verzonden:* woensdag 6 juli 2016 15:01
>     *Aan:* Jeremy Tandy; Linda van den Brink; Payam Barnaghi; Simon
>     Cox; Chris Little; Krzysztof Janowicz; Armin Haller;
> <>; 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:
>     <>
>     ISSUE-20 <> (SSN)
>     ISSUE-23 <> (Best
>     Practices)
>     ISSUE-24 <> (SSN)
>     ISSUE-26 <> (Time)
>     ISSUE-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 <
>     <>>:
>     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
>     <>
>     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

Received on Wednesday, 13 July 2016 18:09:08 UTC