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
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: 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?
https://
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://
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]