- From: matthew perry <matthew.perry@oracle.com>
- Date: Thu, 14 Jul 2016 09:42:35 -0400
- To: public-sdw-wg@w3.org
- Message-ID: <9ad402d0-a2f4-91a3-7dcc-a48aa9e7e984@oracle.com>
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 > <mailto: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> >> <mailto:frans.knibbe@geodan.nl> >> *Date: *Wednesday, 13 July 2016 15:13 >> *To: *Linda van den Brink <l.vandenbrink@geonovum.nl> >> <mailto:l.vandenbrink@geonovum.nl>, matthew perry >> <matthew.perry@oracle.com> <mailto:matthew.perry@oracle.com> >> *Cc: *SDW WG Public List <public-sdw-wg@w3.org> >> <mailto:public-sdw-wg@w3.org> >> *Subject: *Re: Wanted: feedback on UCR requirements >> *Resent-From: *<public-sdw-wg@w3.org> <mailto: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 <mailto: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 >> <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 <mailto: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 <mailto: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 >> > >
Received on Thursday, 14 July 2016 13:43:15 UTC