Re: GeoSitesBackend update

[Edd Dumbill <edd usefulinc com>]

On Thu, 2004-02-26 at 16:33 +0000, dave wrote:

> As I mentioned in my previous email, much of this code needed to be
> moved into utils/geo/gazetteer. This version of the patch fixes this
> problem.
> 
> I think it's now in good shape; probably the areacode data could do with
> some extra fields (e.g. lat/long), but as it stands it generates matches
> quite nicely.

Good work.

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.

Your patch to the Gazetteer makes it conceptually difficult to
understand and dilutes the semantics of the Point and City concepts.

Either we need to:

 (1) say we'll chain (lat, long) clues from phone area codes, in which 
     case we keep with a chainer rather than extending the Gazetteer.
     (I think I still prefer this solution.)  The major argument against
     this is potential loss of information.  You discounted doing this
     and I think you were right.

or

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

     It's good to do this rather than overloading Point as there will
     be different sorts of data available for different kinds of 
     locality.

I favour solution (2) and what I'd like to see is another source file or
two, say Locale.cs for Dashboard.Geo.Locale and PhoneDistricts.cs for
Dashboard.Geo.PhoneLocale and whatever you want to call the phone
district directory.  It seems cleaner to me than piling it all in on the
poor Gazetteer.

-- Edd