Spatial Data on the Web IG - TPAC F2F - Day 1/2

22 October 2018

Meeting minutes


jtandy: [Logistics]. Let's do a quick round of introduction. I work for the Met Office, co-chair of this group

brinkwoman: I work for Geonovum. Other co-chair of this group

tidoust: W3C Team contact for the Spatial Data on the Web IG

RobSmith: I work for AwayTeam. I lead the WebVMT proposal

ChrisLittle: Also working for the Met Office. Did a lot of things including graphics.

ChrisJarvis: Working for the Environment Agency in the UK.
… Managing lots of spatial data there.

MichaelGordon: Ordnance Survey. I do a lot of work with OGC, involved in Test beds.

billroberts: Swirrl. Stats on the Web Best practices.

PeterRushforth: National Resources Canada. Co-chair of the maps for HTML CG.

IngoSimonis: Work for OGC. Starting Testbed 15. Pretty sure that plenty of the topics we'll talk about today will be part of that effort.

JohnPallet: From Google. Involved in Immersive Web CG/WG.

Michael: Also working for Google [scribe missed the rest]

Satoru: from KDDI.

JosephMedley: From Google as well.

<satakagi> I am one of the editors of SVG 2 and I am the chief programmer of KDDI's web mapping system

jtandy: I wanted to present the scope of the IG, how we work.
… We presented the IG in the last OGC meeting.
… The IG is a joint group between the OGC and W3C.

[slides shown]

brinkwoman: Goal is to expose spatial data on the Web so that they become findable by search engines and usable.
… We used to be a Working Group, then we switched to an Interest Group.
… Jeremy and I worked on Spatial Data on the Web Best Practices.
… We also completed standardisation of technical specs OWL Time and Semantic Sensor Network (SSN). These specs have become W3C Recommendation. Not yet OGC standards but we're working on it.
… Also did some work on coverage.

billroberts: Coverages are for big spatial datasets, roughly. Think satellite images.

jtandy: Data with space and time.

brinkwoman: The WG closed in 2017 and we setup this Interest Group to follow up.
… What we're trying to do in the IG is: Statistical Data on the Web Best Practice (Bill is leading that work)
… Also working on adoption and implementation of Spatial Data on the Web Best Practice (led by Michael)
… Also handling errata for published Recommendations SSN and OWL TIME.
… And sheperding topics that are of interest for both OGC and W3C.
… In OGC speak, a W3C Interest Group is a DWG.

ChrisLittle: I find it useful to describe standards WG as vertical, and Domain WG as horizontal

RobSmith: What's the equivalent of a W3C WG in OGC?

brinkwoman: They call it a SWG. Standards Working Group.
… To sheperd ideas, we use the notion of a strategy funnel, from exploration to standardisation.
… We stop before standardisation.
… The strategy funnel is online, we're going to look at it later. The scope is "geospatial + Web".
… We're evaluating all the items that are in the funnel.
… We're coordinating this work with OGC. The OGC has Technology Trends to look at the horizon of things that are coming along. We are having telcos with OGC about Technology Trends once every two months, roughly.
… If we move something in the funnel, we tell the OGC Architecture Board about it, so they know what we're up to here.
… One thing that we do talk in this IG as well is that if something needs to be standardised, we may need to create a W3C WG, an OGC SWG, or a joing group.

jtandy: That's a quick overview, thanks!
… In summary, our job is to incubate ideas related to Spatial Data, and to develop best practices.
… Those are the two roles that I think we do. If you look at how we're working, we have a lot of individual topics, each one led by one individual with little engagement from others in the group.

Strategy funnel

<jtandy2> https://‌github.com/‌w3c/‌strategy/‌projects/‌2?card_filter_query=label%3Ageospatial

<jtandy2> https://‌github.com/‌opengeospatial/‌OGC-Technology-Trends/‌blob/‌master/‌README.md

<jtandy2> https://‌github.com/‌w3c/‌sdw/‌projects

jtandy2: Looking at the Strategy funnel, we have one thing in investigation, and a bunch of things in exploration

jtandy2: We have a number of projects in the works.
… Some proposals for the Time ontology, for instance.
… Also CityJSON.
… CoverageJSON.
… MapML led by Peter, again an example of an initiative led by an individual without much engagement from the rest of the group on the development of the spec itself, but the group provides guidance on moving things forward
… The WebVMT proposal, led by Rob, same thing.
… The SSN Ontology is defined into two ontologies, a complete one effectively called SSN, and a simple one called SOSA. Some extensions are considered.
… Again a small group of people working independently.
… Describing moving objects is essentially dead. The persons who were to work on this have not joined the group and led the work. None of us are short on jobs to do. The group cannot work on everything.
… Time amendments, led by Chris.

