Discussion thread for "Spatial Data on the Web 2022 – where next to drive impact from geospatial data"

[chris-little]

@lvdbrink Thanks for writing the SDWWG2022 markdown document.

I think we need a paragraph on existing, continuing, activities, that have started, but are not yet 'self-sustaining'. "If we stop pushing, the bus will stop, not continue".

In particular, the work that @rob-metalinkage and @ghobona are doing on the OGC Naming Authority registers and definition servers, and work in the pipeline to access other authoritative registers, such as EPSG and WMO, still has some way to go before general web users can access multiple data sources, such as maps, in different CRSs, and munge them all together correctly, with reprojections happening seamlessly under the covers.

[6a6d74]

See comment by @ewulff1 on related thread: issue 1272

[6a6d74]

Please use this thread for discussion relating to the proposed new work described here: Spatial Data on the Web 2022 – where next to drive impact from geospatial data

[6a6d74]

Here's the discussion from the SDW-IG plenary call, 22 Jul 2021 (minutes):

---

jtandy: what big challenge(s) should we focus on in the next few years?

jtandy: early explorations indicated that interoperability of data could be a key part of this, so relevant to the previous discussion

PeterR: I'd like people to focus on Maps for HTML! It would be good to address how to get geo into the web. … there has been a lot of effort and progress on geospatial data interoperability in the last 20 years and a foothold to bring this to the masses could be very important

+1 +1 +1 jtandy: are we interested in trying to write a discussion paper that addresses the challenges in this github document? … please vote with +1/-1 in IRC +1 Christine Perey: we haven't had much discussion of visualisation, which I see as missing from this list. Not just accessible on the web but also visible to people +1 jtandy: we'll gather thoughts on this through the mailing list. And would like a workshop on this in the December 2021 face to face OGC meeting (west coast USA) We should be looking systematialluy at the different user perspectives on interoperability..

[6a6d74]

Summary from the call - this is something to explore further.

Our discussion during the call on Issue #1270 indicated that data interoperability was still a big challenge. @rob-metalinkage noted that we lack a coherent "Web of data" that's scaleable; e.g. how do we make the semantics of features, such as geofences, available to people to use? @BillSwirrl added that he's spent a long time working to make government data interoperable. And it's still a huge challenge. The current community practice focuses on creating the "raw materials" (i.e. publishing data via APIs), rather than integrating data from multiple sources. We're still working in silos.

We had a clear steer from @prushforth and Christine Perey that visualisation of data remains underserved, commenting respectively on their interests in Maps4HTML and Augmented Reality. They both noted that bringing (geo) data to the Web means that you need to be able to visualise that data. Accessibility comes first. But then we need to be able to visualise data!

[6a6d74]

Calling all SDW-IG folks - please add your thoughts below about important topics that we might want to cover the proposed OGC Discussion Paper / W3C Note. We're hoping to use this doc to drive the agenda for SDW over the coming 2-3 years.

[prushforth]

@cperey:

we haven't had much discussion of visualisation, which I see as missing from this list. Not just accessible on the web but also visible to people

re: visualization rendered maps are accessible information for sighted individuals, depending on the disability. Christine is correct that we can't really start a discussion of accessible spatial information without first talking about rendered, visual maps. We need to build accessibility into our discussion from the outset, however, because you can't tack it on after the fact.

As @lieberjosh pointed out at last year's workshop:

There really is a continuum… between a flat map oriented north with a fixed extent and scale and… augmented reality where you really are looking at what’s around you and in front of you and having map objects placed into that view. … [A] Web Map that… is able to transition from… augmented reality to [a] mapped formalism of reality… can really be put into this spectrum…. GeoPose is an important part of establishing that continuum.

Not only is there a continuum between 2D Web maps and an augmented reality, but there is a continuum of accessibility for individuals of all abilities -> disabilities. We need to make our outcomes work across the continuums.

A critical first step in this direction is to get the browser engine, which renders content for visualization, to "understand" the particularities of geospatial coordinate reference systems [1], which are involved in everything from 2D Web maps, to processing geofences, to augmented reality. To accomplish that (which is at first a social problem, and once properly socialized, a highly technically specialized problem of a different nature), one needs a highly cogent argument for including "maps" in HTML. And that argument needs to be based on and start with accessibility and inclusivity.

