W3C home > Mailing lists > Public > public-sdwig@w3.org > January 2021

RE: Agenda items for SDWIG this Thursday 7th of January 2021

From: Little, Chris <chris.little@metoffice.gov.uk>
Date: Wed, 6 Jan 2021 12:01:31 +0000
To: Linda van den Brink <l.vandenbrink@geonovum.nl>
CC: Peter Parslow <Peter.Parslow@os.uk>, "Rushforth, Peter (NRCan/RNCan)" <peter.rushforth@canada.ca>, "Tandy, Jeremy" <jeremy.tandy@metoffice.gov.uk>, "ted@w3.org" <ted@w3.org>, Clara Boyd <clara.boyd@os.uk>, public-sdwig <public-sdwig@w3.org>, Clemens Portele <portele@interactive-instruments.de>
Message-ID: <LO3P265MB2188BC11A21AF2AF0A45DB22A7D00@LO3P265MB2188.GBRP265.PROD.OUTLOOK.COM>
Excellent topic for discussion. Thank you Peter.

Further to Clemens’ comments, I suggest ‘scale of interest’, not just geometry simplification, as a service may have to make a decision to retrieve more features, or more detailed features, to populate a map at a higher resolution.

De-cluttering AND cluttering!

Chris

From: Clemens Portele <portele@interactive-instruments.de>
Sent: 05 January 2021 17:13
To: Linda van den Brink <l.vandenbrink@geonovum.nl>
Cc: Peter Parslow <Peter.Parslow@os.uk>; Rushforth, Peter (NRCan/RNCan) <peter.rushforth@canada.ca>; Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk>; ted@w3.org; Clara Boyd <clara.boyd@os.uk>; public-sdwig <public-sdwig@w3.org>
Subject: Re: Agenda items for SDWIG this Thursday 7th of January 2021


This email was received from an external source.   Always check sender details, links & attachments.
Hi all,

a few comments:

* Best Practice 12 is about designing APIs to specific needs of the intended consumers of the API. Geometry and CRS aspects are just one of the aspects to consider. The current text of the Best Practice already has this:

For geometries with many coordinates, simplifying the geometries for display at large map scales - think about all administrative boundaries of Europe on a map display with scale 1:30,000,000 - is another option; the simplification may be controlled by the client using a query parameter indicating the target scale; geometry simplification including its caveats are discussed in Best Practice 5: Provide geometries on the Web in a usable way.

* I do not see scale/resolution/zoom level as part of the CRS definition, these are separate concepts. But an individual geometry can be associated with a CRS and a scale/resolution/zoom level. And a DGGS or 2D tiling scheme are both based on a CRS and a range of scales/resolutions/zoom levels.

* Since Linda mentioned OGC API standards: Requests to tiles (in OGC API Tiles) include the zoom level of the tile (OGC calls it the "tile matrix"). Most OGC API Features implementations that I am aware of already have the capability to request geometries for a target scale as described in the current Best Practice 12, but there is no agreed specification yet. The Features API SWG has proposed to add a new task to the charter to add a new part to standardize this capability (we are waiting for approval by the OGC membership):

A new part "Geometry simplification" will specify a query parameter to indicate a scale or zoom level at which the features will be displayed (resources Features and Features). The returned curve/surface/solid geometries will be simplified accordingly. The planned schedule is: Public Review by October 2021.

Best regards,
Clemens

Am 05.01.2021 um 17:35 schrieb Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>>:

Hi Peter R.,

I will put it on the agenda.

I think, as Peter P says, that it may be better not to conflate CRS with zoom levels, but I do see your point that it would be useful if convenience APIs have a parameter for scale.

In the SDWBP we currently talk about zoom levels in Best Practice 6: Provide geometries at the right level of accuracy, precision, and size, BP 13 about metadata, where we mention spatial resolution as something to document for datasets, and BP 14 about how to document positional accuracy. However, nothing is mentioned in the BP about convenience APIs yet.

I wonder if/how the OGC APIs deal with this – I don’t think the Features API, the one I read most thoroughly, addresses this.

Linda

Van: Peter Parslow <Peter.Parslow@os.uk<mailto:Peter.Parslow@os.uk>>
Verzonden: dinsdag 5 januari 2021 11:01
Aan: Rushforth, Peter (NRCan/RNCan) <peter.rushforth@canada.ca<mailto:peter.rushforth@canada.ca>>; Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>>; jeremy.tandy@metoffice.gov.uk<mailto:jeremy.tandy@metoffice.gov.uk>; ted@w3.org<mailto:ted@w3.org>; Clara Boyd <clara.boyd@os.uk<mailto:clara.boyd@os.uk>>
CC: public-sdwig <public-sdwig@w3.org<mailto:public-sdwig@w3.org>>
Onderwerp: RE: Agenda items for SDWIG this Thursday 7th of January 2021

