Hi, everyone. So, I realize it's looking a little bit forward, but I'd
like to discuss how I anticipate adding some location services to
Laconica for 0.9.x version. The goal is to store location information
for both people and notices, and provide input and output of that data
to clients.
So, in no particular order:
* 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.
* 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.
* 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.
* 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?
* For output, we'll add georss (http://georss.org/) to our RSS and Atom
feeds.
* We'll support the geo microformat (http://microformats.org/wiki/geo)
in HTML output in profile lists and notice lists.
* 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."
* 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.
Some things I'm not sure of:
* Whether to try to use MySQL and/or PostgreSQL's native support for
geographic points. Worth it?
* 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.
Anything missing here? Any of this a bad idea?
-Evan
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev
