W3C home > Mailing lists > Public > public-automotive@w3.org > March 2021

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

From: Ted Guild <ted@w3.org>
Date: Wed, 31 Mar 2021 09:30:56 -0400
Message-ID: <87cc9dc69df3bcea6c11213da94cd30e48214329.camel@w3.org>
To: Ed Parsons <eparsons@google.com>, Scott Simmons <ssimmons@ogc.org>
Cc: Joseph Abhayaratna <joseph.abhayaratna@geoscape.com.au>, "public-sdwig@w3.org" <public-sdwig@w3.org>, public-automotive <public-automotive@w3.org>
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
> eparsons@google.com
> +44 7825 382263 @edparsons
> 
> 
> 
> On Tue, 30 Mar 2021 at 20:39, Scott Simmons <ssimmons@ogc.org> wrote:
> > Hi Ted,
> > 
> > OGC staff contributed to the requirements assessment for the
> > Unmanned Aerial Systems work in ANSI (see the roadmap here: 
> > https://www.ansi.org/standards-coordination/collaboratives-activities/unmanned-aircraft-systems-collaborative
> > ). 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
> > ssimmons@ogc.org | ogc.org | @opengeospatial
> > 
> > Sign up for OGC News
> > 
> > > On Mar 30, 2021, at 1:23 PM, Ted Guild <ted@w3.org> 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 <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto
Received on Wednesday, 31 March 2021 13:31:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 31 March 2021 13:31:06 UTC