|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | Re: GISList: Compressed Terrain Data |
| Date: |
01/07/2003 11:20:55 AM |
| From: |
Cameron Crum |
|
|
Dimitri,
Thanks for the response, but I think the point was missed. First, SDTS is
cumbersome and inefficient. Our compression gives a 2.3 times smaller file than
SDTS and 10 times smaller than native DEM. Second, SDTS files contain the errors
that the source files had, namely pathological sinkholes and incorrect
georeferencing which the USGS admits to. The reason we came up with the
compression is because we needed a large number of error free quads that will
tile together without gaps. Try putting several hundred or thousand quads on
your hard drive and see if the 2.3 multiplier doesn't add up quickly. You asked
why not propose an open format...simple...no money in it. I do not sit around
all day writing software to give away. As despised as he is, Bill gates is the
richest man in the world for a very simple reason. As for a standardized format,
why is the USGS standard the defacto? Because they say it is, right? It doesn't
mean that it is the best. We have Social Security, yet people still invest in
401k programs and open IRAs. GSM was the most prolifc wireless technology in the
world, but virtually all GSM providers will soon be changing over to UMTS (a
CDMA based technology). Why? Because it provides more voice capacity and high
data rates. Linux, an open source example, is free, yet people still spend money
to buy it because companies like Red Hat and others have made it easier to use.
It is the market which drives inovation and the market will decide if this
product will live or die. Our employees will definitely not survive if we start
giving away our products. As to you final point, yes we will control the
product, its licencing and distrobution. Hopefully though, we will have many
licensees who are also distributing the product. Care to be one? You might make
some money as well.
Regards,
Cameron
Dimitri Rotow wrote:
> > This is a little off topic, but I'm trying to see if there would be an
> > interest in a very compressed (not zipped) form of elevation data. We
> > have come up with a technique for compressing DEM's that brings file
> > sizes down to about 127 KB per 1:24000 scale quad. To let you know, the
> > native USGS DEM's are over 1 MB each and the STDS archiving method in my
> >
> > opinion is cumbersome to extract data from. We have also developed a DLL
> ^^^
> Perhaps you've been using cumbersome software. No reason you can't get an
> SDTS DEM by simply doing a File - Open if your application is well crafted.
>
> >
> > and API that would allow programmers to access the data in these quads
> > programatically without having to decompress them, and we would offer a
> > free translator to convert the quads into an ascii grid, x,y,z, tab,
> > mif, mig or some other common format (but not back to native DEM) for
> > those who just want the raw data and do not need it in a program.
>
> IMHO, the last thing the world needs is yet another proprietary format in
> which to store data, especially one that prevents users from converting to
> the most common format used for such data. Why not propose an open format
> using open algorithms for compression?
>
> Also, as a practical matter, any high performance application will import
> elevation data into whatever internal representation provides the highest
> performance and greatest capability for that application. May as well use
> already-existing, standardized formats for interchange.
>
> > Additionally, the compression process detects and corrects the errors
> > inherent in many of the native USGS quads. So the end product is a
>
> Hmmm,... nothing like having the storage format make changes in a
> standardized data set, no matter how sure of itself it may be.
>
> > corrected quad at 1 tenth the original file size that doesn't require
> > 3-4 steps to make it usable.
>
> In exchange, it only requires users and vendors to agree to hand over to you
> ownership of their ability to access what is now free data that is in the
> public domain. If you own the format and you control the terms and
> conditions of licensing the format you also ultimately control access to the
> data published in that format.
>
> If you provide a very "open" and inclusive SDK license like the ERMapper SDK
> for their ECW compression you might find other applications willing to use
> it. If it is as "closed" and paranoid as the MrSID SDK license you might
> find yourself laying off half of your company as they did.
>
> > Obviously, this is for the US only at the
> > moment, but the compression technique could be used on any data in the
> > world...we just don't happen to have access to that data. I'd be
> > interested to hear any questions or comments abou
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