ChrisLittle: Moving forward in OGC these days.

jtandy: The Time Ontology has been around since 2006, but was not a proper standard. The new one is a standard, introduces new calendars. Gregorian calendar is the default global, but you can also represent the Jewish calendar and so on if you wish.
… SSN/SOSA amendments, Maxime will be there tomorrow.
… Statistical data on the Web, led by Bill.

billroberts: I've been collaborating with Michael, Chris, and a few others. But it's a small group, indeed, not enough to make huge progress.

jtandy: My point is that, going through our list of activities, our job is to progress ideas to the point where they can be standardized, and develop best practices.
… Also giving visibility to our work, to new ideas.
… We're trying to see where things fit in OGC/W3C activities. Our job is to say that if you want to develop WebVMT, you need to gather support from the right people, e.g. defense for body-worn cameras.

RobSmith: And that kind of feedback has been really helpful.
… Our job is to move things through the funnel to the point where our work is concluded.
… It's somewhat mechanistic.

<RobSmith> W3C Strategy categories are described at https://‌github.com/‌w3c/‌strategy

MichaelGordon: We managed to move various things to the incubation phase in Amersfoort. MapML, WebVMT, stuff has been happening.
… It always depends on who's around. Question is whether we're accomplishing things fast enough. From my perspective, we seem to be making progress. In terms of encouraging adoption of the Best Practices, we have some reports coming.
… That's very good stuff. But it's hard to judge what would be a good pace.

RobSmith: I second that. A good way to measure that is to look at movement. Has there been activity in a given amount of time?
… From the technical side, there hasn't been much review, that's true. But from a standardization perspective, the inputs from this group have helped me go in the right direction.

ChrisLittle: I was going to suggest that we should have some kind of timeline on the Web site

tidoust: Right, that's in theory one role of the IG: to update the milestones that were in the Charter

billroberts: The Best practices were the core activity of the Working Group back then. Now we have a bunch of different topics. It's a very different way of working. I'm not sure that we got it right yet.
… We don't have the capacity to develop all of them on our own.
… For new things, we need to have a bigger external group that is channeling efforts on each task. Perhaps we still have the expectation that we're actually going to do stuff in this group. That's an internal/external effort.

jtandy: So you're saying we're more in a coordination role now, and we haven't made that transition yet.

billroberts: Right. I think you made the point, as chairs. But still, it takes time to change the mindset.

PeterRushforth: Maps for HTML CG was an outcome of a workshop that this group started. The reason that we started to collaborate with W3C is that the Web is the most successful platform in the world. Idea to socialize the idea of maps being part of the Web.
… You're lucky when other people pay attention to your ideas.
… In theory, we all share the notion that spatial data are important.
… As for progress, these things take a lot of time.
… It can take a long time to get to a standardization working group.

IngoSimonis: The group does a good job reporting to OGC. The group could leverage resources available at OGC.
… We have a mechanism in the future program to look at new ideas and reach to sponsors.
… I'm pretty sure that we can help from OGC side to find resources.
… The issue is that it needs to be aligned with OGC initiatives. If requirements are known too late, that cannot work. That's something to keep in mind in your discussions. If you have a list of top 5 priorities, that helps.

jtandy: Typically, Maps for HTML has been supported in a Testbed.

IngoSimonis: Yes. It would be great if we could support right away.

MichaelGordon: For each idea, we have people driving them. Advancing something is a very different job from reviewing something. For new ideas, we need people driving the ideas for them to make progress. For best practices, we do need reviews.
… Best practices are stuff that we are producing directly.
… That's where we need to assess that we have the right set of resources within the group to advance these works.

jtandy: What I'm hearing is that the group is largely meeting expectations in terms of sheperding ideas. We can do better to leverage resources, e.g. in OGC, to get work done.
… In that sense, we're providing a useful service.
… In terms of mechanics, as we transitioned from a WG to an IG, we began with a set of teleconferences, but given that we have a bunch of topics with limited interest across the entire group, the attendance to these calls, especially considering timezone issues, was not so good.
… The IG thus switched to a mode where it runs a focus week the first week of each month.
… This month, we didn't do that because we were having TPAC.
… Are the focus days a useful mechanism to "shame" people into doing some work?

RobSmith: Yes.

MichaelGordon: In retrospective, yes, but I struggled to get the focus. Having the monthly focus is good.

RobSmith: It's a good way to write a summary of what has been done, more than just "I've been doing stuff".

