[OSGeo-Discuss] Open File Formats

Fri Aug 21 11:42:25 PDT 2009

All, 

I agree, very good conversation, I've already pointed a few folks at it as the same topic has come up here at work on two different projects, as well as a Survey I just completed yesterday for a Federal data provider. I pointed the survey taker at this thread as well. 

bobb 

>>> "Landon Blake" <lblake at ksninc.com> wrote:

I think we were talking about the easiest way to implement saving space. :] 

I was trying to point out (and maybe Paul was also) that ease of implementation (now or in the future) should be a factor the government chooses when selection a file format/technology for data storage and distribution to the public. 

There are a number of other factors, as MPG mentioned. 

This has been a really good discussion, and I will try to get some content about open file formats on the wiki as Arnulf requested. Maybe next week? 

Landon 

Office Phone Number: (209) 946-0268 

Cell Phone Number: (209) 992-0658 

From: 

discuss-bounces at lists.osgeo.org [mailto:discuss-bounces at lists.osgeo.org] 
On Behalf Of 

Bob Basques

Sent: 

Friday, August 21, 2009 11:28 AM

To: 

OSGeo Discussions; Ivan Lucena

Subject: 

RE: [OSGeo-Discuss] OpenFile FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED] 

All, 

Can someone remind me again, are we talking about saving space, or making it easier to implement something . . .  :c) 

I personally prefer nice simple internal pyramided tiles with indexing, about 10% extra space, and very good performance. 

Someone earlier in this thread spoke about some of these technologies being somewhat obsolete what with the new network and bandwidth speeds available for publishing. 

bobb 

>>> "Lucena, Ivan" <ivan.lucena at pmldnet.com> wrote: 

But you can't compress data types other than byte in JPG. Can you do that in JP2K?

>  -------Original Message-------
>  From: Landon Blake <lblake at ksninc.com>
>  Subject: RE: [OSGeo-Discuss] Open FileFormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]
>  Sent: Aug 21 '09 12:42
> 
>  Paul,
> 
>  I was wondering the same thing.
> 
>  It seems a little like choosing to drive a Honda Accord, or a Ferrari.
>  The Ferrari is a lot faster and comes with a better looking trophy wife
>  (or husband), but the Honda is a lot easier to fix. (Try finding an
>  affordable Ferrari mechanic in Stockton, California.)
> 
>  To tie this back into our original discussion, it seems like the
>  government should be choosing to drive a Honda Accord when it can,
>  instead of the Ferrari.
> 
>  I guess you'd really have to crunch the numbers and see if the savings
>  in bandwidth/disk space costs were really worth the compression savings
>  that result from a proprietary compression scheme ("wavelet black
>  magic").
> 
>  The problem with this is a lot of the benefits that come from the Honda
>  Accord (open image format + open compression algorithm) aren't easily
>  calculated in dollars and cents.
> 
>  Still, this speaks to an important truth I have discovered in open
>  source development: Simple is better, even when it isn't necessarily
>  faster and smaller.
> 
>  I'd rather have code that I can understand, or a file format that a
>  programmer in 20 years will understand, than a Ferrari you can't drive
>  unless you have a PHD and did a thesis on wavelet compression. :]
> 
>  Landon
>  Office Phone Number: (209) 946-0268
>  Cell Phone Number: (209) 992-0658
> 
> 
> 
>  -----Original Message-----
>  From: discuss-bounces at lists.osgeo.org
>  [mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
>  Sent: Friday, August 21, 2009 10:36 AM
>  To: OSGeo Discussions
>  Subject: Re: [OSGeo-Discuss] Open File
>  FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]
> 
>  So hung up on wavelets, we are.
> 
>  Internally tiled TIFF with JPEG compression and similarly formatted
>  internal overviews can achieve 10:1 compression rates without
>  noticeable image quality reductions, and as an added bonus can be
>  decompressed a heck of a lot faster than wavelet-based formats. The
>  wavelet stuff is k00l, in that there is no need for an overview
>  pyramid (it's implicit in the compression math) and much higher
>  compression rates can be achieved. But operationally, you can go a
>  long way with the more primitive (open image format + open compression
>  algorithm) approach.
> 
>  P.
>  _______________________________________________
>  Discuss mailing list
>  Discuss at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss
> 
> 
>  Warning:
>  Information provided via electronic media is not guaranteed against defects including translation and transmission
errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this information in error, please notify the
sender immediately.
>  _______________________________________________
>  Discuss mailing list
>  Discuss at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss
> 
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss 

Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090821/d7cd0054/attachment-0002.html>