Communicate good practice for defining geofences in the Best Practices doc

[lvdbrink]

Based on discussion we had on the mailing list and in the SDWIG plenary session in May (minutes), we have come to the conclusion that

1. We have the standards to define geofences
2. we lack a way to express the rules on behavior

Based on conclusion 1, we have said we want to add a best practice about geofencing to the Best Practices document.

@ogcscotts and @claraboyd volunteered to take this action.

Conclusion 2 indicates new work. As a first step, I propose we describe this lack we identified as a Gap in the Gaps section of the Best Practices doc. Next, we can search for people who are willing to take on a work item to fill this gap.

Background / summary of discussion so far

As @tguild told us, the Automotive group would like to come up with a modest set of parameters that could influence whether an application is permitted to sample data on a vehicle. One of the parameters is geofence boundaries, which is what they want the SDWIG's input on. Their geofence could be in the form of an amorphous shape on a map, boundary of municipalities, counties, regions or a radius.

OGC staff has done some work looking into geofences and has a lot of knowledge available (see this report). They found we have an appropriate suite of standards and knowledge for geofences. Geofences may be defined in increasingly complex ways, starting with a point and radius to a box to an arbitrary polygon to a buffer around a corridor. And those fences can be 2D or 3D in geometry and have temporal characteristics for a period of validity. Finally, geofences include or exclude, e.g., leaving a fenced area can result in a trigger or entering a fenced area can trigger an action.

There are privacy considerations to this. AR also has geofencing use cases.

[tguild]

Based on the discussion within SDW and elsewhere, what I am hoping for is at least two conventions/standards around geofences.

One really capable as Scott described on the thread and call capable of handling range of use cases and nuanced representations - corridor along a road, dynamic protected airspace, etc,.

The other would be a more rudimentary representation, easier to define and transmit. I learned at least a couple participants in the Auto WG in practice use polygons, collection of lat/long points from which it is reasonable to calculate whether a given location is inside or out. One of the two participants also uses circles in addition to polygons which only needs one coordinate and a radius. There are open source libraries that do just that.

In the mail thread I wondered about GIS backed, where it is feasible to lookup if a given location is inside some geographic boundaries (which side of a river, inside or out of a municipality). Depending on where the fence is acted upon, in cloud or on vehicle or device, and its connectivity it may have to have cached data for be able to make that determination.

Precision certainly matters for many use cases and require more complex definitions but for other cases approximation is more than enough.

[lieberjosh]

The Testbed-17 API-X task includes a UAS geofencing use case if that would be of interest.

[prushforth]

In the minutes, I noted that the Web platform has no native representation of location, and so geofences can't be natively represented. Geofences seem (to me) to be a modern way of expressing a feature geometry, together with a desired application behaviour, perhaps based on spatial criteria.

What is really interesting about geofencing on the Web is that they point to a capability of the Web platform that has yet to be standardized, which is, support for maps and location.

"Wait a minute", you say, "nobody said anything about maps." Hear me out.

In MapML, we have specified the <feature> element, which has defined characteristics based on requirements inferred from existing practice and "new" ideas, in particular, ideas from the accessibility community, as I reported last meeting. Having a notification of a location-related event is a fundamental value for location information. I believe it is fundamental for the Web platform to support for the blind and other forms of disability, and so we think it is definitely in-scope for evaluation and implementation in MapML. Whereas a sighted user could look at a map and (+/- easily) say "Yep, I'm within that polygon", or "Yep, I'm near that gas station", a blind user or even an autonomous user agent would need to be able to do that processing and render the result as spoken text, or some other signal.

There is a specification effort in the W3C / WICG, called the geolocation-sensor API, which intends to modernize the existing geolocation API. One of the BIG requests for the geolocation-sensor API is to support geofencing capabilities. It seems that support for geofencing is currently blocked on privacy considerations: allowing a web site to track the user agent 'in the background' means that web sites can / will surveil users' location, even without being in the foreground.

How to bring this concept to the platform without compromising the privacy of the user and enabling big-brother background location surveillance?

If the browser itself had a concept of maps and location, as suggested by MapML, the browser (not the web site) could do the geospatial processing (in the background) for a set of features identified in advance, and yield the accessible result (a notification) when the geospatial criteria are met, without the server receiving the user's location in the background.

[PeterParslow]

I think a "geofence" is a particular kind of "feature geometry" with particular semantics. There are many other kinds: representative point, bounding box, footprint,...

All would benefit from a 'web native' representation, but I think we would be heading the wrong way if we established "geofence" as the main web native geometry expression.