Peter,
CRS is only one part of what makes a given tile / map / dataset useful at only certain scales (zoom levels); it’s also a matter of how accurately the data was collected in the purpose, how much the data has been generalised, and to some extent, what it was collected for.

So for example, we (OS) have data in our own “British National Grid” (a projected grid reference system) and ETRS-89 (an earth-fixed Cartesian system) at various scales / zoom levels. Same CRS, different amounts of detail.

I suspect that the convenience APIs need to have separate parameters for CRS and ‘scale’, and this is the approach taken by those APIs that I know. So a ‘data set’ should be documented with both CRS and ‘acceptable zoom level’ in some way, so that a request to zoom in further than the publisher considers reasonable can be refused.

I do know that the DGGS (Distributed Global Grid System) people are looking at the relationship between ‘cell size’ and underlying CRS – in the sense that some CRSs are in their nature not too good for “zooming in” too close (in their world, having a smaller cell size).

Peter Parslow
OS Open Standards Lead
Adanac Drive, Southampton, United Kingdom, SO16 0AS
T: +44 (0)2380 055341 | M: +44 (0)7796 610020
www.os.uk<http://os.uk/> | peter.parslow@os.uk<mailto:peter.parslow@os.uk>

From: Rushforth, Peter (NRCan/RNCan) <peter.rushforth@canada.ca<mailto:peter.rushforth@canada.ca>>
Sent: 04 January 2021 21:24
To: Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>>; jeremy.tandy@metoffice.gov.uk<mailto:jeremy.tandy@metoffice.gov.uk>; ted@w3.org<mailto:ted@w3.org>; Clara Boyd <clara.boyd@os.uk<mailto:clara.boyd@os.uk>>
Cc: public-sdwig <public-sdwig@w3.org<mailto:public-sdwig@w3.org>>
Subject: RE: Agenda items for SDWIG this Thursday 7th of January 2021

External Email: Take care with attachments & links.

Hi Linda, all,

Best wishes for 2021!

I was wondering if we might have a conversation about Best practice 12 – convenience APIs.  I was going to raise an issue, but it might be better to explain what my idea is before doing that, so as to get person to person feedback.

Basically it’s this: maps on the Web are a new thing, compared with some of the standards for spatial information, such as CRS definitions, feature services and others.

When I look at CRS definitions, they don’t have any definition of scale, or resolution.  I think this may be a hold-over from the GIS era, where metadata and data were simultaneously available on the client, so that data could be rendered at any scale, transparently.  In any case, I think it might be convenient to define a set of known or recommended scale sets to be associated to a CRS, in a similar way that WMTS does.  This way, services such as feature services and so on, would be able to rely on known scale sets from the CRS definition.  Further, having a scale set built into a CRS definition would push service standards to consider how to best transmit the required scale / resolution over the Web in their definition.

My question is: is this possible? Reasonable?  What are the constraints on such a proposal?  Could this be requested of the OGC community if the SDW thinks it worthy of consideration?


Thank you,

Peter

Peter Rushforth
Technology Advisor
Canada Centre for Mapping and Earth Observation



From: Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>>
Sent: January 4, 2021 05:20
To: Clara Boyd <clara.boyd@os.uk<mailto:clara.boyd@os.uk>>; jeremy.tandy@metoffice.gov.uk<mailto:jeremy.tandy@metoffice.gov.uk>; ted@w3.org<mailto:ted@w3.org>; eparsons@google.com<mailto:eparsons@google.com>; Joseph Abhayaratna <joseph.abhayaratna@geoscape.com.au<mailto:joseph.abhayaratna@geoscape.com.au>>
Cc: public-sdwig <public-sdwig@w3.org<mailto:public-sdwig@w3.org>>
Subject: Agenda items for SDWIG this Thursday 7th of January 2021

Hi all,

First of all the best wishes for 2021!

I’m sure most of you are just getting started again and have a pile of email to get through! I just wanted to ask of you have any agenda items for the SDWIG this Thursday.

In a separate email, I already asked Ed/Jo for an update on the responsible use of spatial data Note, of which they want to publish the first draft very soon. Ed or Jo can you confirm?

Clara can you give an update on SDWBP work?

Suggestions from other group members for the agenda are also welcome.

Last month we had a joint call with the Web of Things group, this will be followed up in a separate meeting I expect. I could give a short recap if people want.

Linda




This email and any attachments are intended only for the intended recipient and may contain sensitive information. If you are not the intended recipient, please immediately delete this email and inform the sender.

OS email communications may be monitored to ensure the secure and effective operation of our systems and for other lawful purposes. Subject to contract: No rights are to be derived from any proposal contained in this email until a written agreement containing all necessary terms is executed between the relevant parties.

Thank you for your cooperation.

Ordnance Survey Limited (Company Registration number 09121572)
Registered Office: Explorer House
Adanac Drive
Southampton SO16 0AS
Tel: 03456 050505
http://www.os.uk<http://www.os.uk/>

Received on Wednesday, 6 January 2021 12:01:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 6 January 2021 12:02:01 UTC