So this is the nature of the problem domain that we are working on in the maps for HTML community, and we are looking for shared objectives and partners and contributors. Happy to "merge" [2], with the SDWIG if we can agree on objectives.

[1] as applied on the Web. Which might mean less today that it one day certainly will, because the Web should always "win". [2] I can't speak for everybody and we so far have a 100% public community group, but anyway, we'll work with any self-identified people and organizations who want to work with us. So maybe "work alongside and report into" would be a better approach than "merge", but you get the idea.

[FransKnibbe]

In my opinion, the single most important target for improving spatial data on the Web is interoperability. Many (probably all) other goals will be easier to achieve if spatial data have improved syntactic and semantic interoperability. This is argued in a position paper that I wrote for the GeoLD 2021 workshop: Models for Space Unite! -The Need and Opportunities for Domain–transcendent Modelling of Spatial Data. I hope you can find some time to read it, that way its contents won't have to be repeated here. But in a nutshell: the idea is that it would be good to have a general model for all spatial data (not only geographic data), and further development of GeoSPARQL (which is happening now) could be a way to get there.

Assuming a cross-domain spatial Web model exists, other ambitions that have been brought up become easier to accomplish:

• Native support for spatial data in Web browsers: This would be great to have, but currently there are a lot of competing models and structures to adopt, even when the scope is limited to geographical data. A universal Web model for spatial data in general would be a huge incentive for arriving at a universal way for Web browsers to recognize spatial data, to visualise them and to make them available for user interaction.
• The ability to have interoperable spatial data available on the Web could be a significant boost for the (semantic) Web as a data platform; it will be able to offer an extra unique benefit. That in turn should fuel improved leverage of existing semantic Web solutions for codifying metadata, provenance data and access control for spatial data.
• Authoritative registers will be easier to set up when they can be linked to or based on a general model for spatial data. The concepts of spatial reference systems and coordinate systems, for instance, are applicable to all kinds of spatial data. A general way to define and reference them will be a vital ingredient in practical interoperability of spatial data.

[rjksmith]

I have a few comments on the scoping statement which I thought may be relevant.

1. Conclusions from the WebVMT breakout at TPAC 2020 identified distance and speed as desirable geospatial functions which can be derived from a trajectory. This chimes with current suggestions and also includes temporal aspects for moving objects.

2. MQTT is being used in Testbed-17 Moving Features to link the various components together - ingestion, storage, tracking and analytics. Track fragments are identified from video by the ingestion service, linked together by the tracking service and analysed as moving objects by humans and machines with the goal of drafting an OGC API for Moving Features based on this software architecture.

3. The scope of WebVMT has expanded from just location to generic video metadata which may qualify as a web building block for metadata tracks (as a counterpart to WebVTT for text tracks) to render content dynamically in user agents including use of map overlays.

4. The WebVMT Police Evidence use case provides an interesting mix of citizen-friendly requirements for open access to enable public contribution, privacy, ownership, security and evidence integrity to ensure that submitted data are genuine.

[chris-little]

@rjksmith The OGC API - EDR standardises the representation of 2/3/4D trajectories, using WKT, with the same abstract model as OGC Moving Features, though different encodings. The Moving Features suite of standards have distance and speed/velocity as first class citizens. So maybe worth a look if you are not familiar with them.

[rjksmith]

Thanks @chris-little I'm aware. My point (1. above) was that the current scoping statement refers to static geospatial functions such as within, but doesn't mention dynamic temporal functions like speed. Comparison with OGC Moving Features as you suggest may help prompt more ideas for 'basic geospatial functions' on the web.

[ByronCinNZ]

I would like to see DGGS including in these discussions. While not yet widely implemented the promise it holds to move spatial more solidly into the LOD environment is great

[prushforth]

The immersive web community is looking to collaborate with the OGC GeoPose SWG on the topic of geo-alignment at TPAC, and beyond perhaps.