jtandy: Would it better to change it from focus day to "this is what we want to achieve this month, and here's a retrospective of what we did"?

RobSmith: I think that people are more responsive during the focus days.
… It might just be a perception.

jtandy: OK, let's part that thought and get back to it later on.

WebVMT proposal

[presenting WebVMT slides]

RobSmith: Web Video Map Tracks. A way of synchronizing videos with map track on the Web. This was proposed to this group in February in Amersfoort. I've been benefitting from advice of the group.
… The proposal has moved from stage one to incubation in the Strategy funnel.
… I'm going to give a quick update since Fort Collins, last group's F2F.

RobSmith: One of the things that were proposed was to setup an engagement Web site. Now done.
… It's a non technical description. It shows what it can do, and hopefully catches people eyes.
… The site includes a number of tech demos, written in JavaScript.
… [showing https://‌webvmt.org]

jtandy: In AR, is the idea of taking video footage and presenting in a Web environment a use case?

Michal: Pre-recorded footage?

jtandy: Both pre-recorded and live

RobSmith: Goal is to combine existing technologies to satisy the needs and requirements that are emerging from these new devices.

johnpallett_: WebXR exposes poses, which you can use to record orientation. There has not been any work to expose information such as Lat/Lon along with that info.
… Within WebXR, one question is how do you do that in a privacy-preserving way?

RobSmith: If it's possible to record it, potentially there's a compass track, or an orientation track. The question is how to embed these details along with the video.

johnpallett_: Requires access to getusermedia. There's some discussion going on right now about augmented reality modes. Whether capturing and AR pose tracking can be one mode.

RobSmith: I'm considering different use cases. One of them is to create the track afterwards.

Michal: One role for recording could be to persist features in some way

RobSmith: We are currently focused on dash cameras for now. Possibility to upload dash cameras to the police. Currently, you have to click on the map to tell where it happened.

<jtandy2> https://‌www.bbc.co.uk/‌news/‌av/‌uk-england-norfolk-45843691/‌shocking-dashcam-videos-released-by-norfolk-and-suffolk-police

RobSmith: It looks like an obvious win for WebVMT if there is a location track along with the recorded video.

jtandy: Just put some related article about the use of dashcam.

RobSmith: An early adopter in the dash-cam market is implementing WebVMT for now.

Lionel_Wolberger: In the Credentials community, we have verifiable claims that could be a way to verify the location track. An aspect here is to claim that the location is linked to the actual footage. A verifiable claim could be a way to attach a proof that the video and location are associated.

?1: There's a separate user gesture for geolocation and capture. There is no guarantee that you'll get both.

<jtandy2_> WebVMT project page: https://‌github.com/‌w3c/‌sdw/‌projects/‌8

<jtandy2_> WebVMT editor's draft: https://‌w3c.github.io/‌sdw/‌proposals/‌geotagging/‌webvmt/

RobSmith: One of the demos is me, a bike and a phone and a little bit of editing afterward. It could be that you don't have access to the location information, which is a different problem.
… It's only a recording format. The inputs can be wrong. Out of scope for this meeting.

Michal: It sounds like the video and the recording data have separate pieces. Video formats are frame-by-frame metadata.

RobSmith: Right, there are formats where it's possible. I'm taking a different approach deliberately.
… Using a separate file. Small text file. For a Web crawler, it's way easier to parse and index.

ChrisLittle: I also remember you say that video people are in their own silo.

ChrisLittle: I was interested by the credentials discussions and wonder how to make a connection with the security group at OGC.
… The Security Domain Group is the one I'm thinking about.

jtandy: We might come back to that discussion a bit later on. Some spare time on the agenda.

Lionel_Wolberger: Thanks, that would be great. We would like to socialize Verifiable Claims.

<MichaelGordon> OGC Security DWG - http://‌www.opengeospatial.org/‌projects/‌groups/‌securitydwg

johnpallett_: There is a fairly wide range of tools in the media ecosystem.
… When you have a separate metadata file, the workflow is not the same. I wonder if you've thought about it.
… In particular about integration with existing tools. Any update to the video would require a possible update to the linked file.

RobSmith: Not yet. I'm aware of this. But I'm proceeding one step at a time.
… Some way of putting a line on the map, of tracking objects, of linking objects and e.g. readings from sensors.

RobSmith: Back to the presentation. One of the outcomes of an OGC meeting is that there is a requirement for body-worn cameras to provide geospatial information.
… I'm checking if there are similar requirements in the UK, that's a useful lead.
… I'm also reaching out to Media folks here. The Media and Entertainment IG has a Media Timed Task Force.
… WebVTT is at Candidate Recommendation. They support metadata cues, and I believe we can thread WebVMT as metadata cues.

jtandy: And so the point you raised, John, also applies to WebVTT.

RobSmith: For instance, the URL that links the metadata file to the video file is not in WebVTT. That's one of the questions I want to raise during the breakout session.
… Back to use cases. Dash-cam focus, as I said.
… In car race, cameras in car.
… And police evidence.
… Cyclists and pedestrians would also be able to provide footage, and you'd get interoperability between polices across the globe.
… In the UK, there are apps that turn your smartphone into dash cams for insurance perspective.
… Finally, at the Web level, I've done some work on integration with Mapbox GL. I combined that with Ordnance Survey Open Zoomstack.
… At the spec level, I've added the data model and the syntax, switching from XML to JSON in particular.
… There should be sufficient details for implementation.
… The switch to JSON fits with the WebVTT design.

jtandy: From your perspective, you're seeing progressing. Some airtime with groups. Some momentum.
… Are you shedding moss or gathering moss?

RobSmith: I'm shedding moss.

tidoust: Wondering about native support in browsers with the switch to JSON?

RobSmith: Yes, I'm targeting the "metadata" kind of cues in the track element. The metadata example in WebVTT includes latitude and longitude. I don't think that a lot of thoughts have been given to that until now.
… Figuring this out with WebVTT folks is what I'd like to get out of this TPAC.

ChrisLittle: Obviously, the funnel process is working well for you. Have you got any resource on top of yourself?

<satakagi> https://‌www.programmableweb.com/‌news/‌blackvue-provides-api-access-to-vehicle-dashcams/‌brief/‌2018/‌10/‌04?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ProgrammableWeb+%28ProgrammableWeb%3A+Blog%29

<satakagi> from https://‌people.w3.org/‌mike/‌planet/‌web-developer/

RobSmith: Currently, not. And I'm conscious that I'm an Invited Expert too. I cannot keep committing resources to it unless I get paid, which is what I'm trying to figure out as well.
… I proposed a Community Group, and I could take a bit of support to create the CG.

Proposed WebVMT CG

[I note anyone can support the creation of a CG]

brinkwoman: I just want to verify that you're happy in the Incubation phase

RobSmith: I think so. Getting more early adopters is needed. That's why I'm focusing on the dash cam community for now.

ChrisLittle: How many early adopters do you need?

RobSmith: Two, at least.



MapML engaged with OGC and their Testbeds

APIs are not web friendly enough, Javascript made it hard for map authors and other geospatial stuff.

WebML desgined to be simple, using map content by URL reference. <map> element was introduced into HTML in the mid-1990s

the element had initial traction, similarly to use of <table> element used for layout.

MApML created to allow panning and zooming of proper maps. example shown.

content semantics are transparent. Base map plus links to features with shapes and geometry.

Also allows navigation.

barrier to usage is the javascript requiring sophisticated usage.

map layers cannot use the 'source' semantics of video.

Hence <layer> invented, with source attribute or content

a map has default controls, such as to switch layers on or off

MapML is a 'fork' of HTML, with its own media type.

Very much like an HTML Form

the content of the <extent> element is mainly input and links.

Question from Francois about CRS used in example

A key driver was to accomodate other CRS/projections other than Web Mercator

Currently supporting Lambert Conformal Conic, Arctic Polar Stereographic as well as Web Mercator

Envisage slowly expanding.

Question from Michael: why not use existing resources?

Discussion to be continued offline

Another question from Michael: progressive enhancement good, but where to constrain Javascript libraries?.

Peter: offloading some of the javascript heavy lifting into the browser, and advocating should be in the browsers.

ChrisLittle: why would browser vendors want to implementt his?

What about the resistance of browser developers to keep browsers small?

Peter's answers: 1. Web for everyone, not elite

Francois' comment about support of MathML, MusicML, ChemML in Javascript

Michael mentions some MapML itmes would be simpler in javascript than in an integrated browser

Rob: are you proposing a base API implemented as a small javascript library?

Peter: HTML is so widely implemented, lowers barriers to entry to map creating

Rob: many javascript libraries need javascript skills toimplement a map

Peter: accessibility is built into HTML and browsers

Peter: everybody know werhe they are from their devices, but not where other stuff is.

Peter: HTML apporach allows things to ranked by locality and nearness

jeremy: layer stacking is a new paradigm, not the same a current for resources in a browser

other resources, sush as video, audio could have this stacking property

Francois: no difference in work whether in browser or javascript

Peter: overlays are really important fundamental use case for maps

<Zakim> satakagi, you wanted to say that Without a native implementation, I think javascript should have a way to extend the browser more formally. I think that polyfill and web components are one step.

MapML willing to work with polyfill to explore approach

Chris: question: is the parallel with video and audio content not good enough? Layers stay 'within' map content object and declared methods/operations. Not quite a coherent question yet.


<hugoledoux> you can also all check the slides as I speak:

<hugoledoux> https://‌www.dropbox.com/‌s/‌xwkt9qqbra1ty8w/‌2018-10-22-w3c-cityjson.key.pdf?dl=0

hugoledoux: re-caps history of CityGML and City JSON

Wants JSON to be the second encoding

Version 0.8 released. Software working. Some extensions supported: ADE...

which is Application Domain Extensions for schemata.

software is cjio at CityJSON/io

Version 1.0 needs some feedback from users, V0.8 reasonably complete

CityGML version 3 under development for last 8 months ...

but no apparent changes yet. Issues with software development not considered in the standardisation process. ...

CityJSON seen as a competitor not an extension ...

Problem is CityGML is perhaps too complex.

So no clear direction for future development

proposing to put on hold CityJSON standardisation...

Standardisation against CityGML V2 is a risk


brinkwoman: I was observing CityGML. No consensus on CityGML data model. some thing too complex, others not. ...

no implementation evidence.

brinkwoman: main players are talking.

MichaelGordon: wider discussion in OGC on implementation evoidence as part of standardisation process

jtandy: please engage with OGC as a specific issue.

tidoust: W3C aware of the issue in general and the CityGML in particular. Suggest send message to OGc

MichaelGordon: discussion has taken place by interesed parties. Some progress made.

tidoust: implementation evidence needed in W3C

ChrisLittle: w3c approach been raised in OGC discussion

MichaelGordon: will add link to OGC discussion

hugoledoux: no javascript parser for CityGML after several years, seriously indering adoption of CityGML

ChrisLittle: implementation evidence is part of the OGC Policies and Procedures

hugoledoux: please to hear the theory.

tidoust: processual issue, not technical, so SDWIG could apply pressure

ChrisLittle: Asked Ingo to provide link to OGC P&P implementation evidence

Ingo is Ingo Simonis, OGC staff

jtandy: composing a resolution to pass to OGC and SWGs

<hugoledoux> my proposal: software should be part of the development process

discussion of words to be used from hugoledoux, brinkwoman, jtandy, Ingo, Peter

<tidoust> PROPOSED RESOLUTION: The Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create standards that match reality.

hugoledoux: CityJSON evoked a big debate in the OGC CItyGML standard WG

<hugoledoux> we (TUDelft, Geonovum, NUS, Kadaster) actually presented these slides at the last CityGML-SWG: https://‌speakerdeck.com/‌hugoledoux/‌our-issues-with-citygml-v3

<hugoledoux> they summarise our concerns

tidoust: perhaps we should list the practical and actionable items

hugoledoux: agrees to use of presentation slides for SDWIG response

tidoust: can we have some expamnded details of point 2 over complexity of the standard?

hugoledoux: agreed, will send details later.

jtandy: SDWIG chairs, Francois and Hugo will formulate a statement to go to OGC TC-Discuss mailling list and OGC CTO Scott Simmons

<tidoust> PROPOSED RESOLUTION: In principal, the Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create standards that match reality. The SDW IG will work on a formal response on CityGML v3 raising technical concerns to be sent to the tc-discuss OGC list.

<tidoust> PROPOSED RESOLUTION: In principal, the Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create effective standards implemented by the wider community. The SDW IG will work on a formal response on CityGML v3 raising technical concerns to be sent to the tc-discuss OGC list.

<jtandy> +1

<brinkwoman> +1


<tidoust> +1

<PeterRushforth> +1

<hugoledoux> +1

<billroberts> +1

<ChrisJarvis> +1

<MichaelGordon> +1

Ingo +1

Resolved: In principal, the Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create effective standards implemented by the wider community. The SDW IG will work on a formal response on CityGML v3 raising technical concerns to be sent to the tc-discuss OGC list.

jtandy: question to Hugo confirm that do not want to base CityJSON on CityGML2

hugoledoux: reluctant to be involved in a conflict for several months, and prefers to wait

hugoledoux: will continue development on CityJSON, but will not put to OGC as a standard until issue resolved

tidoust: advocates not parking CityJSON, but maintain as an open item in the SDWIG Funnel.

jtandy: thank you

Statistical Data on the Web

Charter said we would do a best practices note by Q2 2019

... as a specialisation of Data on the Web Best Practices

...Spatial Data on the web best practices work found that there were many use cases that involved statistics

...scope - what do we mean? - numerical data, based on measurements of a sample

...what are common between government and "scientific" stats? what are differences?

...government stats often have location as enumerated list, often scientific stats have grid form

(but not always as pointed out by ChrisLittle)

Why are we doing this? - to make stats data easier to find, understand and use

Make it easy to bring into a range of tools - that means machine readable, automatable and interoperable between datasets and organisations

Stats organisations already have various best practices for creating and publishing stats - we're not trying to cover those areas

Common ways of publishing often is PDF's with commentary

In recent years in UK gov and some others, there's also PDFs with excel spreadsheets - often structured for human readability rather than machine reuse

In scientific community there are the FAIR principles - findability, accessibility, interoperability, and re-usability

Current status of work - haven't got too far. Working through DWBP to look at context with statistical data with extra attention to spatial aspects

Collaborations - there is a vote in progress in OGC about Statistics Domain Working Group - currently does not have quorum but still being voted on

Bill has talked with Ian Coady about close collaboration with this group and with Ian's work in UNGGIM

Bill also has talked with Eurostat and others about this best practice work

Key aspects of data model - what is being measured? how are measurements organised? There are relevant W3C / OGC standards

Publishing controlled vocabularies can help here

But if there are many for the same thing (e.g. country codes) there can still be a problem - this is where best practice can help

Regarding the "on the web" portion - network accessible information - Discovery, Global scale, de-centralised, linkable

...a lot of problems come up with bodies wanting to centralise, however there are challenges in trying to de-centralise well

...Many challenges will require data from multiple sources - this requires data being defined in enough detail for people to know how it could be used for other uses

...Doing data "data" is hard work

...sharing best practices should reduce the effort and maximise the benefits

...examples can show what benefits come from putting in the extra effort

Challenges - 1) Getting people to use consistent data models 2) Using shared well defined identifiers 3) Changing mindset from report first to data first

