[OSGeo-Discuss] Open File Formats and Proprietary Algorithms
Doug_Newcomb at fws.gov
Doug_Newcomb at fws.gov
Mon Aug 24 04:49:51 PDT 2009
I regularly use the gdal tools and python to convert/reproject the NAIP
county mosaics from UTM to NC State Plane in a Quarter Quad format. It
really doesn't take that long on a 64-bit linux box with a couple of big
hard drives. Once you get things out of MrSid format, things go pretty
quickly.
Doug
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at fws.gov
---------------------------------------------------------------------------------------------------------
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of Interior.
Life is too short for undocumented, proprietary data formats.
Eric Wolf
<ebwolf at gmail.com
> To
Sent by: OSGeo Discussions
discuss-bounces at l <discuss at lists.osgeo.org>
ists.osgeo.org cc
Subject
08/20/2009 04:53 Re: [OSGeo-Discuss] Open File
PM Formats and Proprietary Algorithms
Please respond to
OSGeo Discussions
<discuss at lists.os
geo.org>
Interesting... I can understand why NAIP was in MRSID. It's a pretty large
dataset - and I think .SID was more widely supported than JP2 until
recently. The USDA site does provide links to PCI Geomatics FreeView, which
can read .SID format but not save it. IrfanView, with a plugin, can read
SID format and convert. So it's not a dead-end format. And it sure beats
SDTS!
I think data interchange and real interoperability has only recently been
possible for large raster datasets. It's still a chore if you have to
re-project large raster datasets. This may add some content to a research
paper I'm working on.
-Eric
-=--=---=----=----=---=--=-=--=---=----=---=--=-=-
Eric B. Wolf New! 720-334-7734
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography
On Thu, Aug 20, 2009 at 2:22 PM, Landon Blake <lblake at ksninc.com> wrote:
Eric,
The imagery I am talking about is from the USDA APFO:
This FAQ contains a snippet about the format:
http://www.fsa.usda.gov/FSA/apfoapp?area=home&subject=prog&topic=nai
In an interesting turn of events I note that as of 2008, the USDA is
releasing the county mosaics in JP2 format, not in MRSID. I am not sure
what brought about this change, and I wasn’t aware that it had been made.
The same web page indicates that there is a shapefile index for the
individual image tiles.
It appears that you can also download the county mosaics online.
A lot of this has changed (improved) in the last couple of years. I’m
glad I checked again. That being said, the principles from our discussion
still apply. :]
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 Eric Wolf
Sent: Thursday, August 20, 2009 1:15 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open File Formats and Proprietary Algorithms
The MRSID format is a very special case - and perhaps an opportunity for
a new FOSS file format. MRSID is a lossless, fractal-based, multi-scale
raster compression format. LizardTech has the algorithms to encode and
decode MRSID locked up in copyrights, and I believe, patents. Even
companies like ESRI shell out big bucks to LizardTech to be able to read
and write the MRSID format.
I guess I missed the context of the discussion. Is the government
releasing certain data exclusively in this format? If so, I think the
argument can be made against this practice. The different in compression
between MRSID and gziped TIFFs isn't really that great in this day of
cheap disks and fat pipes.
-Eric
-=--=---=----=----=---=--=-=--=---=----=---=--=-=-
Eric B. Wolf New! 720-334-7734
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography
On Thu, Aug 20, 2009 at 12:27 PM, Landon Blake <lblake at ksninc.com> wrote:
I realized that publishing a spec for a file format like MRSID isn’t as
clear cut as I had at first thought. If the MRSID software uses a fancy
top-secret compression/decompression algorithm to move data to and from
the file format knowing only the structure of the format would do no
good. You’d have to release the details of the algorithm as well.
I still don’t think proprietary file formats are a good idea for
government data released to the public, but I admit that having a company
like LizardTech publish a spec for something like MRSID is not
necessarily a simple task. No doubt a lot of time and money goes into
developing those algorithms.
This makes me wonder about algorithms used to purposefully encrypt binary
file formats. That is another can of worms. It looks like the easiest
thing to do is to start with a file format that was designed to be open
from the very beginning.
Landon
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
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090824/58c437e9/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090824/58c437e9/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic13966.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090824/58c437e9/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090824/58c437e9/attachment-0002.gif>
More information about the Discuss
mailing list