Greetings,
I am currently doing some prototyping of what I am calling
"geobeacons"... It is very similar to Google's concept of a "physical
internet" but it moves from relying on uri encoding into strings which
may be too long, to instead adoping a model such as RadioDNS.
As a brief background, Apple has been promoting the concept of iBeacons
- this is a Bluetooth low energy device which sends unsolicted
"advertisement" packets out periodically. Smartphone applications can
be written to monitor beacons received and to "do something" upon
receival[display an advertisement, show distance to a meeting room, ping
a web server, etc].
An iBeacon is extremely small and consists of a 128 bit unique
identifier, a 16 bit "major" code, a 16 bit "minor" code, and an 8 bit
transmission power code.
The initial thinking had been that a single company would establish a
single 128 bit identifier for all it's "beacons" and use the major and
minor codes to identify a specific beacon.
My thought is to convert this iBeacon format into an open format that
does not depend on closed source applications.
The major and minor codes would instead be used to contain a single
32-bit long geohash. This resolves the issue of multiple beacons in the
same area, since no beacon will physically reside at the same latitude
and longitude[excepting being placed at different altitudes - in which
case since the latitude and longitude are assigned to the device, they
can be fudged 1 bit for multiple devices].
All geoBeacons would be expected to start with a specified string of
bytes 32 bytes - represented in hex as GE0B. This then leaves the
remaining 96 bits for use as a semi unique identifier[since many
individuals run smartphone applications which display the uuid, it is
expected and encouraged for users to use hexspeak for the amusement of
their customers].
By running some form of central lookup service, either web based or dns
based, the combination of the 96 bit code and the latitude and longitude
can be used to retrieve a uri which can then be loaded to provide
content for the user that can be specific to an event/company/person.
I ran across the OSGEO group while researching various aspects of this
and wanted to reach out for commentary and suggestions to this group,
especially when it comes to utilizing existing standards. Keeping in
mind that smartphone applications have a fast development cycle, any
standards implemented must be uncomplicated and simple. JSON is
preferred to XML, there is not a need for quite the level of detail of
the current open GEO standards - while more complicated applications
should be encouraged to reuse existing open GEO standards.
[IE to develop a simple time and location sensitive offer, all an
application developer needs to do is provide an uri where the offer is
available in html format, and then register their beacon code along with
optionally the latitude and longitude codes.
Any query system must be smart enough to be able to not only lookup a
specific unique id and geohash, but also to provide lists of all beacons
at a specific geohash, and also have the ability to provide unique id's
that are "close" to a geohash.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss
