07 January 2021


Chris, Christine, Clara, ClemensPortele, Joost, jtandy, Linda, Peter, RobS, Ted
Bill, Scott
Jeremy, Linda

Meeting minutes

Tile Zoom Level

Peter: it is important for MapML to have coordinate and tile matrix sets together
… EGSP data set is separate from the notion of scale. whenever GIS data is used, scale is vital for visual representation on map
… it would be convenient if the coordinate system recommendation had concept of scaling
… having scales or resolutions recommended would be helpful for consumption
… web feature service without notion of scale you get highest resolution possible which may not be appropriate for certain uses

Chris: I raised that with OGC API for tiles. they have been focused on styles etc

<ClemensPortele> Chris, this is not a tiles issue, its a maps issue

Chris: I am trying to get them to revisit
… it is desireable to request tiles at a given scale that is device capability compatible
… in short, I agree with you

Peter: as I mentioned in my email, the standardized definition probably dates back to GIS era when you typically already had local to desktop/workstation the different scaled resources

Peter's email

Jeremy: coordinate reference system is needed as well as scale as you called it
… I think it was in Clemens' email that we should not bind these too closely together
… you cite the WFS work and want these concepts combined

Clemens' email

Clemens: I think the CRS come from survey era which predates GIS

<ChrisLittle> present ChrisLittle

Clemens: these are reference systems and don't need a scale but provide eg limited accuracy
… CRS don't really have a scale component to them
… at some scale or zoom level, certain features or information should be suppressed
… for tiling, each is at a certain zoom level and hierarchy is defined with accompanying OGC standards
… scale or zoom level is supported in many APIs
… we have a call for review on work items. we are focusing on geometry simplification
… welcome proposals for handling feature/scale relationship
… this can also be addressed in Best Practices revision

Peter: some WFS do support scale/zoom as a parameter
… some features are either too small or big
… how you model your data need to take into consideration having feature disappear at a certain scale for instance
… data modeler needs to know the recommended scales. we can use inheritance model

<Zakim> jtandy, you wanted to ask PR to describe what he can't do with today's APIs

Jeremy: if I'm using a coordinate reference system, what you're saying is there should be a set of zoom scales that are recommended for use with that particular CRS

Peter: correct

Jeremy: for a given municipality, the data is limited and others at eg a county zoom level
… is the choice of CRS coupled to choice of zoom scale or zoom scale to application you are trying to support?

Peter: good question
… agree there could be scale recommendations from town level in British National Grid

<cboyd> You did a better job than I could Jeremy

Jeremy: you are positing there are a number of data providers and with scaling we can overlay them reasonably well

Peter: I'm unaware of ETRS89 but guess you would have to reproject data for combining

Jeremy: a consistent set of zoom levels would be preferable across different data providers then?

Peter: yes

Jeremy: if I have a list of zoom levels somewhere, would that help?
… encouraging people to publish data at specific zoom levels?

Clemens: I think we are the wrong group of people to raise that. we should discuss with CRS
… they have a concept of scope
… there are regionally appropriate systems, eg the British National Grid isn't as useful in Germany
… I don't think it is a CRS issue. if anything gets added to its definition, it should come from CRS group

Peter: fair enough

Jeremy: as a data publisher, you have control over the server and should have additional meta data available

Clemens: you can unlimited zoom detail but then reasonably depending on data you may restrict information to specific zoom level
… this is a conscious decision already being used

Jeremy: zoom level already expressed in that case?

Clemens: Google's tiling scheme that is widely used
… OGC doesn't call it zoom level but tile metrics which isn't immediately intuitive

Jeremy: agree. anyone wanting to publish with web mercator (sp? google's tile scheme) can include level

Clemens: the zoom level from their tiling scheme differs from others with their own conventions
… how do we express zoom level?


Jeremy: how do we combine data from different schemes and data providers?
… a list of scales coupled to CRS is one way, another by an algorithm from Web Features standard

Clemens: the scale range you want to support when you publish your feature data is not dependent on CRS

Jeremy: we are not trying to line up pixelated tiles

Chris: I want to respond to an earlier comment of Clemens'
… what sort of device am I using and what do I want to see on it
… cluttering/decluttering is a decision of the client application and zoom level mucks that up
… Clemens wants to simplify geometry from a set of features. that is separate from a filtering aspect

<jtandy> (I guess the ultimate geometry simplification is down to a point ... and then client applications could determine how to deal with situations where many point features are too close together?)

Clemens: from features API perspective, if feature shown as a certain zoom level is part of it
… at some zoom level or scale you would simply show a point. you would not return certain features at a given scale level
… adjacent polygons with attributes can be returned as you zoom out
… filtering features and getting them ready is server side, combining is post processing

Jeremy: at simplest scale a geometry can be a single point and it is still related to a set of features

Clemens: correct but dependent on zoom level, point could be an airport but when you zoom in have more detail
… if you zoom out to a certain level you would want to only present certain, larger airports and suppress others
… this filtering requires extra knowledge and there is a question if we should even do this

Linda: I am trying to relate to SDWBP
… it is only partially related and the rest about visualization and user interaction

Clemens: it is related to the convenience API
… you need to think about how people want to interact with your data. we already have text along these lines we might want to expand
… how to make data more usable. you may want to return different data if it is to be used for mapping for instance

Peter: would it be convenient to have recommended scale sets attached to CRS for those who want to make a feature service
… you know you are going to have to generated tiled features
… this is why I am suggesting/asking for advice
… sounds like we should discuss with CRS group

Clemens: not sure it is the right thing. scale depends on the data not on the CRS
… still could be worth discussing with that group to get their opinion

Jeremy: how you want to present data is often closely related to type of application[s] you want to support

<ChrisLittle> +1 to clemens - data linked not CRS

<RobSmith> +1

Jeremy: do we want to engage the CRS folks?
… Peter you want us to put you in touch with them?

Peter: sure and can bring back here response

[Clemens provides suggestion on specific OGC group and individual to contact]

Peter: I have corresponded with Roger before, comfortable talking with him directly and will report back

Jeremy: any other topics for today?

Linda: Responsible Use Note
… believe we are ready to publish

Ted: @@Ed, timing

RobS: we want to get feedback on this Note, not meant to be a finished work yet which is what prompted wanting to get it published soon

<Zakim> brinkwoman, you wanted to ask if there's progress to report on the BP

Linda: wonder if we have updates on BP work?

Clara: we are still working through it and was delayed in lead up to holiday break
… still seeking input and welcome contributions

Linda: I can try to find someone at Geonovum
… Christine, you want to follow up on WoT?

Christine: indeed, want to focus discussion on discovery and scheduling with Michael McCool
… will let people know timing if interested. want to combine with Augmented Reality, how do you discover sensors and data available from an AR client including someday a browser

Jeremy: if you have date/time for AR and WoT that would be handy

Christine: 19 January at 11EDT
… anyone interested, let me know and I can add you

<jtandy> WoT meeting: Tue 19th Jan, 11AM Eastern

Linda: anyone else have new years regrets or resolutions?

<RobSmith> https://w3c.github.io/sdw/proposals/geotagging/webvmt/#virtualguide

RobS: I sketched out a WoT use case related to WebVMT

Christine: I appreciate that Rob. we are not limiting the discussion to AR

RobS: understood and appreciated

Peter: forgot to ask if ok to make an issue in SDW repo?

<cperey> Thank you!

Linda: yes and please link to the email discussion [and minutes]

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).