Re: GeoSitesBackend update
- From: dave <davidr sucs org>
- To: Edd Dumbill <edd usefulinc com>
- Cc: dashboard-hackers gnome org
- Subject: Re: GeoSitesBackend update
- Date: Fri, 27 Feb 2004 15:30:42 +0000
Hi Edd,
Firstly, thanks for your feedback.
> I'm a little uncomfortable with the conflation of Point with something
> that's not a point but an area, to be honest. Even if we got lat/longs
> for areacodes it would still mean something slightly different.
>
> Essentially the process of going from (lat, long) -> city name is
> different from going (phonecode) -> locale.
I agree with this. In fact I think it would be a good idea to separate
out a LatLong class from the Point class (which should contain a LatLong
instance as well as city data etc). We can reuse this in a Locale class
also.
> (2) recognise these are different things and split them out from the
> Gazetteer into a different class. What you're finding is
> essentially localities. You could have a class Locale, and then
> TelephoneLocale, PostalLocale and so on when you add in different
> data sources later.
I think this is a good approach. We can give this class a way to
generate a list of Points (cities in the locale). The match generator
will need to be changed too. The obvious question is, how do you define
a locale? List of cities? Polygon of lat/long coordinates? My
inclination would be a lat/long for the approximate centre, plus
approximate radius of interest. Match relevance can be scaled according
to distance from the centre. But this can be hidden inside the locale
class anyway and in fact different subclasses could do it differently
depending on their dataset.
I'll look into these changes and post some code in due course. Also I've
got some postcode->latlong code going, along with UK & US datasets, so
we should be able to generate local info from addresses too.
Cheers,
dave
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]