Output of work - best practices doc similar to DWBP and SDWBP. However statistics BPs might more closely align to Data on the Web Best Practices

In the next 9 months - need to produce best practices doc. This means the scope will probably be smaller and focused on those that have biggest impact

Is there a prioritization of challenges so that others can be kept rather than simply limited scope?

There hasn't been any feedback gathered in terms of which DWBP have most impact around stats

jtandy: Which bodies are producing stats data around INSPIRE? Another area to look would be the coming update of climate change update and how that data is published

ChrisLittle: They have using Climate and Forecasting convention but have made some changes

jtandy: Ian Coady is probably best placed to answer some of these questions

billroberts: I'm reasonably well connected with UK stats bodies - all have a lot in common

jtandy: Key point that they have a lot in common, are these best practices or common in a could be better way?

billroberts: probably not exploiting possibilities of web

ChrisJarvis: We publish one stat on bathing water (as linked data) - their focus is on demonstrating there is no interference
… don't know if the transparency between published stat and raw data.
… we collect a lot for environment monitoring but often don't think so much on the secondary uses of the data
… we have 40 years of environmental study data - one of things that is being worked on is opening up that data for academic use

billroberts: Different people have different definitions of stats, but in this context probably best not to be too constrained for this work

jtandy: Getting a line of sight between a measure (like amber bathing water rating) and the raw data over months that that is created from

