Sounds like an awesome idea. My group has been talking about this already. We'd like the ability to be able add custom sites on the server side (to correspond to our work sites) or to able to reference our own geomapping db from laconica.
On Sun, Apr 12, 2009 at 9:51 PM, Evan Prodromou <[email protected]> wrote: > 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 > -- Mark "Blessed is he who finds happiness in his own foolishness, for he will always be happy." _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
