Hi, Looks very nice!
Evan Prodromou wrote:
I don't think the geo extension in MySQL is worth it just to track location. If you have lots of data in your installation, maybe the geo stuff in Sphinx can be used to speed things up instead. I don't know how compatible MySQL/Postgres is in that regard, but Sphinx should hopefully work the same on both.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.
I do like keeping the geonamesid as well, but I don't really know what use it would be above being able to debug where the long/lat came from. I guess it might be useful to be able to do a lookup later on other things stored in the geoname database. For that it would be handy if you could install the table locally and do lookups that way instead of using a web service.
If you're running a smaller private installation, it might be useful to break out the long/lat and only have a location (int) field everywhere and then a separate location table with the a local primary key, a local name, long, lat, and geonamesid. It would then be a cache for known locations and be filled in by the user or from geoname.
MvH,
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