billroberts: Good example for best practice document as it has visual stats at one end and raw data available as open standards at other end

jtandy: Same could be said for example of agriculture data - line of sight between policy statements and the raw data tha t
… that creates it

billroberts: In some ways possibly this is why it isn't common practice - showing the link between policy and evidence

jtandy: But in creating the benefits analysis for the policy that evidence is collected and then audited

PeterRushforth: Relative to the discoverability etc - have you given any thought as to how maps on the web could be useful?

billroberts: One of the things we should try and develop a bit more is the spatial element of the possibly statistical best practices
… for example how good is a chloropleth - often can depend on implementation
… one of things initially about the spatial data on the web best practices was trying to get the GIS and web communities to be able to work better together

jtandy: In terms of agriculture data example - is that work lined up to happen?

ChrisJarvis: It's lined up and in terms of 9 months worth of work on the statistical best practices - this might be a good way to test these and feed back in

jtandy: So knowing what you know about the bathing quality approach, you could write some proposals around that and go forward with that

billroberts: Certainly want to make this data available in the best possible way

billroberts: and this work could help document these

ChrisJarvis: Whilst EA don't have the policy area as they are an operational department, they do regulate using a risk-based approach using evidence but is harder because data isn't joined up and so the line of sight is obscured

jtandy: Another potential avenue would be Geospatial Commission partner bodies - OS, LR, VOA, Coal Authority, BGS, UKHO. And whether any of them have interest in publishing stats?

