Why nbsp?

The development of Nbsp started in 2005, with a specific set of purposes in mind. When we announced it around March 2005 in the noaaport yahoo group, we were asked about the differences between Nbsp and Ldm. Our answer then, in a message sent to the group, is reproduced unedited below. With minor variations, it would still be our answer today.

> On Saturday 16 July 2005 18:54, Jose F. Nieves wrote:
>
> > I'm curious to the difference between nbsp and the UNIDATA ldm noaaport
> > software.
>
>
> This is how I understand it.
>
> ldm is a general purpose data capture and distribution system,
> independent of how or where the data comes from.
> For the noaaport application, you must couple it to a tool
> that gets the data from the receiver and sends it the ldm
> system for processing, following the ldm protocol.
> That combination gives you a complete noaaport receiver software.
> It is what I call gempak-centric, that is to say,
> for obvious reasons, the assumption is that you will be looking
> at the data using the gempak tools, and therefore the
> output of the whole thing is governed by the gempak tools' formats.
> For example, satellite images are not stored directly as png, gif or jpg
> files that be viewed with ordinary programs including a web browser.
> That requires further processing and/or configuration.
>
> I wanted something that was not focused on gempak, that could
> output the files in ready-to-read formats that can be viewed and
> distributed by standard tools, incorporating facilities
> for distribution by various means (email, web).  Trying to adapt
> the ldm-noaaport system to do something it was not designed for
> semed like the wrong path to follow. For example, one has to learn
> a new and rather specific language-syntax to modify the ldm
> configuration file pqact.conf. I wanted a system where the
> configuration (actually the run-control scripts) was based on a full,
> general purpose language like perl, tcl and others.
>
> So, nbsp is designed, from the ground up, with all these things in mind.
> In general, files are stored in their original form
> as they were sent. Text files (bulletins, etc) can be viewed
> with any text editor, satellite images with png/jpg/gif viewers,
> they can be sent through the network `a la emwin, by email, by
> news software, etc. No further tools are needed to produce them.
> If anyone is content with just getting the text fles and satellite
> images and putting them up in a web site, it can be done without
> installing any other external programs. Output can also be
> in a gempak format mimicking what ldm would do, so nothing is lost
> since all can be done at the same time.
>
> ldm is still slightly faster, because it skips a lot of work that it leaves
> to others. For example, the satellite images are saved as they are
> received, raw data in compressed form, and it leaves the decompression and
> decoding to the gempak tools (e.g., nmap2). nbsp on the other hand
> does the decompression and decoding itself, storing the file as a
> png/jpg file. nbsp is quite fast, and the speed difference
> is not much anyway, but it is the price for
> being able to see the output files from any computer anywhere,
> with or without gempak, not just the one where gempak is installed.
>
> Jose F Nieves