Re: [Slashcode-general] GeoRSS and Google Maps API Plugins for Slash

[Larson, T. E. <TEL...@we...>]

shane wrote:
> On Aug 29, 2006, at 10:16 AM, Larson, Timothy E. wrote:

> http://www.lottadot.com/projman.pl?op=3Dview&id=3D15
>=20
> I had started that zipcode plugin, well, a very long time ago. As far
> as I recall, it was functional last time I messed with it. If you can,
> take a look at it, specifically the schema and the data it contains.
> From a quick glance, it looks like it has lat/long information by
> zip/city/state.   =20
>=20
> However, defining boundaries w/ landmasses et all, er yuk.

Don't have time to look right now, but it sounds like it's a step in the
right direction.

>> Precisely!  That was my original vision for how it would work in that
>> low-pri request.  It would be a fourth piece of data along with
topic,
>> section, and author.  One would be able to filter the homepage on
>> location just as with those three.
>>=20
>> In fact, 699047 describes an enhancement to home page customization
>> that would make use of this field.  Since that request, a different
>> enhancement has been done, but the idea of using locale is still
cool.
>> On slashdot, for example, sure it's interesting that some big
business
>> 10 timezones away is switching operations to Linux, but I'm also
>> interested in the much less earthshaking news of an Open Software
>> Festival sponsored by a high school club in the next county.  By
>> adding support for location, big sites can still cover local news
>> without "spamming" the non-locals.
>=20
> How would this be any different from having a topic-nexus defined that
> would hold all stories associated with a certain area?=20

It probably wouldn't be...just a different implementation of the idea.
Slash topics have become much more...tag-like I suppose.  Having
separate fields reinforces the notion that they are different types of
data, but from the user perspective of "being able to focus in
interesting stuff" it doesn't really matter much.  If you can intersect
two sets of information to get the interesting subset, that's the
important thing.

> I bring that solution up, because that doesn't entail modifying any
> source code, nor schema. So far, to get the functionality that's
> mentioned on the project homepage ( http://lottadot.com/projects/
> slashmaps ) I've not had to modify all that much source code to get
> these things to work. Mostly we're using topic_nexus_extras to store
> the information, and modified templates to show it. (I did have to
> complete the skins editor, and the skins_params, but that's another
> topic).      =20
>=20
> Inorder for one to be able to essentially search by story.location
> (let's assume that's what it's called) efficiently, at first thought I
> would think we'd have to modify the stories table schema, add that
> column, and then modify all the story code (getStoriesEssentials,etc)
> in Slash.pm as well as retool a bit of Slash::Search. Then add a bit
> to the edituser page that would let them set the 'region/place'    =20
> limiting options (just like they can exclude authors, topics).
>=20
> At first glance, that seems like quite a bit of work. Maybe there'd be
> a better way to do it. Any thoughts? I'm all ears.=20

Nope, that's pretty much what I thought I'd have to do someday, when I
submitted the request.  Reworking of topics to allow for multiples and
the behavior we have now essentially allows the same thing, and more
easily.

> Another question I would have, is if you're wanting to associate a
> story with a location, how do you let a user exclude? by proximity to
> that location? how do you define proximity? lat/long? within XX miles?
> but that's US, so you'd want to investigate using an alternative
> metric.   =20

This is where treating geo information specially would be helpful.  If
the lat/long input simply gets mapped to a topic (which you can filter
on, of course) you lose granularity/flexibility.

You could do both, of course.  Using a topic nexus would be quick and
easy, and give rough idea of location.  For most sites I imagine that
would be sufficient.  Adding support for <proximity> to <location> as
well would be a refinement down the road.  Flagging things in my
immediate vicinity for homepage display (that I otherwise might not care
about) would be cool.

Tim
--=20
Tim Larson
West Corporation, Interactive TeleServices
Eschew obfuscation!