13:57:12 RRSAgent has joined #sdw 13:57:12 logging to https://www.w3.org/2021/01/07-sdw-irc 13:57:15 RRSAgent, make logs Public 13:57:17 please title this meeting ("meeting: ..."), ted 13:58:22 brinkwoman has joined #sdw 14:01:12 ClemensPortele has joined #sdw 14:01:21 jtandy has joined #sdw 14:01:31 present+ ClemensPortele 14:01:38 Chair: Linda 14:01:39 Present+ Ted 14:01:49 hi folks - just updating my webex :-| 14:01:51 scribenick: ted 14:02:32 jvanulden has joined #sdw 14:02:57 Present+ Linda, Peter, Joost, RobS, Clara 14:03:18 Present+ jtandy 14:03:59 Chair+ Jeremy 14:05:01 RobSmith has joined #sdw 14:05:04 regrets+ Scott, Bill 14:05:34 cboyd has joined #sdw 14:06:09 Agenda: https://lists.w3.org/Archives/Public/public-sdwig/2021Jan/0014.html 14:06:32 cccccceukvetfedndegtbeifghbfrrujetujnbjcllkt 14:06:41 Topic: MapML 14:07:16 Peter: it is important for MapML to have coordinate and tile matrix sets together 14:08:17 … EGSP data set is separate from the notion of scale. whenever GIS data is used, scale is vital for visual representation on map 14:08:35 … it would be convenient if the coordinate system recommendation had concept of scaling 14:08:54 Present+ Chris 14:09:16 s/cccccceukvetfedndegtbeifghbfrrujetujnbjcllkt// 14:09:45 … having scales or resolutions recommended would be helpful for consumption 14:10:11 … web feature service without notion of scale you get highest resolution possible which may not be appropriate for certain uses 14:10:52 Chris: I raised that with OGC API for tiles. they have been focused on styles etc 14:11:15 Chris, this is not a tiles issue, its a maps issue 14:11:22 … I am trying to get them to revisit 14:11:48 … it is desireable to request tiles at a given scale that is device capability compatible 14:12:06 … in short, I agree with you 14:13:02 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 14:13:13 q? 14:13:32 -> https://lists.w3.org/Archives/Public/public-sdwig/2021Jan/0002.html Peter's email 14:13:50 Jeremy: corner reference system is needed as well as scale as you called it 14:14:05 q+ 14:14:08 … I think it was in Clemens' email that we should not bind these too closely together 14:14:27 … you cite the WFS work and want these concepts combined 14:14:47 -> https://lists.w3.org/Archives/Public/public-sdwig/2021Jan/0008.html Clemens' email 14:15:04 ChrisLittle has joined #sdw 14:15:11 Clemens: I think the CRS come from survey era which predates GIS 14:15:30 present ChrisLittle 14:15:35 … these are reference systems and don't need a scale but provide eg limited accuracy 14:15:51 … CRS don't really have a scale component to them 14:16:16 … at some scale or zoom level, certain features or information should be suppressed 14:16:38 q? 14:16:44 cperey has joined #sdw 14:16:50 … for tiling, each is at a certain zoom level and hierarchy is defined with accompanying OGC standards 14:17:10 q+ to ask PR to describe what he can't do with today's APIs 14:17:15 … scale or zoom level is supported in many APIs 14:17:38 … we have a call for review on work items. we are focusing on geometry simplification 14:18:05 … welcome proposals for handling feature/scale relationship 14:18:33 … this can also be addressed in Best Practices revision 14:18:49 Peter: some WFS do support scale/zoom as a parameter 14:18:50 q+ 14:19:03 … some features are either too small or big 14:19:47 … how you model your data need to take into consideration having feature disappear at a certain scale for instance 14:20:13 … data modeler needs to know the recommended scales. we can use inheritance model 14:20:18 jtandy, you wanted to ask PR to describe what he can't do with today's APIs 14:21:02 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 14:21:15 Peter: correct 14:22:19 Jeremy: for a given municipality, the data is limited and others at eg a county zoom level 14:22:39 … is the choice of CRS coupled to choice of zoom scale or zoom scale to application you are trying to support? 14:22:44 Peter: good question 14:23:27 … agree there could be scale recommendations from town level in British National Grid 14:24:09 You did a better job than I could Jeremy 14:24:18 Present+ Christine 14:24:36 Jeremy: you are positing there are a number of data providers and with scaling we can overlay them reasonably well 14:25:02 Peter: I'm unaware of ETRS89 but guess you would have to reproject data for combining 14:25:33 Jeremy: a consistent set of zoom levels would be preferable across different data providers then? 14:25:36 Peter: yes 14:25:37 q? 14:26:05 Jeremy: if I have a list of zoom levels somewhere, would that help? 14:26:25 … encouraging people to publish data at specific zoom levels? 14:26:50 Clemens: I think we are the wrong group of people to raise that. we should discuss with CRS 14:27:03 … they have a concept of scope 14:27:46 … there are regionally appropriate systems, eg the British National Grid isn't as useful in Germany 14:28:47 … I don't think it is a CRS issue. if anything gets added to its definition, it should come from CRS group 14:28:54 Peter: fair enough 14:29:20 Jeremy: as a data publisher, you have control over the server and should have additional meta data available 14:29:51 Clemens: you can unlimited zoom detail but then reasonably depending on data you may restrict information to specific zoom level 14:30:10 … this is a conscious decision already being used 14:30:35 Jeremy: zoom level already expressed in that case? 14:31:20 Clemens: Google's tiling scheme that is widely used 14:31:38 … OGC doesn't call it zoom level but tile metrics which isn't immediately intuitive 14:32:25 Jeremy: agree. anyone wanting to publish with web marcater (sp? google's tile scheme) can include level 14:32:48 Clemens: the zoom level from their tiling scheme differs from others with their own conventions 14:33:03 … how do we express zoom level? 14:33:28 s/marcater/mercator/ 14:33:57 https://developers.google.com/maps/documentation/javascript/coordinates 14:34:23 Jeremy: how do we combine data from different schemes and data providers? 14:35:01 … a list of scales coupled to CRS is one way, another by an algorithm from Web Features standard 14:35:14 q? 14:35:34 Clemens: the scale range you want to support when you publish your feature data is not dependent on CRS 14:35:45 Jeremy: we are not trying to line up pixelated tiles 14:35:49 ack ChrisLittle 14:35:58 Chris: I want to respond to an earlier comment of Clemens' 14:36:09 … what sort of device am I using and what do I want to see on it 14:36:32 … cluttering/decluttering is a decision of the client application and zoom level mucks that up 14:37:05 … Clemens wants to simplify geometry from a set of features. that is separate from a filtering aspect 14:37:54 (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?) 14:38:16 Clemens: from features API perspective, if feature shown as a certain zoom level is part of it 14:38:55 … at some zoom level or scale you would simply show a point. you would not return certain features at a given scale level 14:39:27 … adjacent polygons with attributes can be returned as you zoom out 14:39:56 … filtering features and getting them ready is server side, combining is post processing 14:40:23 Jeremy: at simplest scale a geometry can be a single point and it is still related to a set of features 14:40:47 Clemens: correct but dependent on zoom level, point could be an airport but when you zoom in have more detail 14:41:49 … if you zoom out to a certain level you would want to only present certain, larger airports and suppress others 14:42:11 … this filtering requires extra knowledge and there is a question if we should even do this 14:42:19 q? 14:42:34 Linda: I am trying to relate to SDWBP 14:42:56 … it is only partially related and the rest about visualization and user interaction 14:43:11 Clemens: it is related to the convenience API 14:43:35 … 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 14:44:08 … how to make data more usable. you may want to return different data if it is to be used for mapping for instance 14:44:45 Peter: would it be convenient to have recommended scale sets attached to CRS for those who want to make a feature service 14:45:09 … you know you are going to have to generated tiled features 14:45:20 … this is why I am suggesting/asking for advice 14:45:31 … sounds like we should discuss with CRS group 14:45:53 Clemens: not sure it is the right thing. scale depends on the data not on the CRS 14:46:10 … still could be worth discussing with that group to get their opinion 14:46:31 Jeremy: how you want to present data is often closely related to type of application[s] you want to support 14:46:32 +1 to clemens - data linked not CRS 14:46:42 +1 14:46:44 … do we want to engage the CRS folks? 14:46:59 … Peter you want us to put you in touch with them? 14:47:10 Peter: sure and can bring back here response 14:47:48 [Clemens provides suggestion on specific OGC group and individual to contact] 14:48:28 Peter: I have corresponded with Roger before, comfortable talking with him directly and will report back 14:48:31 q? 14:48:47 Jeremy: any other topics for today? 14:49:07 Linda: Responsible Use Note 14:50:35 q+ 14:50:45 … believe we are ready to publish 14:50:47 ack RobSmith 14:50:55 Ted: @@Ed, timing 14:51:29 q+ to ask if there's progress to report on the BP 14:51:59 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 14:52:05 brinkwoman, you wanted to ask if there's progress to report on the BP 14:52:20 Linda: wonder if we have updates on BP work? 14:52:52 Clara: we are still working through it and was delayed in lead up to holiday break 14:53:04 … still seeking input and welcome contributions 14:53:32 Linda: I can try to find someone at Geonovum 14:53:48 … Christine, you want to follow up on WoT? 14:54:12 Christine: indeed, want to focus discussion on discovery and scheduling with Michael McCool 14:54:31 q+ to ask @cperey for the meeting date 14:54:58 q+ 14:55:01 … 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 14:55:14 q- 14:56:11 Jeremy: if you have date/time for AR and WoT that would be handy 14:56:51 Christine: 19 January at 11EDT 14:57:08 … anyone interested, let me know and I can add you 14:57:09 WoT meeting: Tue 19th Jan, 11AM Eastern 14:57:12 q+ 14:57:26 Linda: anyone else have new years regrets or resolutions? 14:57:45 https://w3c.github.io/sdw/proposals/geotagging/webvmt/#virtualguide 14:57:53 RobS: I sketched out a WoT use case related to WebVMT 14:58:07 ack next 14:58:22 Christine: I appreciate that Rob. we are not limiting the discussion to AR 14:58:31 RobS: understood and appreciated 14:58:47 ack PeterR 14:59:02 Peter: forgot to ask if ok to make an issue in SDW repo? 14:59:08 Thank you! 14:59:17 Linda: yes and please link to the email discussion [and minutes] 14:59:18 I have made the request to generate https://www.w3.org/2021/01/07-sdw-minutes.html ted 14:59:20 When is next meeting? 14:59:27 bye 14:59:34 Bye! 14:59:40 leaving. As of this point the attendees have been ClemensPortele, Ted, Linda, Peter, Joost, RobS, Clara, jtandy, Chris, Christine 14:59:40 Zakim has left #sdw 14:59:41 I see no action items