LocationPlan

From StatusNet

Jump to: navigation, search

StatusNet will use locational (geospatial) information and services intelligently to enhance users' experience.

Location will be stored against:

  • users: where they are based, hang out
  • notices: could be either a place the notice refers to or where it was submitted from.

The information can be used by clients to add value for user activities, particularly geography-based discovery tasks.

(There might be a case for storing it against groups, but it seems redundant given that notices and user members will be located.)

Contents

[edit] The structure of a location

In the abstract, we may choose to define a location as:

  • point: latitude/longitude combination (decimal, to save our sanities); OR
  • (we might support a third point dimension, elevation)
  • named place: a place with an extent larger than a point, listed in Geonames, and referenced by its Geonames ID; OR
  • OSM object: a node, way, or area existing in the extensive, community-contributed OpenStreetMap database

We could extend this to encompass one or more of these concepts:

  • fuzzed point: a point which has been slightly offset in a random way to respect privacy
  • line: a sequential series of points not ending at the starting point (e.g. walking tracks)
  • area: a sequence of points which close at the starting point, defining an inner extent (e.g. forests)

The practicality of posting notices with accurate instances of the last two forms is in doubt.

It seems wise to begin an implementation representing locations according to the simpler first three definitions.

Database tables and the classes they represent will require fields/properties for latitude and longitude. We also want one field for a Geonames ID and one each for OSM object ID and type {TODO: find out if OSM IDs can determine object type}. It is unlikely that for a given location instance, both a Geonames and OSM ID will be provided, but normalisation issues are an aside for now. Lat/long, however, should always be stored redundantly where one of these IDs is provided, to speed up renderings, and also because OSM objects have been known to disappear :-[

Developers should make these interpretations based on the populated status of fields/properties in a location instance:

  • where both Geonames and OSM ID are null, the location is a simple point
  • where either are populated (should only be one), the canonical location is that identifier and lat/long is redundantly populated for map pin renderings
from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:
  • We'll enhance the profile table (and corresponding class) with three location fields: latitude, longitude, and Geonames ID. Geonames is a geographic thesaurus -- it maps multiple names of a place to a single numeric ID. This is an efficient way to store information about a place much bigger than a single point. For example, setting your location to "Dallas" will set lat and long to 32.78306 & -96.80667, and geonameid = 4684888. Geonames's database is available gratis under a CC-By license, btw. Lots of freedom there.
  • We'll enhance the notice table (and corresponding class) with the same three location fields. When a new notice is saved, we'll save the current value of the three fields from the profile into the notice. So, if you dented from Cairo, but you're now back in Des Moines, we'll know where that dent actually happened.

[edit] Location interfaces

These are the principal methods by which users and applications will interact with location instances.

[edit] Select

The primary way to select a simple point will be on a graphical map using an OpenLayers widget displaying OSM data. We should try as much as possible to code the widget according to progressive enhancement principles, for both accessibility and simplicity. The map widget should be accompanied by synchronised HTML text controls showing the currently selected latitude and longitude. The HTML controls should be fully enabled. A change in either the map widget or the control should be reflected in the other.

We may require a checkbox for users, which will obfuscate precise locations for privacy reasons.

We might also support direct entry of OSM permalinks and shortlinks, though these locations should ultimately be tweakable by users a la Augmented selection. We would need a geohashing library to decode OSM shortlinks.

Named places could be selected:

OSM objects might be selected:

  • using OpenLayers (with the data layer enabled)
  • by direct URL or object ID input in a text box (which should be available anyway as part of progressive enhancement)
  • using the Name finder search
  • through suggestion from a list of names in the current OpenLayers widget viewport (this can be a ridiculous number), or
  • using a history or favourites system.

Users might struggle to understanding and choose appropriately between points and named places or objects. This may not even be a real problem. They may also struggle with the complexity of having to choose, so there is an interface challenge.

[edit] Recall

Ideally, the last selected location will be saved in a cookie and presented as the default for the next selection. If a cookie is not set, the user's home location may be selected by default. If this has not been set, we may try an open IP address lookup service, The absolute failover location might be … Canada? This is similar to the way the OSM site selects its initial view.

Potentially, a history of the last few selected locations could be presented for quick selection as many users will reuse locations. Alternately, there could be a favourites system for user locations.

[edit] Augmented selection

Users browsing a map widget might be presented with named locations and OSM objects within its view, so that they can select as appropriate.

Users should also be able to directly query for named locations and OSM objects. This interaction may end with either a selection of one of these names, or with a precise point (lat/long) that they have found using the search to help them zero in on the location.

from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:
  • When we update a profile's location, we'll try to geocode it using geonames. We'll take the human-language description that comes in and feed it directly to geonames.org's Web service (or another such service, config option) and hopefully get out a lat, a long, and a geonames ID. We may in the future try poking at the location first -- say, if it looks like a lat/long pair, or like a postal code + country.

[edit] Inline coded selection

Should StatusNet supported a syntax (that is, one that the HTML and client parsers recognise) within notices to denote locations, just as it supports #tag, @user, and !group?

For points, this could work: 

*-27.4780,153.0127

This renders easily enough as a link, but without a zoom level. Zoom levels can be provided in the URL, but a suitable one would need to be determined. We could use the level of precision in the coordinates to derive this. The syntax is a little long, especially if you want precision.

If OSM objects are supported, referencing them would require another syntax, adorning the ID. {TODO: see above re finding out if OSM IDs are unique across object types}

In a similar way, it might be possible to trigger a Geonames lookup inline using syntax like: 

*Brisbane

Users would need to be very confident in a single Geonames match for this to come off.

[edit] Render

Interactive maps can be rendered using OpenLayers widgets with OSM data, without any license issues. (It might be possible to allow installations to choose other map renderers and datasets, as part of configuration, if they have the necessary keys/licenses.) OpenLayers should fulfil just about any requirement we might have for rendering on a web page in a StatusNet instance.

On the rendered web interface, locations might be shown:

  • adjacent to "located" notices
  • with profile information (showing home location(s) - see Privacy)
  • a map of user locations, subscribers locations (showing home location(s) - see Privacy)
  • going with any timeline - personal, group, tag, query, popular
  • in another search tab, "Location"

Inline maps should generally be accompanied by links to full interactive maps. For rendering maps with multiple markers/pins, we would need to create KML/GPX/etc dynamically at a URL and look outside the OSM website, as it does not support loading these files in by URL (as Google Maps do).

We might make use of Geotag icons to signpost related geographic data links.

from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:
  • We'll support a map view of your personal incoming timeline. This will be another tab on your personal tabset, and will by default use OpenStreetMap data and an OpenLayers widget.

[edit] Other representations

StatusNet should output GeoRSS as metadata for RSS and Atom feeds at entry and/or feed level as appropriate.

For web pages, we should embed Geo microformat markup (or possibly geopsatial RDFa?), so that plug-ins, intelligent user agents, and clever search engines can do amazing things with our web pages. (It's all about exposing lots of linked interfaces into our data.) This markup is embedded with individual notices.

For feeds and web pages containing a "set" (with maybe only one member) of located users or notices, we should provide <link> elements in the head, pointing to a KML or GPX file containing those locations with descriptive information.

from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:

[edit] API support

The API should support several serialisations of location in its payloads and responses.

[edit] Location functionality

These are the features that could be available using locational information.

[edit] User and notice location

  • anyone can find, and display as pins on a map, users or notices within a geographic extent (this becomes another search option tab - maybe two)
  • any map pin views (for showing a set of locations) can be exported as KML/GPX, with users' avatars and text used in the descriptions where applicable
  • web interface users with browsers supporting the hGeo microformat (or RDFa?) can exploit its capabilities (like, maybe, opening their favourite mapping application, or an OSM editor)
from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:
  • We'll support the location parameters for the search API.
  • We'll support location search in the Web interface; "Find people within 10/20/30 km." "Find people also in Dallas." "Find notices made near this point: lat/long". "Find notices made in New Jersey."

[edit] User location

  • users can select, change and unset their home location from their profile settings
  • users' location can be used to guess-populate timezone and language settings when signing up {already happens?}
  • users can view their friends as pins on a map
  • anyone can view group members as pins on a map
  • everyone can view a user's subscribers as pins on a map
  • everyone can view a user's subscriptions as pins on a map
  • anyone can view a single user's location in their profile where it has been set
  • all users can be browsed/discovered by map

[edit] Notice location

  • users can attach locations to notices they send ("geodenting?")
  • notices from applications on devices with (or communicating with) GPS devices will be able to exploit this interface to make geodenting simple (for example, the developer of Mobidentica and Mobile Trail Explorer are the same - *hint* :) )
  • anyone can view a single located notice on a map, and links to map displays adjacent to them in listings (timelines)
  • anyone can view a user's personal timeline notices as pins on a map
  • anyone can view a user's replies as pins on a map
  • anyone can view a user's notices as pins on a map
  • anyone can view a user's favorites as pins on a map
  • anyone can view a group's timeline as pins on a map
  • all notices can be browsed by map (hmm, scaling)
  • available feeds for sets of notices contain geoRSS metadata for entries corresponding to located notices
from http://mail.laconi.ca/pipermail/laconica-dev/2009-April/001225.html:
  • We'll support additional lat, long, and geonameid arguments to post a new notice in the API, which will override what we have stored for the profile. I seem to remember that Twinkle had some standard for doing this; does anyone have a link?

[edit] Issues

  • Privacy etc. (see http://lists.status.net/pipermail/statusnet-dev/2009-April/001244.html)
  • hGeo or RDFa?
  • should each user have a "home" location, which can be temporarily overridden as default denting location by a "current" location?
  • is elevation worthwhile?
  • should groups be located?
  • will users select appropriately between points and named places and OSM objects? (or will it become a mess? will it just confuse them?)
  • is location to be specified inline with notices, outside of them, or both?
  • "Whether to try to use MySQL and/or PostgreSQL's native support for geographic points. Worth it?" (asked by Evan and response provided)
  • "Is supporting geonamesid's going to be more hassle than it's worth? I'd like to save that valuable information about what a user input, in an efficient form. I think using geonames id's is the best bet: global, free-for-any-use IDs (some such IDs are part of proprietary vocabs), fairly good coverage." (asked by Evan)
  • is there a need to somehow distinguish between talking about a place and denting from a place?

[edit] Use cases

[edit] Coding requirements

  • database extensions
  • class extensions
  • search functionality extended
  • API support:
    • post notice
    • get notice(s)
    • (etc)
  • user location tab
  • user profile settings editing
  • (more)

[edit] Privacy

[edit] References

Retrieved from "http://status.net/wiki/LocationPlan"
Personal tools