MichaelGordon: they're talking on a more general level at the moment

billroberts: it might be worth trying to get them to apply the SDWB and stats BP once they get round to publishing data and the technicaliities of that.

Possibly LR - I can have a think about how we can interface there. There are also various projects just starting that will benefit from spatial data on the web best practices

<brinkwoman> ... particularly the SDWBP

jtandy: In terms of how things are working, stats on the web best practice is aiming to be a note not a standard, if the OGC stats domain working group kicks off would you feel more comfortable using that as your group and using this group as a place for visibility?

billroberts: I think we need more involved than so far - if that's putting it under the remit of that group or a joint activity with that group, I suspect that they would have a broader range of people involved. Not sure if this needs to be an official thing

jtandy: Lets keep a watching brief of that - if the OGC stats DWG can cover this work then this group can focus more on visibility

billroberts: Anyone who wants to contribute to this work please do

billroberts: One of things I need to do is rally the troops and put some more structure in place

billroberts: This should make asking for help easier as it would be more focused

jtandy: One of the things this group has talked about is being more specific on calls for review

ChrisLittle: Where did the 9 months come from?

jtandy: group charter ends Dec 2019 but can renew charter if needed / wanted

MapML discussion

mmocny: question about use cases around customising maps on different web sites

mmocny: should this be in javascript, or in a map element in the browser DOM. Publishers generally select the solution at the moment, and users have to use that solutoion whether they want it or not
... google maps for example can produce some customised maps for different users
... have you considered the idea of users being able to customise their own views?

PeterRushforth: having the default map built into the browser is not the ideal 'webby' solution, should be configurable

jtandy: what criteria would you use to determine what to put into the browser, or not

mmocny: browsers are already very big bits of software. It's preferable not to add more things

mmocny: we already have enough primitives to build what we need

PeterRushforth: google maps could also use MapML.
... people have very diverse needs, so having something that is very customisable is a benefit in web mapping tools like Google maps as well

PeterRushforth: good to have simple primitives around maps as part of the 'infrastructure', that enable all kinds of things

RobSmith: can't you do this kind of thing easily already (put a pin on a map etc), eg via Google Maps API?

[discussion of what could be a built-in HTML/browser feature vs a Javascript add on]

jtandy: can we get all the providers with stackable maps to follow one standard - which could be MapML perhaps

PeterRushforth: MapML is a simple wrapper to existing tile based and service based data sources

jtandy: question is: should this be in the browser or met via 'add-on' components

PeterRushforth: maps are fundamental to all kinds of decision, web is an essential mechanism for sharing ideas - seems natural that maps are part of the browser

Question: what is the benefit of native support?
... there are a lot of browsers out there, so a lot of work to implement this in all of them
... could we just use web components?

PeterRushforth: HTML is a widespread and basic technology, and common skill to work with it. A custom element might not have such wide reach

MichaelGordon: Javascript is also a widely taught and used skill

jtandy: have used the available time for now.
... If you could get evidence of adoption of people using a custom HTML element, that could make the case for standardisation

MichaelGordon: the argument around using this for progressive enhancement is more compelling

John: web components also allow you to do declarative tags without Javascript

Open Discussion

mmocny: I'm Michael, from Immersive Web group at Google. Working on immersive, collaborative applications.
... we're exploring browser primitives to allow use of augmented reality components etc
... the content is currently closed off in silos
... so interested in open publishing
... compose AR into large datasets and complex experiences
... Spatial data publishing is a big area so interested in this for its relevance to AR
... Current presentation model doesn't gel well with immersive web
... We would like an augmentation type (ARML has this), as well as supporting some simple content primitives
... We'd like to find people with relevant experience and ideas, so we don't reinvent the wheel unnecessarily

jtandy: yes the purpose of the group is to help make these kind of connections and would like to help. What are the top things that would be most useful?

mmocny: moveable, trackable things that are not just fixed places in the world (Current guidelines focus on static things)
... where should this data live?
... How does one make statements about the world? Should this follow different publishing guidelines?

<ChrisLittle> An useful AR person is Christine Perey cperey@perey.com
... Is there anyone working on composable world-scale experiences (as opposed to just single perspective experiences)

MichaelGordon: there is work on AR in the OGC innovation programme, looking at ARML amongst others. Ingo is part of this

