Re: GeoSitesBackend update
- From: Edd Dumbill <edd usefulinc com>
- To: dave <davidr sucs org>
- Cc: dashboard-hackers gnome org
- Subject: Re: GeoSitesBackend update
- Date: Fri, 27 Feb 2004 14:17:46 +0000
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
> 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.
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.
(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
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
] [Thread Prev