allow coarse location for devices

[zven]

How about we allow for a coarse location setting for devices? I could imagine that some users would like to use the openSenseMap for their devices but would be hesitant because you have to publicly add its precise location.

Assuming that you set up your device at your own home, you would effectively publish your home location broadly available on the internet.

Taking a random device located at a single family house in a village and a few minutes on Google Street view, it was easilly possible to identify the home owner.

Some ideas:

• Define the center point of a region by allowing to set the decimal places to only 5, for example, to define a rough rectangle.
• Split the globe in regions sized X by X meters and let users select only one of those square regions.
• Save the that information in the device so those consuming the data could handle it appropriately.

[scheidtdav]

Very interesting idea!

I think users could continue to enter the precise location and it is a matter of how we proceed with it.
When I am looking at my own devices, seeing the precise location would be fine (same for API requests).

However when looking at the publicly available data, we could apply what AirBnB is doing as an example. We use the precise location to define a "random" circle in the area and show that instead.

I think the term "geomasking" is correct here.
The only thing I am wondering about is, if this would make the data unusable for scientific purposes? (@robarto any ideas?)

This will also not affect the archive. What location would end up in there?
How would we handle existing data?

[jona159]

Based on this conversation i opened a draft PR that could be discussed in this context.

It introduces:

• Geomasking for device locations so devices can expose either an exact or approximate public location.
  Geomasking is done via the [donut method](https://academic.oup.com/aje/article-abstract/172/9/1062/148483?
  redirectedFrom=fulltext) so public coordinates are deterministically displaced from the exact location by at least a defined
  minimum distance (defaults to 20m atm) and at most a defined maximum distance (defaults to 50m atm).

• Public API and device queries return masked public coordinates (calculated on the fly) unless the user opted in to sharing the exact coordinates for this device.

• Exact coordinates are available for owner/authenticated device views.

• The location privacy can be configured in the device creation and location edit flows.

• Image metadata is stripped for uploaded device/profile images to avoid accidental GPS metadata exposure.

• Mobile measurement location data has not been taken into consideration here as masking the mobile locations with the donut
  method would probably still allow to derive information about the actual track. However, the sensebox:bike app already allows to
  define privacy areas where no data is recorded.

For data that is transmitted to the archive we could add metadata to the location of devices to include information about whether the coordinates are exact or masked. For this the archival script would need to be adjusted.

[scheidtdav]

What about the API?
I think we should probably default to a geomasked location for requests via the api as well.
I'd argue for distances to be chosen arbitrarily (between the aforementioned values of 20-50m) when requested via api.

Regarding the archival: Since the process needs to be defined for the new osem, I don't think this would be a problem to implement.
From a research point of view, the metadata is crucial. Imagine wanting to study the noise pollution in cities. You'd almost always want to correlate that to certain streets where a 20m offset can potentially already be in a side street. You'd definitely want to know about that :-)

Regarding migration (discussion question): Should we migrate every existing user to a "private" location?

[zven]

We should definitely add information about the geomasking to the metadata, as @scheidtdav has highlighted.

As for the default case and the migration, it might be worth getting input from @mariopesch and @robarto.