<ChrisLittle> Christine Perey steered ARML2 through OGC. Now considering re-suscitating an AR Domain WG in OGC. strong interaction with the VR

IngoSimonis: that AR experiment is on hold at hte moment. There are more Virtual Reality work items right now
... if you can say what you find missing in ARML we can feed that into the work activities

mmocny: A recipe for recognising moving things

jtandy: there were a couple of things in SDW BP that touched on this, but we talked mostly about what people were already doing rather than developing new technology
... there was a plan to do Moving Objects in the SDWIG but that has not been moved forward and is currently in the 'Parking Lot'
... we'd be open to include these questions in teh activitives of the group, (but of course involves bringing in some effort to contribute to it)

RobSmith: Also very interested in moving objects

Ingo: could get involved in the OGC group

[jtandy points Michael to the Projects part of the sdw github ]

jtandy: would be useful to feedback to OGC that you feel that ARML is missing some important features for this use case

brinkwoman: OGC Moving Features. Scott Simmons got in touch recently to say they would like to schedule a presentation to SDWIG from the Moving Features group, and could be some overlapping interests. Might be of interest to the Google immersive web team too?

OGC moving features specs: http://‌www.opengeospatial.org/‌standards/‌movingfeatures

<mmocny> Existing docs referenced: Spatial Data Best Practices (https://‌www.w3.org/‌TR/‌sdw-bp/#best-practice-criteria)

<mmocny> ARML v2: http://‌docs.opengeospatial.org/‌is/‌12-132r4/‌12-132r4.html

CovJSON update (Mark Hedley)

Update status:

markh submitted a proposal to the W3C strategy Funnel

Status is "investigation"

... created a project for the Spatial Data Interest Group on the web

... focusing on the identification vocabulary here

... and there are only stubs

... there are indications that CovJSON will use JSON-LD but need more info.

... next steps listed in the strategy funnel #122:

... Liaise with OGC and ISO to analyse the harmonisation of ISO19123 and CovJSON. Develop vocabularies to support the CovJSON encoding. Manage and review activities through the Spatial Data on the Web Interest Group.

... Develop vocabularies to support the CovJSON encoding: spoke with John Blower

Manage and review activities through the Spatial Data on the Web Interest Group: a bit resource starved, will continue to try to push this forward.

Jeremy: CovJSON is of interest to the Meteorological office as the data is handled in the browser, enabling in-browser computations at the edge rather than doing end-to-end data calls (client/server) which are heavier and slower

markh: There are various encoding formats, image formats.
… GML supports various coverages.

ChrisJarvis: There is 15TB of Lidar data, some stretching back 15-20 years in age
… had not thought about opening that data for other users

Jeremy: We are seeking to fit the "web" pattern of working within the browser

markh: We seek an interested party. The Met Office needs a clear partner.
… No clear time scale yet on this.

Lionel: Is there any similarity between the other needs of overlay, e.g. AR?

markh: there is some overlap. CovJSON was good a structured data, grids in space and time sampled across regular grids

Billrobe_: CovJSON was dedicated to space efficient encoding of a regular or semi-regular domains. E.g. a rectangular grid of points, it lists the values in ways sympathetic with JSON array structures that work well in web pages.
… So gridlike data is one clear way they would overlap.

Jeremy: Agenda: Improving how the group works via remote
… Rob suggests helpme tags, and a recent issues list for the home page

improving how the group works via remote

Jeremy: MichaelGordon said it was helpful setting objectives for the month and then reporting on completion by end of month
… but the focus days did not help. Rob did find them helpful.

Rob: I find objective-setting less useful, as the events during the month change things.

Jeremy: you both agree the retrospective is helpful

Linda: Uses focus week to answer questions more quickly

Rob: consider use of tags

Rob: tags do have descriptions attached

Jeremy: descriptions of tags can be edited

Rob: can we highlight issues like 'help wanted' on interest group home page - most recent issues that have a help wanted tag to bring to people's attention

Jeremy: project list would be better than home page

Jeremy: linda, francois and Jeremy to discuss best way

<ChrisLittle> thank you Chairs and Scribes

Summary of resolutions

  1. In principal, the Spatial Data on the Web IG strongly supports the need to create a feedback loop between practical experience implementing a spec and its design to create effective standards implemented by the wider community. The SDW IG will work on a formal response on CityGML v3 raising technical concerns to be sent to the tc-discuss OGC list.
Minutes manually created (not a transcript), formatted by Bert Bos's scribe.perl version 2.49 (2018/09/19 15:29:32), a reimplementation of David Booth's scribe.perl. See CVS log.