Re: Wanted: feedback on UCR requirements

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