Re: Geo-fencing for responsible use of spatial data from vehicles

There was also use of fences in SCIRA, but as filter / exclusion zones for routing, e.g. route emergency vehicles to incident zones, route public vehicles around them. Defined as polygons for this purpose, optionally with intervals of time validity. There was tracking of responders and their vehicles for coordination purposes, but not of others. Routing was also used to facilitate public evacuation, through random provision of multiple escape routes, but we did not incorporate larger traffic monitoring a la Waze to do so.

Since it seems valuable to use a given geometry or feature for different purposes, it might be most important to have a well-defined set of predicates for connecting such geofence features to particular actions or conditions.


Josh Lieberman, Ph.D.
Director Innovation Programs | Open Geospatial Consortium (OGC)
Office: +1-617-431-6431 | @geospatialogist <> | <> | @opengeospatial

> On Mar 31, 2021, at 9:30 AM, Ted Guild <> wrote:
> Thanks Ed and Scott for the responses.
> Scott,
> Thanks for the pointer and agree fences can be far more complicated
> than I was initially describing. Some of those you mention didn't occur
> to me.
> Ed,
> Temporal constraints are currently used as well, sometimes in
> conjunction with other parameters. Use cases vary pretty widely. On/off
> hours for when to track a commercial vehicle an employee is allowed to
> take home for convenience is not uncommon.
> There are organizations using fencing schemes in practice, allowing
> user to draw boundaries or identify in different ways in map within an
> app. I may for instance be alright with my vehicle information being
> collected for certain specific purposes (eg traffic congestion or road
> condition monitoring) outside my town and surrounding area. I could be
> more comfortable contributing data that isn't tracking my daily
> activity around my community, even moreso if anonymized/unattributed,
> that helps reduce congestion, improve road conditions or provides some
> other direct or indirect benefit.
> Given the further complexity Scott elaborated on, agree simpler may
> well be better than more capable/nuanced. Simple geometries such as a
> rectangle or circle are much easier to represent. They may not be
> adequate enough for some though, especially as we are already seeing
> more capable UI being used. 
> On Wed, 2021-03-31 at 12:23 +0100, Ed Parsons wrote:
>> A key concept from a privacy protection point of view would be
>> maintaining anonymity, because of the temporal sensitivity of
>> vehicle tracking data that might call for limitations in data capture
>> at the beginning and end of each journey to hide start and end points
>> which could be associated with home and work addresses for example.
>> So rather than a geofence a time fence might be a useful concept ?
>> In terms of actual spatial limitation I would keep it simple to a
>> minimum bounding box perhaps, although surely there is a natural
>> limitation in terms of the range of the sensors onboard the vehicle ?
>> It's great to have this conversation !
>> Ed
>> Ed Parsons
>> Geospatial Technologist
>> +44 7825 382263 @edparsons
>> On Tue, 30 Mar 2021 at 20:39, Scott Simmons <> wrote:
>>> Hi Ted,
>>> OGC staff contributed to the requirements assessment for the
>>> Unmanned Aerial Systems work in ANSI (see the roadmap here: 
>>> ). There are standards that can be used to represent a geofence,
>>> but no standard to exactly describe a geofence in general (there
>>> are specs for various industries for domain-specific fencing).
>>> In short, 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.
>>> Best Regards,
>>> Scott
>>> Scott Simmons
>>> Chief Standards Officer | Open Geospatial Consortium (OGC)
>>> Office: +1 970 682 1922 | Mobile: +1 970 214 9467
>>> | | @opengeospatial
>>> Sign up for OGC News
>>>> On Mar 30, 2021, at 1:23 PM, Ted Guild <> wrote:
>>>> Hi Jo and Spatial Data experts,
>>>> The Automotive group would like to be able to come up with a
>>>> modest set
>>>> of parameters that could influence whether an application is
>>>> permitted
>>>> to sample data on a vehicle.
>>>> We already have granular access control for signals so an
>>>> application
>>>> should be restricted to only information deemed pertinent and
>>>> would
>>>> likely only send a subset off the vehicle for
>>>> bandwidth/cost/privacy
>>>> considerations. We figure we can influence the access control
>>>> authorization system based on additional parameters.
>>>> As to thoughts on parameters for restricting data collection we
>>>> have a
>>>> few that initially come to mind:
>>>> * Time of day, concept of eg off-work hours and personal use of
>>>> company
>>>> vehicle
>>>> * geofence boundaries**
>>>> * explicit opt-in/out override on a whole as well as granular per
>>>> data
>>>> point, specific purpose
>>>> Geo-fencing in particular is what I'm hoping to get input from
>>>> the OGC
>>>> +others crowd in SDW group. 
>>>> The shape of the "fenced" area can vary. We are hearing in
>>>> practice,
>>>> the privacy settings may involve user drawing an amorphous shape
>>>> on a
>>>> map, specify municipalities, counties, regions or give a radius.
>>>> Representing that concisely is our problem. A simple rectangular
>>>> shape
>>>> would require four sets of coordinate, radius one coordinate and
>>>> a
>>>> distance plus means to calculate, county or other geographic
>>>> boundary
>>>> could be a look-up based on current location, and a free drawn
>>>> shape
>>>> more complex. 
>>>> Is there a geo-fencing definition convention or standard that
>>>> might
>>>> facilitate?
>>>> If there are other thoughts this question provokes or suggested
>>>> references, please share.
> -- 
> Ted Guild <>
> W3C Automotive Lead


Received on Wednesday, 31 March 2021 13:40:48 UTC