Lamar,
> I do still want to get CDBS in a PostgreSQL setup, with automatic nightly
> import, at some point in time. Just probably not as quickly as Josh needs a
> dataset to crank on.
Oh, I don't know. I expect setting this up to take several weeks. And if
we do the CDBS database as part
On Friday 04 April 2003 14:54, Merlin Moncure wrote:
> I can tell you, though; the land mobile database is much more
> complicated. Getting it to run decently on pc hardware is a significant
> engineering challenge.
Then it sounds like it's a better fit for Josh's requirements.
> ill-fated DTV r
> I'm quite familiar with RadioSoft. Can't afford any of the software;
> familiar
> with the products... :-)
>
> I've been putting together open source tools to do much of the same
stuff.
> With the release of the FCC's Fortran source, I've been able to do
> virtually
> everything I need to do.
>
On Friday 04 April 2003 14:23, Merlin Moncure wrote:
> Up until about 6 months ago, I worked at a company called RadioSoft.
> They are a provider of high quality database, engineering, and GIS
> software. The company has its roots as source of engineering tools for
> broadcast engineers. They cur
Lamar,
> Also check out the cdbs files (which contain the broadcast stuff as well as
> more) at /pub/Bureaus/Mass_Media/Databases/cdbs/ (which I would be more
> interested in doing, since I am a broadcast engineer by profession)
Hey, if you're willing to do the text --> postgres conversions
Lamar Owen wrote:
> Also check out the cdbs files (which contain the broadcast stuff as
well
> as
> more) at /pub/Bureaus/Mass_Media/Databases/cdbs/ (which I would be
more
> interested in doing, since I am a broadcast engineer by
profession)
> --
Up until about 6 months ago, I worked at a comp
On Friday 04 April 2003 11:47, Merlin Moncure wrote:
> The location of the data of interest is at
> /pub/Bureaus/Wireless/Databases/uls/.
> wireless services. This includes most two way systems and point to
> multipoint (microwave) but not broadcast (AM, FM, TV) and not advanced
> radio.
Also ch
Josh Berkus wrote:
> Cool. I'll tackle this in a week or two. Right now, I'm being paid
to
> convert a client's data and that'll keep me busy through the weekend
...
I would suggest downloading the data now. I can help get you started
with the create table statements and the import scripts. T
Merlin,
> The fcc FTP site is ftp.fcc.gov
>
> The location of the data of interest is at
> /pub/Bureaus/Wireless/Databases/uls/.
Cool. I'll tackle this in a week or two. Right now, I'm being paid to
convert a client's data and that'll keep me busy through the weekend ...
--
-Josh Berkus
A
The fcc FTP site is ftp.fcc.gov
The location of the data of interest is at
/pub/Bureaus/Wireless/Databases/uls/.
There are zip files (pipe delimited) in complete and the daily changed
files in daily. Theres lots of info in documentation which includes
excel spreadsheets of the schema. These wil
Jeff, Mlw,
> Absolutely. We could just use one large state or several small ones and
> let folks download the whole thing if they wanted. Using that technique
> you could control the size of the test quite closely and still make
> something potentially quite valuable as a contribution beyond th
On Thu, Apr 03, 2003 at 17:19:13 -0500,
mlw <[EMAIL PROTECTED]> wrote:
>
> I have a set of scripts, SQL table defs, a small C program, along with a
> set of field with files that loads it into PGSQL using the "copy from
> stdin" It works fairly well, but takes a good long time to load it all.
Bruno Wolff III wrote:
On Thu, Apr 03, 2003 at 13:26:01 -0500,
[EMAIL PROTECTED] wrote:
I don't know that it meets your criteria, but.
I have a set of scripts and a program that will load the US Census TigerUA
database into PostgreSQL. The thing is absolutely freak'n huge. I forget
whic
On Thu, Apr 03, 2003 at 13:26:01 -0500,
[EMAIL PROTECTED] wrote:
> I don't know that it meets your criteria, but.
>
> I have a set of scripts and a program that will load the US Census TigerUA
> database into PostgreSQL. The thing is absolutely freak'n huge. I forget
> which, but it is eithe
Folks,
Please pardon the cross-posting.
A small group of us on the Performance list were discussing the first steps
toward constructing a comprehensive Postgresql installation benchmarking
tool, mostly to compare different operating systems and file systemsm but
later to be used as a foundatio
Josh Berkus wrote:
> 1) At least one "main" table with 12+ columns and 100,000+ rows
(each).
> 2) At least 10-12 additional tables of assorted sizes, at least half
of
> which
> should have Foriegn Key relationships to the main table(s) or each
other.
> 3) At least one large text or varchar field am
16 matches
Mail list logo
