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
