better yet, be able to save multiple "favorite" locations in your profile so that you don't have to screw around with finding where a place on the map when you want to make what is supposed to be a quick 140 char dent :)
On Tue, Apr 14, 2009 at 12:30 PM, Craig Andrews <[email protected]> wrote: > I have two questions which have been bothering me a long time about how to > implement location awareness: > > 1) How can privacy levels be specified, or in other words, intentional > approximation? For example, I may want my dents to be marked as > Washington, DC, but I don't really want people to know I'm denting from > 1600 Pennsylvania Avenue. Marking the location for the dent as being, say, > the geographical center of DC isn't very good... if you do that, > statically analysis of dent location data would get serious messed up, and > it reduces the value of the data for analytics. Allowing people to "fuzz" > or specify that only their city, or state, or even just their country be > included as location-meta would be nice. > > 2) How can I dent about locations other than where I am actually located? > For example, I may say "I heard that the pizza at Cask'n'Flagon is pretty > good!" What location would/should be attached to that dent? Where I am, or > the location of the Cask'n'Flagon? > > From a UI perspective, I think having a little button next to the text box > where a user enters their dent that, when clicked, displays a map centered > on a best guess of their location, which the user can then change (by > clicking), would be nice. That way, users can specify per-dent locations > without changing their profile (which you support with the API as > described below, but not via the web interface as far as I can see). > > Just my 2 pence, > ~Craig > >> 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