One could also argue that a "geofence" is the bounding geometry of a particular feature: generally a feature that exists to monitor and report on movement. That would put the semantics at the feature level, rather than the "geofence" being one geometry of a feature (data item representing e.g. a gun / child / robotic lawn mower).

[prushforth]

All would benefit from a 'web native' representation, but I think we would be heading the wrong way if we established "geofence" as the main web native geometry expression.

I wasn't suggesting that.

What I was saying is that the Web needs a <feature> element, which doesn't make sense unless there's a <map> to draw it on.

a "geofence" is a particular kind of "feature geometry" with particular semantics.

I am suggesting that geofences of all kinds could be realized through the application of a "main native geometry expression" (your term) through the <feature>'s <geometry> when combined with appropriate client-side processing, which could be performed by the browser via an API. As a first approximation, I would say the semantics of a geofence processing could follow the Simple Features DE-9IM model via a browser-provided API.

One could also argue that a "geofence" is the bounding geometry of a particular feature: generally a feature that exists to monitor and report on movement.

Or maybe any feature that the user + website deem to be worthy of such an interaction?

[6a6d74]

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

brinkwoman: I'm not the owner of this, just wrote it down! But to summarise: different communities have a need for geofences and for standardisation in describing them
… We think we do have standards that could be used - generally just a polygon. But we lack a way to express the rules of what can happen inside or outside the geofence
… It would be useful to add to the best practices document. Scott and Clara have taken the action to write something

jtandy: There's a new piece of work - writing up for the best practices but also to develop a way of expressing the rules

Peter Parslow: The geofence is more than just a description of the geometry. It also has the aspect of expected difference in behaviour inside or outside the fence

PeterR: I raised an issue that the web itself (HTML, javascript etc) has no need for a description of features. (A geofence would be a kind of a feature). But browsers would need to understand feature semantics to process geofences on the client side
… there is a privacy danger to server side geolocation processing, which helps motivate understanding geolocation on the client side

ScottSimmons: This would be very interesting as a Best Practice. We can talk about the geometry, but it's the semantics of the geofence that makes it interesting. A great example of why we should have spatial data on the web. I volunteer to take a first stab at writing this up. OGC has had a go at a descriptor for one kind of geofence which could be more broadly applicable

jtandy: to confirm - getting a geofence into the BPs would be useful and there is OGC work that could act as a start

roba: current best practice is pretty much at the level of 'hasGeometry' but that doesn't tell you much about what it means. Relates to the HTTP-14 kind of issue
… there probably isn't a best practice yet, but having feature types that suit the end use and the ability to publish the feature types to describe the semantics of geometry properties would be part of any solution

jtandy: so in the OGC SWIG structure there is already work going on. Can SDWWG help? Coordination role?

Scottsimmons: certainly an early review would be good. And to get input from the experts in this group on how this could work in the SDW paradigm

PeterR: Accessibility for people with disabilities could be related to geofence semantics. Could provide extra information for people with particular needs.

jtandy: Scott, please add links to the work that has already been taking place as a comment on the GH issue

[6a6d74]

Summary:

• It really makes sense to include "how to define a geofence" in the updated SDW Best Practices
• OGC already have a draft spec for "geofence descriptor"; this has come from the UXS SWG (uninhabited systems?) so is pretty drone-centric, but there are additional contributions from @tguild from a simpler automotive usecase
• @ogcscotts says that OGC can take a first stab at defining a spec for describing the behaviour when interacting with a geofence
• @ogcscotts asks the SDW-WG to provide early review of draft specs, and to continue coordinating with the W3C groups

[6a6d74]

@ogcscotts - tagging you with a reminder to add links to the existing work in OGC. Thanks.

[ogcscotts]

The OGC write-ups on GeoFences can be found in the ANSI Unmanned Aircraft Standardization Collaborative (UASSC) Roadmap document here: https://www.ansi.org/standards-coordination/collaboratives-activities/unmanned-aircraft-systems-collaborative. Not quite a draft spec yet, but I will convert the requirements into a new document.

[lvdbrink]

@cperey mentioned to me that Michael McCool, the chair of Web of Things WG (several sub WGs) has some suggestions as stubs/places that would probably be useful starting points for writing up the geofencing section.

Consider this me reaching out to @mmccool. Michael, could you provide your suggestions here, as a comment in this issue?

[ogcscotts]

@lvdbrink I have text ready per my earlier comment - happy to insert, but just not sure to which branch I should issue a pull request

[lvdbrink]

@ogcscotts that's great! Use gh-pages... right @situx ?

[situx]

Correct, you can use gh-pages for that