Ah, sorry Frans, I’m trying to dip in and out of these conversations and getting a bit confused about their scope. Sorry for the noise!




From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Thursday, 14 July 2016 10:03
To: Jon Blower <sgs02jdb@reading.ac.uk>
Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, matthew perry <matthew.perry@oracle.com>, SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: Wanted: feedback on UCR requirements


Thank you Jon. My concern in this thread is mainly the Use Cases & Requirements, so it is about stating current problems and wishes and not so much about how to solve problems and how to make wishes come true. But your points provide good input for the BP editors, who are reading along of course.





On 13 July 2016 at 18:33, Jon Blower <j.d.blower@reading.ac.uk> 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.




From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wednesday, 13 July 2016 15:13
To: Linda van den Brink <l.vandenbrink@geonovum.nl>, matthew perry <matthew.perry@oracle.com>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: Wanted: feedback on UCR requirements
Resent-From: <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, 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"?





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.




Van: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Verzonden: woensdag 6 juli 2016 15:01
Aan: Jeremy Tandy; Linda van den Bri
nk; 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:


ISSUE-23 (Best Practices)


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?







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 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.