[Imports] WiFi Hotspots in SA

Greg Troxel gdt at ir.bbn.com
Wed Jul 6 22:59:30 UTC 2016


Michael Graaf <graaf.michael at gmail.com> writes:

> I write on behalf of a team preparing to create an app (free as in beer as
> well as in speech) which will help users find WiFi hotspots and also review
> them or report new ones. We already have some data-sets which appear to be
> public-domain, but these things keep changing hence our intention to have
> real-time crowdsourcing.

Presumably you have seen
  https://wiki.openstreetmap.org/wiki/Key:internet_access
and the rejected proprosal
  https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/WiFi_Zone/Hotspot&oldid=868868

It's good that you are thinking about licensing from the beginning.

The standard opinion in OSM is that reviews don't belong in the
database.  But public hotspots seem to be viewed as appropriate.

> Initially we thought of using both Google Maps and OSM but on closer
> investigation, discovered that above a minimal level of use, Google API
> costs some dollars, so we discarded that idea.

Google Maps also tends to allow only tile viewing, not access to vector
data.

The big problem with users editing data is ensuring that the edits are
aligned with existing data.  For people who learn to use the editing
tools and look at the whole db near the hotspot, this works, but it's a
huge barrier to entry.  The other extreme is a "add this hotspot" button
in an app that takes lat/lon and hotspot info and just adds a node to
OSM without checking if it's there - which of course isn't ok.  In
between there is some degree of looking for existing nearish hotspots
and verifying if the new one is the same or not, and doing that as
automatically as possible while causing acceptably little trouble.  This
is going to be the hard part of your project technically.


I can see two approaches to what you want to do.  One option is to make
a database of hotspots separate from OSM, with lat/lon for each.  Or
perhaps also a reference to an object in OSM.  Then you can display that
on an OSM basemap.  The db could have information about ssid, bssid,
channel, etc., which is beyond what probably belongs in OSM. 
editing the db is really just about making sure there isn't an existing
object for the hotspot.  Avoiding dups should be relatively easy.

The other is to maintain the main data for a hotspot in OSM, adding the
internet_access=wlan tag to (probably) an existing object.  Again you
may wish to maintain some data that is too detailed for OSM, and
associate that with the OSM object.  This has the advantage that changes
by OSM editors are reflected in your app's data, and your app's edits
will help others.  You will need to ensure that contributions from your
user's meet the Contributor Terms, both in not violating existing rights
and granting adequate rights.  One approach might be that the app only
adds hotspots it is observing, so the users have first-party data, and
to get them to agree that contributions are PD.

With this second approach, the hard part will be to find the right
object in OSM to modify, but if the facility with the wifi is mapped,
that may be easy as multiple choice of nearby, and if not, adding a node
with just the internet_access=wlan tag is arguably reasonable.


You are writing to imports, but to me the user-contributed data does not
feel like an import.  It's a different kind of change to the OSM db that
needs extra scrutiny (the structure, not each edit), though.

You mention an existing database.  The import norms (see the wiki) are
that you post the actual data, the license, scripts to transform it to
OSM changesets, and all other info about what you are proposing to do.
Pay extra attention to how hotspot info will be merged into existing OSM
objects, so tha the resulting data is no messier than humans would
create.

An alternative is to have the app search the union of OSM and the other
datasets, and to offer to upload a point to OSM, with human choosing
help, when the user is actually observing it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20160706/8eff97bb/attachment.sig>


More information about the Imports mailing list