Re: GeoSitesBackend update

[Edd Dumbill <edd usefulinc com>]

On Fri, 2004-02-27 at 15:30 +0000, dave wrote:

> 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.

I'd go the other way, if you wanted to refactor...  the members I've got
here are debatable, but for illustration

  Locale (name, region, country)
    |
    +--- Point (has lat,long too)
    +--- PhoneDistrict (has STD code)
    +--- PostalDistrict (has postal code, also conceivably lat,long)

The Point there should probably become City.

However, this refactoring is likely overkill for now.

> >  (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 don't think you need to go this far just now.  The issue is that areas
aren't points and are something different.  The separation doesn't
matter to the user, as the GeoSites backend will aggregate their display
anyway.

In terms of code, the Locale class is simply the (area name, region,
country) stuff you already have, without the bogus lat,long.

-- Edd