Subject: Re: airport codes.
To: Chris G. Demetriou <cgd@sibyte.com>
From: Andrew Brown <atatat@atatdot.net>
List: tech-userlevel
Date: 10/19/2000 02:27:07
>let's see.
>
>http://www.framed.usps.com/ncsc/lookups/lookup_ctystzip.html
>	went to usps site, and followed links.
>
>http://www.agt-gems.com/AGTbook/AGTbs/AGTbs.html
>	"gemological society birth stones"
>
>http://anewleaf.com/florist/flowermeanings.htm
>	"flower meanings florist"
>
>http://www-cse.ucsd.edu/users/bsy/area.html
>	"area code table"
>	following from there i got http://www.nanpa.com/
>
>... etc.  (things in quotes are the google searches i "got lucky" on.)
>
>btw, even suffering a rather lousy net connection and slow browser, i
>managed to collect and document those in less than 4 minutes.

funny...i find myself sitting in cafes or movie theaters (before the
lights go out) or in the backs of cars when i'm looking for these.  or
at home, but not dialed up.

>> i, for one, have always been *delighted* that those things are there.
>
>That's great.  But fundamentally, when an OS project is trying to
>track area code assignments and birth tokens, something isn't quite
>right.

um...i will concede the lack of association (if you grant the hack
value of "i found this thing and i'll stuff it here so that others can
find it easily too") but the tracking bit isn't really right.  the
birth tokens are fixed in stone (you will forgive the pun) and i can't
say that i know of any airports that have closed and been removed from
the list.  nor do i think it grows that much.

you could just as well argue that we *don't* need someone to track the
time zone changes and import them on a regular basis because no one
you know cares if cyprus/nicosia is in europe or asia.

>These types of things -- if somebody finds them desirable -- should be
>in an add-in, third-party-maintained package, in pkgsrc.

netlint?

>> it's invaluable to me to quickly look up which area code is calling
>> me, or from what city a zip code originates.  i even added lat+long
>> data to my zip codes file so that i can do rough (really, really
>> rough) estimates of driving time from point a to point b.
>> 
>> some of the other stuff is a little more esoteric, but i'd hate to
>> have to search around on the "web" for it if it wasn't installed here.
>> why throw away good data?
>
>because, especially for the ones which change (airport codes, phone
>stuff, zipcode stuff), it's outside of the scope of an operating
>system project to maintain them.

as they are, they're okay.  i'd also be willing to volunteer my time
to make sure they stayed more or less up to date, assuming that it
wouldn't take much more than an hour or so every month or so.  none of
that information changes...it only grows.  well...i *assume* it never
changes.  do airports and zipcodes disappear?

>They need to be kept up to date, and I see no reason The NetBSD
>Project -- an operating system development project -- should spend the
>effort on maintaining them.

let me do it.

>If somebody, you or other, wants to make a package out of them, and
>distribute it and maintain it, that'd be _great_.  Then it'd not only
>be usable to NetBSD users, but also to users of other systems.

freebsd has a little more than we do.  openbsd also, i think.
linux...hmm...no misc, but they do have wallpapers and some other
weird stuff.  kooky.

>But an OS development project doesn't really have any business wasting
>any resources on maintaining them.

wait...how did this start again?  oh yeah...it wasn't up to date.  how
about a pr from the complaining party?  who governs what goes in those
files anyway?  i remember the domains one being a little "wrong"...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."