Subject: Re: airport codes.
To: Andrew Brown <atatat@atatdot.net>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-userlevel
Date: 10/18/2000 23:16:25
Andrew Brown <atatat@atatdot.net> writes:
> >as far as i'm concerned, the following could go: birthtoken, flowers,
> >inter.phone, na.phone, zipcodes.
> >
> >things which are only barely relevant: acrynyms, bsd-family-tree.
> 
> i always figured misc was a place for little things that didn't have a
> better home.  i guess you could make individual homes for mostof them,
> or take the non-system related ones and stuff them in something call
> /usr/share/foo?

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.


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

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


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

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.


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.

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



chris