Re: [OSGeo-Discuss] Examples of Opposition to Open Source/Open File Formats in the United States

[Arnulf Christl (OSGeo)]

Landon Blake schrieb:
 It looks like I might have ruffled a few feathers with my earlier post

Landon,
please keep it up, it is advocacy at its best. As you said before, this
is the OSGeo mailing list.

Would you care to also add some of your thoughts and ideas backed up
with reference links (just link from the mailing list archives) to the
OSGeo Wiki? It provides an easy way to reference and disseminate our
activities wrt advocating Open Source Geospatial and is easily indexed
by search engines.

There is also a dedicated category in the Wiki to tag and organize pages
with explicit advocacy content. Most of the pages there are currently
focused on Open Source, Free Software and some on Business Models. Pages
related to Open Standards and Formats are still missing and would round
of the topic really well.

http://wiki.osgeo.org/wiki/Advocacy
and
http://wiki.osgeo.org/wiki/Category:Advocacy

Thanks, Arnulf.

 about the lack of support for open source software in the United States.
 I was making a generalization, and didn't mean to criticize or downplay
 the efforts of advocates and government employees that are promoting
 open source software. I hope their advocacy continues, and I will do
 what I can to support it.
 
  
 
 I thought I would take a minute to post one or two articles that
 highlight the type of opposition/attitude that I was talking about.
 
  
 
 The first one isn't directly related to geospatial software, but it is
 related to the use of open source software and open file formats by
 government agencies in the United States. It has to do with the adoption
 of ODF (the file format used by Open Office).
 
  
 
 See the section on Massachusetts in this wikipedia article:
 http://en.wikipedia.org/wiki/OpenDocument_adoption
 
 Here is an article about legislation proposed in 2006 to do the same
 thing in Minnesota:
 http://www.informationweek.com/news/software/open_source/showArticle.jht
 ml?articleID=184429732
 
  
 
 These articles are old, and there may have been updates and new legal
 decisions that I am not aware of. You could check to ODF Alliance site
 for updates:
 
  
 
 http://www.odfalliance.org/mail_list.php
 
  
 
 There is no question in my mind that Microsoft opposed the adoption of
 ODF by state governments in the United States. If you don't think this
 is true, I've got a bridge I want to sell you. :]
 
  
 
 My second example involves the Autodesk suit against the Open Design
 Alliance. You can read an article about that here:
 
 http://www.stress-free.co.nz/autodesk_sues_the_open_design_alliance
 
  
 
 Autodesk may have legitimate concerns about trademark violation, but
 I'll bet they would love to sink the Open Design Alliance ship. The
 majority of CAD data produced in the surveying/engineering arena is
 stored in the DWG format, and Autodesk knows this. Controlling that
 format and programmer's access to it is a key component of Autodesk's
 business model.
 
  
 
 It looks like the legal battle was still on as recently as July 7, 2009:
 
 http://www.opendesign.com/node/398
 
  
 
 Autodesk is certainly entitled to protect is intellectual property, but
 in my mind this is a big obstacle to data sharing among the geospatial
 communities in the US, especially as you move to the engineering/survey
 side of things.
 
  
 
 Let's not kid ourselves. There is a lot of money to be made selling
 software in the United States, and people will do their best to
 influence our legal and commercial systems to serve their own needs. One
 thing I love about open source software development is the sense of
 sharing and community. This is a definite contrast.
 
  
 
 I think OSGeo (and all of us as individual software developers) should
 be aware of this opposition to open source and open technology
 standards, and should do our best to counteract it. A lot of the general
 public doesn't understand the issues involved, or understand how
 governments funded by their tax dollars might benefit from open source
 software. We need to be the voice the people aren't going to hear from
 Autodesk or ESRI.
 
  
 
 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@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss


-- 
Arnulf Christl
OSGeo President
http://www.osgeo.org
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] Mac Pro collocation for OSGeo

[Mateusz Loskot]

Folks,

I have a pretty powerful workstation that I'd like to
connect to OSGeo infrastructure, somehow. It is: Mac Pro with
2 x Intel Xeon 2.66GHz (5150, Woodcrest, dual core)
5 GB RAM
1.5 TB HDD
If I'll manage to find a new home for my machine, I want to
extent RAM to 16 GB and get one or more TB of HDD.

I'm looking for possibility of collocation my machine
somewhere in UK (not necessarily in London), so it can be
permanently connected to OSGeo infrastructure.
Unfortunately, I am not able to connect this machine from home
and keep connected 24/7.

I would be delighted to make it available for OSGeo projects
and their development purposes like Buildbot, scheduled builds, software
testing, etc.
The only personal use of this machine I would like to be able to do
is...development and software testing of OSGeo software I work with
plus I'd like to keep some personal backups there (disks are getting
cheap, so it shouldn't be a problem to extent to tens of TB
in near future). OS X Leopard and license for Parallels VM software is
included.

When I was working in Poland, I was successfully running 3-4 systems on
that Mac (ie. unstable Debian, stable Ubuntu and 2 x Windows) to crunch
scheduled builds.

I tried to find collocation service in Poland or UK but prices like
~100 GBP/month are too high to pay for the purposes I'd like to
dedicate my machine to.

So, if anyone knows a data centre in UK that would be interested
in rescuing the wasted CPU cycles of my machine resting in the box
please let me know. I think providing collocation could be a nice
way to sponsor OSGeo by contributing some nice hardware option :-)

Currently, the machine rests in box in my flat in Poland
(I live in London, UK). If I find a place for it, I'll ship
it from PL to UK.

A few pictures of the machiewne:
http://www.flickr.com/photos/mloskot/sets/72157602734463745/

Best regards,
Mateusz

p.s. I cross-posted this message to both, discuss@lists.osgeo.org
and u...@lists.osgeo.org.
--
Mateusz Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Mac Pro collocation for OSGeo

[Mateusz Loskot]

Chris Puttick wrote:

If anyone has a use for it, we can provide space, protected power and
 a connection


I used to use this machine as a part of http://buildbot.osgeo.org farm.
It could also be used for other purposes, like live demo of
GeoServer/MapServer, nightly builds and binary packaging.

(probably in our new French office which has more spare bandwidth, 
but we can get it from here to France).


Hmm, France is quite a different location than UK, but thanks for the
offer, if I won't find anything, I could ship my machine to
France, why not ;-)


Not quite colo quality, but should be enough for while.


I'd prefer to find something for a longer while :-)
Shipping 20kg across Europe several times a year may be expansive.

We'd have to restrict bandwidth still, so depends what you think it 
would need bandwidth-wise.


Do you mean bandwidth limit or monthly transfer limit?
I'm sure 1mbps of bandwidth is enough.
Uploading/downloading data like backups can take longer
but none of these operation need to be fast for me.
Distributed building/testing is bandwidth efficient as
it does not transfer tons of MB, just a message and some reports,
plus initial checkouts and further updates from repository, of course.

By the way, you could use this machine for your own purposes in the
office, though more disk-oriented than cpu-demanding ones. For instance,
just put a disk and use it as a file server, backup server, etc.
So, the CPU time could be dedicated more to OSGeo jobs.

Anyway, Chris thank you for your offer, Although, let's see if there
would be option in UK.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Mac Pro collocation for OSGeo

[Chris Puttick]

- Mateusz Loskot mate...@loskot.net wrote:

 Chris Puttick wrote:
  If anyone has a use for it, we can provide space, protected power
 and
   a connection
 
 I used to use this machine as a part of http://buildbot.osgeo.org
 farm.
 It could also be used for other purposes, like live demo of
 GeoServer/MapServer, nightly builds and binary packaging.
 
  (probably in our new French office which has more spare bandwidth, 
  but we can get it from here to France).
 
 Hmm, France is quite a different location than UK, but thanks for the
 offer, if I won't find anything, I could ship my machine to
 France, why not ;-)

From London, Northern France is not so different to most of the UK (travel 
time, weather, etc.), except the wine is cheaper...

  Not quite colo quality, but should be enough for while.
 
 I'd prefer to find something for a longer while :-)
 Shipping 20kg across Europe several times a year may be expansive.

A while meaning 1 year, no guarantees after that.

  We'd have to restrict bandwidth still, so depends what you think it
 
  would need bandwidth-wise.
 
 Do you mean bandwidth limit or monthly transfer limit?
 I'm sure 1mbps of bandwidth is enough.
 Uploading/downloading data like backups can take longer
 but none of these operation need to be fast for me.
 Distributed building/testing is bandwidth efficient as
 it does not transfer tons of MB, just a message and some reports,
 plus initial checkouts and further updates from repository, of
 course.

Bandwidth limit of 1mbps would be no problem (said office has a 10 mbps fibre).
 
 By the way, you could use this machine for your own purposes in the
 office, though more disk-oriented than cpu-demanding ones. For
 instance,
 just put a disk and use it as a file server, backup server, etc.
 So, the CPU time could be dedicated more to OSGeo jobs.

All that sort of thing we try to do in the Oxford office - but because of that 
I'm not sure we can justify sparing bandwidth from there, plus major physical 
space constraints in the server room.
 
 Anyway, Chris thank you for your offer, Although, let's see if there
 would be option in UK.

No problem.

Chris


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Open File Formats and Proprietary Algorithms[SEC=UNCLASSIFIED]

[Considine, Michael]

All,

Opticks is an open source remote sensing application and development
framework. We recently started the process to add JPEG 2000 support to
our framework. We picked OpenJpeg to add JPEG 2000 support to our
application. They are also open source. We currently support importing
JPEG 2000 files but we are currently limited to the 4GB memory size
after decoding.

Our plan is to continue development and to upgrade to OpenJpeg 2.0 once
they have a stable release. That will allow Opticks to use a pager to
display and support much larger files.

Michael Considine

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Bruce Bannerman
Sent: Thursday, August 20, 2009 8:15 PM
To: 'OSGeo Discussions'
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms[SEC=UNCLASSIFIED]


IMO:


Just another thought on this issue (though we do seem to be recycling
arguments over the years...):


Assuming that I have a very large archive of spatial data, be it imagery
or any other spatial format and that I store my data in a variety of
proprietary formats:


In ten years from now, can I be sure that:

- the company that created, understands, and holds the IP in the 
  data format will still be around?

- there will still be software that runs on the then current
  operating environment, that can read and 'fully exploit' the data
  in the proprietary standard?

- that this future software will work seamlessly with my then current 
  spatial environment?

- if all of the above risks prove to eventuate, can I be sure that I'll
  be able to salvage my data into another format, retaining its complete

  semantic context?


IMO, it is a high risk proposition to lock public (or private) archives
away in proprietary data formats. It makes more sense to use open
standards and formats that are publically available.



Bruce Bannerman



 

 -Original Message-
 From: discuss-boun...@lists.osgeo.org 
 [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael 
 P. Gerlek
 Sent: Friday, 21 August 2009 6:55 AM
 To: OSGeo Discussions
 Subject: RE: [OSGeo-Discuss] Open File Formats and 
 Proprietary Algorithms
 
 Some clarifications:
 
  
 
 - MrSID has both lossy and lossless modes
 
 - MrSID is not fractal based; it uses wavelets (and 
 arithmetic encoding)
 
 - you can't copyright algorithms; the MrSID source code 
 certainly is, however
 
 - MrSID relies on a number of patents, not all of which are 
 owned by LizardTech
 
 - reading MrSID does not require any fees; we have libraries 
 you can download, although they are not open source
 
  
 
 That said, some editorial comments (although I'm now wishing 
 I hadn't been so quick to rise to Landon's bait :-)
 
  
 
 - Some of you know the history of trying to open source 
 MrSID; I won't go into that here, except to say that 
 LizardTech doesn't own all of the required IP needed to make 
 that happen.
 
 - If we are speaking of the NAIP data, then no, it is not 
 exclusively available in MrSID format; it is also shipped as GeoTIFFs.
 
 - JPEG 2000 is a very robust open standard alternative to 
 MrSID, and a number of players already support it (including 
 LizardTech), but not enough to make it viable for certain 
 domains like NAIP.
 
 - some of you also know the history on open JP2 support: 
 there is today no open source implementation of JP2 that is 
 suitable for geo work.  Alas.
 
  
 
 -mpg
 
  
 
  
 
 From: discuss-boun...@lists.osgeo.org 
 [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Eric Wolf
 Sent: Thursday, August 20, 2009 2: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. WolfNew! 720-334-7734
 USGS Geographer
 Center of Excellence in GIScience
 PhD Student
 CU-Boulder - Geography
 
 
 
 
  
 
 ___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended 

RE: [OSGeo-Discuss] Open File Formats and ProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Landon Blake]

Thanks for the information Michael. I am downloading Opticks right now.
:]

I also found this Java library for JP2, thought I'm not sure how
complete/up-to-date it is:

http://jj2000.epfl.ch/

Maybe we need a JPEG 2000 page on the OSGeo wiki.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Considine, Michael
Sent: Friday, August 21, 2009 8:09 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and
ProprietaryAlgorithms[SEC=UNCLASSIFIED]

All,

Opticks is an open source remote sensing application and development
framework. We recently started the process to add JPEG 2000 support to
our framework. We picked OpenJpeg to add JPEG 2000 support to our
application. They are also open source. We currently support importing
JPEG 2000 files but we are currently limited to the 4GB memory size
after decoding.

Our plan is to continue development and to upgrade to OpenJpeg 2.0 once
they have a stable release. That will allow Opticks to use a pager to
display and support much larger files.

Michael Considine

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Bruce Bannerman
Sent: Thursday, August 20, 2009 8:15 PM
To: 'OSGeo Discussions'
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms[SEC=UNCLASSIFIED]


IMO:


Just another thought on this issue (though we do seem to be recycling
arguments over the years...):


Assuming that I have a very large archive of spatial data, be it imagery
or any other spatial format and that I store my data in a variety of
proprietary formats:


In ten years from now, can I be sure that:

- the company that created, understands, and holds the IP in the 
  data format will still be around?

- there will still be software that runs on the then current
  operating environment, that can read and 'fully exploit' the data
  in the proprietary standard?

- that this future software will work seamlessly with my then current 
  spatial environment?

- if all of the above risks prove to eventuate, can I be sure that I'll
  be able to salvage my data into another format, retaining its complete

  semantic context?


IMO, it is a high risk proposition to lock public (or private) archives
away in proprietary data formats. It makes more sense to use open
standards and formats that are publically available.



Bruce Bannerman



 

 -Original Message-
 From: discuss-boun...@lists.osgeo.org 
 [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael 
 P. Gerlek
 Sent: Friday, 21 August 2009 6:55 AM
 To: OSGeo Discussions
 Subject: RE: [OSGeo-Discuss] Open File Formats and 
 Proprietary Algorithms
 
 Some clarifications:
 
  
 
 - MrSID has both lossy and lossless modes
 
 - MrSID is not fractal based; it uses wavelets (and 
 arithmetic encoding)
 
 - you can't copyright algorithms; the MrSID source code 
 certainly is, however
 
 - MrSID relies on a number of patents, not all of which are 
 owned by LizardTech
 
 - reading MrSID does not require any fees; we have libraries 
 you can download, although they are not open source
 
  
 
 That said, some editorial comments (although I'm now wishing 
 I hadn't been so quick to rise to Landon's bait :-)
 
  
 
 - Some of you know the history of trying to open source 
 MrSID; I won't go into that here, except to say that 
 LizardTech doesn't own all of the required IP needed to make 
 that happen.
 
 - If we are speaking of the NAIP data, then no, it is not 
 exclusively available in MrSID format; it is also shipped as GeoTIFFs.
 
 - JPEG 2000 is a very robust open standard alternative to 
 MrSID, and a number of players already support it (including 
 LizardTech), but not enough to make it viable for certain 
 domains like NAIP.
 
 - some of you also know the history on open JP2 support: 
 there is today no open source implementation of JP2 that is 
 suitable for geo work.  Alas.
 
  
 
 -mpg
 
  
 
  
 
 From: discuss-boun...@lists.osgeo.org 
 [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Eric Wolf
 Sent: Thursday, August 20, 2009 2: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 

Re: [OSGeo-Discuss] Open File Formats and ProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Chris Puttick]

Well, according to this page: http://jpeg2000.epfl.ch/ v.5.1, courtesy in part 
Eastman Kodak, provides complete JP2 support at the decoding side - not sure 
whether that covers the tiling or other geo needs, but doesn't it sound worth 
investigating?

Chris


- Christopher Schmidt crschm...@crschmidt.net wrote:

 On Fri, Aug 21, 2009 at 08:27:13AM -0700, Landon Blake wrote:
  Thanks for the information Michael. I am downloading Opticks right
 now.
  :]
  
  I also found this Java library for JP2, thought I'm not sure how
  complete/up-to-date it is:
  
  http://jj2000.epfl.ch/
  
  Maybe we need a JPEG 2000 page on the OSGeo wiki.
 
 Note that JPEG 2000 support is different from JPEG 2000 support
 which
 works on geo-sized images. The tiling (or 'paging'? as Michael calls
 it) support that's supposed to be provided by OpenJPEG2000 has been
 coming 'real soon now' for about 18 months now from my uneducated
 observations, and until it's there, most tools using OpenJPEG for JP2s
 are
 going to suffering under much the same limitations.
 
 -- Chris
 
  Landon
  Office Phone Number: (209) 946-0268
  Cell Phone Number: (209) 992-0658
   
   
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Considine,
 Michael
  Sent: Friday, August 21, 2009 8:09 AM
  To: OSGeo Discussions
  Subject: RE: [OSGeo-Discuss] Open File Formats and
  ProprietaryAlgorithms[SEC=UNCLASSIFIED]
  
  All,
  
  Opticks is an open source remote sensing application and
 development
  framework. We recently started the process to add JPEG 2000 support
 to
  our framework. We picked OpenJpeg to add JPEG 2000 support to our
  application. They are also open source. We currently support
 importing
  JPEG 2000 files but we are currently limited to the 4GB memory size
  after decoding.
  
  Our plan is to continue development and to upgrade to OpenJpeg 2.0
 once
  they have a stable release. That will allow Opticks to use a pager
 to
  display and support much larger files.
  
  Michael Considine
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Bruce
 Bannerman
  Sent: Thursday, August 20, 2009 8:15 PM
  To: 'OSGeo Discussions'
  Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
  Algorithms[SEC=UNCLASSIFIED]
  
  
  IMO:
  
  
  Just another thought on this issue (though we do seem to be
 recycling
  arguments over the years...):
  
  
  Assuming that I have a very large archive of spatial data, be it
 imagery
  or any other spatial format and that I store my data in a variety
 of
  proprietary formats:
  
  
  In ten years from now, can I be sure that:
  
  - the company that created, understands, and holds the IP in the 
data format will still be around?
  
  - there will still be software that runs on the then current
operating environment, that can read and 'fully exploit' the data
in the proprietary standard?
  
  - that this future software will work seamlessly with my then
 current 
spatial environment?
  
  - if all of the above risks prove to eventuate, can I be sure that
 I'll
be able to salvage my data into another format, retaining its
 complete
  
semantic context?
  
  
  IMO, it is a high risk proposition to lock public (or private)
 archives
  away in proprietary data formats. It makes more sense to use open
  standards and formats that are publically available.
  
  
  
  Bruce Bannerman
  
  
  
   
  
   -Original Message-
   From: discuss-boun...@lists.osgeo.org 
   [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael 
   P. Gerlek
   Sent: Friday, 21 August 2009 6:55 AM
   To: OSGeo Discussions
   Subject: RE: [OSGeo-Discuss] Open File Formats and 
   Proprietary Algorithms
   
   Some clarifications:
   

   
   - MrSID has both lossy and lossless modes
   
   - MrSID is not fractal based; it uses wavelets (and 
   arithmetic encoding)
   
   - you can't copyright algorithms; the MrSID source code 
   certainly is, however
   
   - MrSID relies on a number of patents, not all of which are 
   owned by LizardTech
   
   - reading MrSID does not require any fees; we have libraries 
   you can download, although they are not open source
   

   
   That said, some editorial comments (although I'm now wishing 
   I hadn't been so quick to rise to Landon's bait :-)
   

   
   - Some of you know the history of trying to open source 
   MrSID; I won't go into that here, except to say that 
   LizardTech doesn't own all of the required IP needed to make 
   that happen.
   
   - If we are speaking of the NAIP data, then no, it is not 
   exclusively available in MrSID format; it is also shipped as
 GeoTIFFs.
   
   - JPEG 2000 is a very robust open standard alternative to 
   MrSID, and a number of players already support it (including 
   LizardTech), but not enough to make it viable for certain 
   domains 

RE: [OSGeo-Discuss] Open File Formats and ProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Michael P. Gerlek]

Tiling essentially means you can take a large file and compress pieces of it 
independently.  This avoids having to deal with the large memory footprint 
issues, but it can also lead to seam-line artifacts under certain conditions.  
Ideally, one would prefer to have the option of compressing large images 
without resorting to using tiles.

Note too that, in addition to the large image issue, many of the JP2 
implementations out there are either not fully compliant or are not tuned for 
performance.  A viable solution would need both of these.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Chris Puttick
Sent: Friday, August 21, 2009 9:37 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open File Formats and 
ProprietaryAlgorithms[SEC=UNCLASSIFIED]

Well, according to this page: http://jpeg2000.epfl.ch/ v.5.1, courtesy in part 
Eastman Kodak, provides complete JP2 support at the decoding side - not sure 
whether that covers the tiling or other geo needs, but doesn't it sound worth 
investigating?

Chris


- Christopher Schmidt crschm...@crschmidt.net wrote:

 On Fri, Aug 21, 2009 at 08:27:13AM -0700, Landon Blake wrote:
  Thanks for the information Michael. I am downloading Opticks right
 now.
  :]
  
  I also found this Java library for JP2, thought I'm not sure how
  complete/up-to-date it is:
  
  http://jj2000.epfl.ch/
  
  Maybe we need a JPEG 2000 page on the OSGeo wiki.
 
 Note that JPEG 2000 support is different from JPEG 2000 support
 which
 works on geo-sized images. The tiling (or 'paging'? as Michael calls
 it) support that's supposed to be provided by OpenJPEG2000 has been
 coming 'real soon now' for about 18 months now from my uneducated
 observations, and until it's there, most tools using OpenJPEG for JP2s
 are
 going to suffering under much the same limitations.
 
 -- Chris
 
  Landon
  Office Phone Number: (209) 946-0268
  Cell Phone Number: (209) 992-0658
   
   
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Considine,
 Michael
  Sent: Friday, August 21, 2009 8:09 AM
  To: OSGeo Discussions
  Subject: RE: [OSGeo-Discuss] Open File Formats and
  ProprietaryAlgorithms[SEC=UNCLASSIFIED]
  
  All,
  
  Opticks is an open source remote sensing application and
 development
  framework. We recently started the process to add JPEG 2000 support
 to
  our framework. We picked OpenJpeg to add JPEG 2000 support to our
  application. They are also open source. We currently support
 importing
  JPEG 2000 files but we are currently limited to the 4GB memory size
  after decoding.
  
  Our plan is to continue development and to upgrade to OpenJpeg 2.0
 once
  they have a stable release. That will allow Opticks to use a pager
 to
  display and support much larger files.
  
  Michael Considine
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Bruce
 Bannerman
  Sent: Thursday, August 20, 2009 8:15 PM
  To: 'OSGeo Discussions'
  Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
  Algorithms[SEC=UNCLASSIFIED]
  
  
  IMO:
  
  
  Just another thought on this issue (though we do seem to be
 recycling
  arguments over the years...):
  
  
  Assuming that I have a very large archive of spatial data, be it
 imagery
  or any other spatial format and that I store my data in a variety
 of
  proprietary formats:
  
  
  In ten years from now, can I be sure that:
  
  - the company that created, understands, and holds the IP in the 
data format will still be around?
  
  - there will still be software that runs on the then current
operating environment, that can read and 'fully exploit' the data
in the proprietary standard?
  
  - that this future software will work seamlessly with my then
 current 
spatial environment?
  
  - if all of the above risks prove to eventuate, can I be sure that
 I'll
be able to salvage my data into another format, retaining its
 complete
  
semantic context?
  
  
  IMO, it is a high risk proposition to lock public (or private)
 archives
  away in proprietary data formats. It makes more sense to use open
  standards and formats that are publically available.
  
  
  
  Bruce Bannerman
  
  
  
   
  
   -Original Message-
   From: discuss-boun...@lists.osgeo.org 
   [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael 
   P. Gerlek
   Sent: Friday, 21 August 2009 6:55 AM
   To: OSGeo Discussions
   Subject: RE: [OSGeo-Discuss] Open File Formats and 
   Proprietary Algorithms
   
   Some clarifications:
   

   
   - MrSID has both lossy and lossless modes
   
   - MrSID is not fractal based; it uses wavelets (and 
   arithmetic encoding)
   
   - you can't copyright algorithms; the MrSID source code 
   certainly is, however
   
   - MrSID relies on a number of patents, not all of 

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Landon Blake]

MPG wrote: Tiling essentially means you can take a large file and
compress pieces of it independently.  This avoids having to deal with
the large memory footprint issues, but it can also lead to seam-line
artifacts under certain conditions.  Ideally, one would prefer to have
the option of compressing large images without resorting to using
tiles.

This is probably a stupid question, since I know absolutely nothing
about image compression, but couldn't you overlap the tiles slightly to
avoid the seam lines?

This would obviously result in a slightly larger file size because some
pixels would be compressed twice. But that might be OK if you were
trying to compress a huge image.

What about reading chunks of the image off disk, instead of trying to
put the whole image in memory? This would be slower, but might make an
impossible task possible.

We run into this problem with vector datasets to. Some datasets are just
to stinking BIG. One of my tasks for OpenJUMP is to write a core module
that displays vector data accessed directly from disk, instead of from
memory. This will be slower, but it is better than crashing the program
because there isn't enough RAM.

Things must be more complicated than can be described in an e-mail,
because we've got people a lot smarter than me working on these
problems. I am just curious. (I tried reading about wavelet compression
on Wikipedia yesterday and quickly got a headache.) :]

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Friday, August 21, 2009 9:36 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats
andProprietaryAlgorithms[SEC=UNCLASSIFIED]

Tiling essentially means you can take a large file and compress pieces
of it independently.  This avoids having to deal with the large memory
footprint issues, but it can also lead to seam-line artifacts under
certain conditions.  Ideally, one would prefer to have the option of
compressing large images without resorting to using tiles.

Note too that, in addition to the large image issue, many of the JP2
implementations out there are either not fully compliant or are not
tuned for performance.  A viable solution would need both of these.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Chris Puttick
Sent: Friday, August 21, 2009 9:37 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open File Formats and
ProprietaryAlgorithms[SEC=UNCLASSIFIED]

Well, according to this page: http://jpeg2000.epfl.ch/ v.5.1, courtesy
in part Eastman Kodak, provides complete JP2 support at the decoding
side - not sure whether that covers the tiling or other geo needs, but
doesn't it sound worth investigating?

Chris


- Christopher Schmidt crschm...@crschmidt.net wrote:

 On Fri, Aug 21, 2009 at 08:27:13AM -0700, Landon Blake wrote:
  Thanks for the information Michael. I am downloading Opticks right
 now.
  :]
  
  I also found this Java library for JP2, thought I'm not sure how
  complete/up-to-date it is:
  
  http://jj2000.epfl.ch/
  
  Maybe we need a JPEG 2000 page on the OSGeo wiki.
 
 Note that JPEG 2000 support is different from JPEG 2000 support
 which
 works on geo-sized images. The tiling (or 'paging'? as Michael calls
 it) support that's supposed to be provided by OpenJPEG2000 has been
 coming 'real soon now' for about 18 months now from my uneducated
 observations, and until it's there, most tools using OpenJPEG for JP2s
 are
 going to suffering under much the same limitations.
 
 -- Chris
 
  Landon
  Office Phone Number: (209) 946-0268
  Cell Phone Number: (209) 992-0658
   
   
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Considine,
 Michael
  Sent: Friday, August 21, 2009 8:09 AM
  To: OSGeo Discussions
  Subject: RE: [OSGeo-Discuss] Open File Formats and
  ProprietaryAlgorithms[SEC=UNCLASSIFIED]
  
  All,
  
  Opticks is an open source remote sensing application and
 development
  framework. We recently started the process to add JPEG 2000 support
 to
  our framework. We picked OpenJpeg to add JPEG 2000 support to our
  application. They are also open source. We currently support
 importing
  JPEG 2000 files but we are currently limited to the 4GB memory size
  after decoding.
  
  Our plan is to continue development and to upgrade to OpenJpeg 2.0
 once
  they have a stable release. That will allow Opticks to use a pager
 to
  display and support much larger files.
  
  Michael Considine
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Bruce
 Bannerman
  Sent: Thursday, August 20, 2009 8:15 PM
  To: 'OSGeo Discussions'
  Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
  

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Michael P. Gerlek]

Not a stupid question -- but it doesn't work that way.  The artifacts are due 
to the wavelet processing of the pixels near the tile boundaries, and the 
boundaries have to be treated reflectively within their individual tiles (in 
order to keep each tile separate), which means you can sometimes see where 
those boundaries are.  Overlapping doesn't help because the wavelet footprint 
spans a large width, in order to handle the lower-resolution scales.  Which in 
turn means you need to be able reach far away parts of the image at various 
(some might say arbitrary) stages in the wavelet pipeline.
 
Just trust me, it is a nontrivial problem to solve.  Brighter minds than ours 
have spent a lot of energy on this problem -- a literature search would reveal 
a number of PhD theses and patents.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Landon Blake
Sent: Friday, August 21, 2009 10:45 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats 
andProprietaryAlgorithms[SEC=UNCLASSIFIED]

MPG wrote: Tiling essentially means you can take a large file and
compress pieces of it independently.  This avoids having to deal with
the large memory footprint issues, but it can also lead to seam-line
artifacts under certain conditions.  Ideally, one would prefer to have
the option of compressing large images without resorting to using
tiles.

This is probably a stupid question, since I know absolutely nothing
about image compression, but couldn't you overlap the tiles slightly to
avoid the seam lines?

This would obviously result in a slightly larger file size because some
pixels would be compressed twice. But that might be OK if you were
trying to compress a huge image.

What about reading chunks of the image off disk, instead of trying to
put the whole image in memory? This would be slower, but might make an
impossible task possible.

We run into this problem with vector datasets to. Some datasets are just
to stinking BIG. One of my tasks for OpenJUMP is to write a core module
that displays vector data accessed directly from disk, instead of from
memory. This will be slower, but it is better than crashing the program
because there isn't enough RAM.

Things must be more complicated than can be described in an e-mail,
because we've got people a lot smarter than me working on these
problems. I am just curious. (I tried reading about wavelet compression
on Wikipedia yesterday and quickly got a headache.) :]

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Friday, August 21, 2009 9:36 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats
andProprietaryAlgorithms[SEC=UNCLASSIFIED]

Tiling essentially means you can take a large file and compress pieces
of it independently.  This avoids having to deal with the large memory
footprint issues, but it can also lead to seam-line artifacts under
certain conditions.  Ideally, one would prefer to have the option of
compressing large images without resorting to using tiles.

Note too that, in addition to the large image issue, many of the JP2
implementations out there are either not fully compliant or are not
tuned for performance.  A viable solution would need both of these.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Chris Puttick
Sent: Friday, August 21, 2009 9:37 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open File Formats and
ProprietaryAlgorithms[SEC=UNCLASSIFIED]

Well, according to this page: http://jpeg2000.epfl.ch/ v.5.1, courtesy
in part Eastman Kodak, provides complete JP2 support at the decoding
side - not sure whether that covers the tiling or other geo needs, but
doesn't it sound worth investigating?

Chris


- Christopher Schmidt crschm...@crschmidt.net wrote:

 On Fri, Aug 21, 2009 at 08:27:13AM -0700, Landon Blake wrote:
  Thanks for the information Michael. I am downloading Opticks right
 now.
  :]
  
  I also found this Java library for JP2, thought I'm not sure how
  complete/up-to-date it is:
  
  http://jj2000.epfl.ch/
  
  Maybe we need a JPEG 2000 page on the OSGeo wiki.
 
 Note that JPEG 2000 support is different from JPEG 2000 support
 which
 works on geo-sized images. The tiling (or 'paging'? as Michael calls
 it) support that's supposed to be provided by OpenJPEG2000 has been
 coming 'real soon now' for about 18 months now from my uneducated
 observations, and until it's there, most tools using OpenJPEG for JP2s
 are
 going to suffering under much the same limitations.
 
 -- Chris
 
  Landon
  Office Phone Number: (209) 946-0268
  Cell Phone Number: (209) 992-0658
   
   
  
  -Original Message-
  From: discuss-boun...@lists.osgeo.org
  

RE: [OSGeo-Discuss] Open File FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Landon Blake]

Wow. Whoddu thunk we'd spend so much time and energy trying to make big
pictures smaller.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Friday, August 21, 2009 9:55 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File
FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

Not a stupid question -- but it doesn't work that way.  The artifacts
are due to the wavelet processing of the pixels near the tile
boundaries, and the boundaries have to be treated reflectively within
their individual tiles (in order to keep each tile separate), which
means you can sometimes see where those boundaries are.  Overlapping
doesn't help because the wavelet footprint spans a large width, in order
to handle the lower-resolution scales.  Which in turn means you need to
be able reach far away parts of the image at various (some might say
arbitrary) stages in the wavelet pipeline.
 
Just trust me, it is a nontrivial problem to solve.  Brighter minds than
ours have spent a lot of energy on this problem -- a literature search
would reveal a number of PhD theses and patents.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Landon Blake
Sent: Friday, August 21, 2009 10:45 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats
andProprietaryAlgorithms[SEC=UNCLASSIFIED]

MPG wrote: Tiling essentially means you can take a large file and
compress pieces of it independently.  This avoids having to deal with
the large memory footprint issues, but it can also lead to seam-line
artifacts under certain conditions.  Ideally, one would prefer to have
the option of compressing large images without resorting to using
tiles.

This is probably a stupid question, since I know absolutely nothing
about image compression, but couldn't you overlap the tiles slightly to
avoid the seam lines?

This would obviously result in a slightly larger file size because some
pixels would be compressed twice. But that might be OK if you were
trying to compress a huge image.

What about reading chunks of the image off disk, instead of trying to
put the whole image in memory? This would be slower, but might make an
impossible task possible.

We run into this problem with vector datasets to. Some datasets are just
to stinking BIG. One of my tasks for OpenJUMP is to write a core module
that displays vector data accessed directly from disk, instead of from
memory. This will be slower, but it is better than crashing the program
because there isn't enough RAM.

Things must be more complicated than can be described in an e-mail,
because we've got people a lot smarter than me working on these
problems. I am just curious. (I tried reading about wavelet compression
on Wikipedia yesterday and quickly got a headache.) :]

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Friday, August 21, 2009 9:36 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats
andProprietaryAlgorithms[SEC=UNCLASSIFIED]

Tiling essentially means you can take a large file and compress pieces
of it independently.  This avoids having to deal with the large memory
footprint issues, but it can also lead to seam-line artifacts under
certain conditions.  Ideally, one would prefer to have the option of
compressing large images without resorting to using tiles.

Note too that, in addition to the large image issue, many of the JP2
implementations out there are either not fully compliant or are not
tuned for performance.  A viable solution would need both of these.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Chris Puttick
Sent: Friday, August 21, 2009 9:37 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open File Formats and
ProprietaryAlgorithms[SEC=UNCLASSIFIED]

Well, according to this page: http://jpeg2000.epfl.ch/ v.5.1, courtesy
in part Eastman Kodak, provides complete JP2 support at the decoding
side - not sure whether that covers the tiling or other geo needs, but
doesn't it sound worth investigating?

Chris


- Christopher Schmidt crschm...@crschmidt.net wrote:

 On Fri, Aug 21, 2009 at 08:27:13AM -0700, Landon Blake wrote:
  Thanks for the information Michael. I am downloading Opticks right
 now.
  :]
  
  I also found this Java library for JP2, thought I'm not sure how
  complete/up-to-date it is:
  
  http://jj2000.epfl.ch/
  
  Maybe we need a JPEG 2000 page on the OSGeo wiki.
 
 Note that JPEG 2000 support is different from JPEG 2000 support
 which
 works on geo-sized images. The tiling (or 'paging'? as Michael calls
 it) support that's supposed 

Re: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Christopher Schmidt]

On Fri, Aug 21, 2009 at 09:45:04AM -0700, Landon Blake wrote:
 MPG wrote: Tiling essentially means you can take a large file and
 compress pieces of it independently.  This avoids having to deal with
 the large memory footprint issues, but it can also lead to seam-line
 artifacts under certain conditions.  Ideally, one would prefer to have
 the option of compressing large images without resorting to using
 tiles.
 
 This is probably a stupid question, since I know absolutely nothing
 about image compression, but couldn't you overlap the tiles slightly to
 avoid the seam lines?
 
 This would obviously result in a slightly larger file size because some
 pixels would be compressed twice. But that might be OK if you were
 trying to compress a huge image.
 
 What about reading chunks of the image off disk, instead of trying to
 put the whole image in memory? This would be slower, but might make an
 impossible task possible.

Reading chunks of image off disk == tiling. With compression, bits
aren't stored on th disk in a way that you can say Okay, bytes 0-32768
are the first 720 pixels in any way. Instead, you have to decompress
the image, or part of it, to start to learn these things. Tiling lets
you split the image up into many little chunks, which you can read
individually.

 We run into this problem with vector datasets to. Some datasets are just
 to stinking BIG. One of my tasks for OpenJUMP is to write a core module
 that displays vector data accessed directly from disk, instead of from
 memory. This will be slower, but it is better than crashing the program
 because there isn't enough RAM.

Most Vector datasets have some lvel of random access -- I can look for
feature 7, and get it, because i know where the start and end of feature
7 are. I don't know where the start and end of pixel 7 is -- because
its' different depending on exactly how wth file is compressed.

This is all a vast simplification, and some of it is probably
not-entirely right, but the problems are -- as you suggested -- more
complex than most people not working in imagery know. (And even more
complex than some of them know, most likely :))

Regards,
-- 
Christopher Schmidt
Web Developer
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Paul Ramsey]

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] Open File Formats

[Landon Blake]

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-boun...@lists.osgeo.org
[mailto:discuss-boun...@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.luc...@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 lbl...@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-boun...@lists.osgeo.org
  [mailto:discuss-boun...@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@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@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/discuss
 
___
Discuss mailing list
Discuss@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 

Re: [OSGeo-Discuss] Open File Formats

[Bob Basques]

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 lbl...@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-boun...@lists.osgeo.org [mailto:discuss-boun...@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.luc...@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 lbl...@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-boun...@lists.osgeo.org
  [mailto:discuss-boun...@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@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@lists.osgeo.org
  

RE: [OSGeo-Discuss] Open File FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Lucena, Ivan]

Bob,

Sorry to mess with discussion but if someone is suggesting the use of Geotiff 
with JPEG compressed as a Open File Format (copied and pasted from the thread 
title) I would like to remember myself and the audience obout the data type 
limitations. 

There's more in raster data than meet the eye, and that usually doesn't come in 
unsigned integer 8  bits. :)

Regards,

Ivan

  ---Original Message---
  From: Bob Basques bob.basq...@ci.stpaul.mn.us
  Subject: RE: [OSGeo-Discuss] OpenFile
 FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]
  Sent: Aug 21 '09 13:27
  
  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.luc...@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 lbl...@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-boun...@lists.osgeo.org
    [mailto:discuss-boun...@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@lists.osgeo.org
    [LINK: http://lists.osgeo.org/mailman/listinfo/discuss]
  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@lists.osgeo.org
    [LINK: http://lists.osgeo.org/mailman/listinfo/discuss]
  http://lists.osgeo.org/mailman/listinfo/discuss
   
  ___
  Discuss mailing list
  Discuss@lists.osgeo.org
  [LINK: http://lists.osgeo.org/mailman/listinfo/discuss]
  http://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org

[OSGeo-Discuss] Open Source Lurkers

[Landon Blake]

I would like to get some comments on a phenomenon I have discovered
among the OpenJUMP community. I know for sure of one (1) company that
maintains a separate fork of OpenJUMP, but which monitors our mailing
list and likely grabs patches form our source code repository. They
never participate in the forums or make known their use of OpenJUMP in
any other public manner.

 

I think there is at least one other company that does this.

 

I only learn of these companies when I am contacted by private e-mail to
work for them on OpenJUMP development, usually by some headhunter. I
actually did a little work for one of these companies (which was not a
great experience, but that is another story) and I was surprised at how
important OpenJUMP was to their operation. They even distributed it to
their customers.

 

I couldn't for the life of me figure out why this company wouldn't take
a more active role in supporting the OpenJUMP community. I'm not
necessarily talking about money here, but about writing documentation,
contributing their own patches, or answering questions on the mailing
lists. Our community is very informal and open, and an organization
could likely have a large influence on the direction the program took
with an investment of some resources.

 

Is OpenJUMP the only community with these open source lurkers? How many
of these companies do you think there are? (I'm not talking about one
guy who downloads an open source app and uses it. I'm talking about
actual companies with more than one employee.)

 

Why don't they get more involved? Are they embarrassed? Do they not want
their competition to find out about the open source program they are
benefiting from? Are they violating the terms of the license and don't
want to get busted? Do they not understand that their involvement is a
key part of the program's survival?

 

This has become an important question for me recently as the active
development of OpenJUMP has slowed. We don't have any organizations
actively participating in development. (Well, maybe one or two, but they
have been quiet lately.) I'm the only one working on serious
improvements or changes, and not just bug fixes. I would really like to
reach out to these lurkers to get them more involved. Ultimately, the
survival of the project may depend on it.

 

What do you think? Send an e-mail to the project list with an invitation
to contact me privately about getting more involved? Are these lurkers
worth the time?

 

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Open File FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Michael P. Gerlek]

 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.

I think the comment was that by hiding the data behind a server, you can reduce 
the users' exposure to a myriad of file formats, some possibly proprietary.  
It's a good point.

You still need to store the data on the servers, though, so the technologies 
themselves are by no means obsolete -- it's just a question of who has to deal 
with them.

-mpg





From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Bob Basques
Sent: Friday, August 21, 2009 12:28 PM
To: OSGeo Discussions; Ivan Lucena
Subject: RE: [OSGeo-Discuss] Open File 
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.luc...@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 lbl...@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-boun...@lists.osgeo.org
  [mailto:discuss-boun...@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
  disc...@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
  disc...@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/discuss
 
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Open File FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Landon Blake]

Ivan,

Ignoring the danger that this thread will devolve into a discussion about 
different raster formats, I will ask you for some specifics.

What are the limitations of Geotiff/JPEG compared with the proprietary 
alternatives?

Maybe we need to cook up a Guide To Raster Data File Formats for Storage and 
Distribution of Public Data. :]

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Lucena, Ivan
Sent: Friday, August 21, 2009 11:54 AM
To: Bob Basques; OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File 
FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

Bob,

Sorry to mess with discussion but if someone is suggesting the use of Geotiff 
with JPEG compressed as a Open File Format (copied and pasted from the thread 
title) I would like to remember myself and the audience obout the data type 
limitations. 

There's more in raster data than meet the eye, and that usually doesn't come in 
unsigned integer 8  bits. :)

Regards,

Ivan

  ---Original Message---
  From: Bob Basques bob.basq...@ci.stpaul.mn.us
  Subject: RE: [OSGeo-Discuss] OpenFile
 FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]
  Sent: Aug 21 '09 13:27
  
  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.luc...@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 lbl...@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-boun...@lists.osgeo.org
[mailto:discuss-boun...@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@lists.osgeo.org
[LINK: http://lists.osgeo.org/mailman/listinfo/discuss]
  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 

RE: [OSGeo-Discuss] Open File FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

[Michael P. Gerlek]

Yes, JP2 supports signed and unsigned types of up to ~24 bits.  And lots of 
channels (bands).  And alpha masking.  And arbitrary metadata blobs (geospatial 
and otherwise).

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Lucena, Ivan
Sent: Friday, August 21, 2009 12:22 PM
To: OSGeo Discussions; OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File 
FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]

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


  ---Original Message---
  From: Landon Blake lbl...@ksninc.com
  Subject: RE: [OSGeo-Discuss] Open File   
 FormatsandProprietaryAlgorithms[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-boun...@lists.osgeo.org
  [mailto:discuss-boun...@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@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@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/discuss
  
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Open Source Lurkers

[Christopher Schmidt]

On Fri, Aug 21, 2009 at 11:55:30AM -0700, Landon Blake wrote:
 Is OpenJUMP the only community with these open source lurkers? 

No.

 How many of these companies do you think there are? (I'm not talking about
 one guy who downloads an open source app and uses it. I'm talking about
 actual companies with more than one employee.)

The majority. I figure it's approximately equal to the iceberg effect:
Unless you are a consultant advertising your services far and wide, my
guess is that for every one company you see participating openly in an
Open Source project, there are probably about 9 that are using the
software without you having any clue.

 Why don't they get more involved? 

 * No need: When Open Source solves the problem, you don't need to get
   involved.
 * No time: We'd love to participate more, but we've got our own
   problems to solve -- and they don't match those of the community.
 * No understanding: We download this software just like all of our
   other software. What's a mailing list?
 * Not enough encouragement. Gtting started in an open source project
   can be a daunting task even for the well-educated in the open source
   world; for those who aren't, it's an order of magnitude more
   difficult

 Are they embarrassed? Do they not want
 their competition to find out about the open source program they are
 benefiting from? Are they violating the terms of the license and don't
 want to get busted? 

I think these are generally unlikely.

 Do they not understand that their involvement is a
 key part of the program's survival?

It is likely they do not, in my opinoin; and in this, they may well be
right. The software existed before they started using it; it is likely
it will exist in some form afterwards as well.

 This has become an important question for me recently as the active
 development of OpenJUMP has slowed. We don't have any organizations
 actively participating in development. (Well, maybe one or two, but they
 have been quiet lately.) I'm the only one working on serious
 improvements or changes, and not just bug fixes. I would really like to
 reach out to these lurkers to get them more involved. Ultimately, the
 survival of the project may depend on it.

See also: OpenLayers.

Regards,
-- 
Christopher Schmidt
Web Developer
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Open Source Lurkers

[Landon Blake]

Thank you for your comments Christopher. I may just try my mailing list
invitation, and will let you guys know how it works out.

If there are other ideas on outreach of this type, I would like to hear
it.

I think the ultimate success of my favorite little GIS program may
depend on the results of this outreach.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Christopher
Schmidt
Sent: Friday, August 21, 2009 12:16 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open Source Lurkers

On Fri, Aug 21, 2009 at 11:55:30AM -0700, Landon Blake wrote:
 Is OpenJUMP the only community with these open source lurkers? 

No.

 How many of these companies do you think there are? (I'm not talking
about
 one guy who downloads an open source app and uses it. I'm talking
about
 actual companies with more than one employee.)

The majority. I figure it's approximately equal to the iceberg effect:
Unless you are a consultant advertising your services far and wide, my
guess is that for every one company you see participating openly in an
Open Source project, there are probably about 9 that are using the
software without you having any clue.

 Why don't they get more involved? 

 * No need: When Open Source solves the problem, you don't need to get
   involved.
 * No time: We'd love to participate more, but we've got our own
   problems to solve -- and they don't match those of the community.
 * No understanding: We download this software just like all of our
   other software. What's a mailing list?
 * Not enough encouragement. Gtting started in an open source project
   can be a daunting task even for the well-educated in the open source
   world; for those who aren't, it's an order of magnitude more
   difficult

 Are they embarrassed? Do they not want
 their competition to find out about the open source program they are
 benefiting from? Are they violating the terms of the license and don't
 want to get busted? 

I think these are generally unlikely.

 Do they not understand that their involvement is a
 key part of the program's survival?

It is likely they do not, in my opinoin; and in this, they may well be
right. The software existed before they started using it; it is likely
it will exist in some form afterwards as well.

 This has become an important question for me recently as the active
 development of OpenJUMP has slowed. We don't have any organizations
 actively participating in development. (Well, maybe one or two, but
they
 have been quiet lately.) I'm the only one working on serious
 improvements or changes, and not just bug fixes. I would really like
to
 reach out to these lurkers to get them more involved. Ultimately, the
 survival of the project may depend on it.

See also: OpenLayers.

Regards,
-- 
Christopher Schmidt
Web Developer
___
Discuss mailing list
Discuss@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Distributed Computing

[Mateusz Loskot]

Henning Lorenz wrote:
 Hi all,
 
 Mateusz's email about his unused MacPro brought another question to
 my mind (again): Is there interest in a distributed computing 
 infrastructure for OSGeo.

I would take a risk and say that there is no interest but a need or even
demand of bringing a usable farm to FOSS4G developers.

The distributed nature of FOSS development requires larger
teams to stick to principles of Continuous Integration [1] because
it is crucial to keep work moving smoothly, with assurance of
decent quality of final product that makes all team members happy
and motivated to move forward, stay with in the team project and
support community. All these aspects are crucial to make a project
healthy and sustainable, so successful.

[1] http://en.wikipedia.org/wiki/Continuous_integration

Without an efficient and reliable development infrastructure, it's
really hard to achieve these goals.
Many of big  healthy projects like Boost C++ Libraries, GCC,
PostgreSQL have used compile farms, distributed
regression test jobs, etc. We (OSGeo) have found Buildbot very helpful
once we've got used to use it.

So, for myself personally, no question about benefits of such solution.
The only problem I see is that we need more machines that are
connected 24/7 to make the whole solution usable and powerful
enough to serve all our projects.

 For us Mac users it's rather straight forward with XGrid if someone
 can host the server in an environment that allows for it (see
 OpenMacGrid at MacResearch.org), for other unices one would need a
 person with a good understanding of these things.

Yes, but this is a technical issue that can be solved by investigate,
learn and solve approach, IMHO.

 So lets collect some basic information (reply to this thread if the 
 answer on a question below is yes): - Would you like to contribute
 your waste CPU cycles to a grid aimed for OSGeo purposes? (what
 hardware, operating system)

Yes, as soon as my Mac Pro is plugged in.

 - Would you utilise such a grid for OSGeo purposes? (what operationg 
 system requirements do you have)

Yes.

 I myself have lot's of spare CPU cycles on my MacPro (now used by 
 OpenMacGrid) that I can contribute, but I won't become a user.

Thus, you may want to plug it into our Buildbot or equivalent for Java
(I apologise Java camp for my ignorance, but I don't know if OSGeo has
anything setup in that area, I only know Buildbot that serves C/C++ camp).

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Open Source Lurkers

[Mateusz Loskot]

Landon Blake wrote:
 What do you think? Send an e-mail to the project list with an
 invitation to contact me privately about getting more involved? Are
 these lurkers worth the time?

I would write a post on my blog:

***
Wow! This is a fantastic news!
I've just been told that the big company X has used OpenJUMP
in development of their supper-dupper and even more expansive product Y
for long long time. Every time we discover such story, it's terribly
encouraging to us, the OpenJUMP team, because it means we do an amazing
job of yet higher quality and even more usable than we've thought.
Thank you company X for such a proof of appreciation!
Dear X, keep watching and new features will keep coming.
***

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

RE: [OSGeo-Discuss] Open Source Lurkers

[Landon Blake]

Thanks for the suggestion Mateusz. Unfortunately I don't know who
Company X is. The blog post is a good idea though.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Friday, August 21, 2009 1:49 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open Source Lurkers

Landon Blake wrote:
 What do you think? Send an e-mail to the project list with an
 invitation to contact me privately about getting more involved? Are
 these lurkers worth the time?

I would write a post on my blog:

***
Wow! This is a fantastic news!
I've just been told that the big company X has used OpenJUMP
in development of their supper-dupper and even more expansive product Y
for long long time. Every time we discover such story, it's terribly
encouraging to us, the OpenJUMP team, because it means we do an amazing
job of yet higher quality and even more usable than we've thought.
Thank you company X for such a proof of appreciation!
Dear X, keep watching and new features will keep coming.
***

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Discuss mailing list
Discuss@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Open Source Lurkers

[Bill Thoen]

I've been a moderator for a commercial desktop mapping forum for more 
than 10 years and this behavior is quite common. I think it has more to 
do with how people adapt to a social network than it has to do with 
anything unique in the Open Source world. Like Chris mentioned, the 
majority of subscribers prefer to lurk below the public visibility 
horizon in a way that resembles an iceberg where only the tip remains 
above the waterline while the majority of its bulk lurks below.


People lurk for many of the reasons you suggest, but I think the most 
common one is that they don't feel expert enough to contribute anything 
useful to a thread, and the risk of saying something stoopid --in 
public... and worse, thus revealing to their GIS/mapping peers the depth 
of their ignorance-- is just too embarrassing to contemplate. Especially 
when compared with the perceived safety of remaining anonymous in the 
shadows where they can drink in new knowledge like free beer while also 
being entertained by the interplay of the forum's regularly featured 
fools and sages.


If we assume that Maslow was right about what motivates people 
(self-interest) then lurking in an open source community and not 
participating is exactly the wrong thing to do. If your business depends 
on some FOSS tool, then it's in your self-interest to expand the 
environment in which it operates as much as possible. Because if what 
you sell depends on tools like OpenJUMP, you want OpenJUMP well 
supported with a lively user group, a good supply of free data, 
technologically competitive, and actively being developed. This is the 
key to making money out of bits instead of atoms. If you sell services, 
give away the software and the infrastructure of the environment it runs 
in. This expands the market for your services and since the tools are 
free, the more people who download them the bigger your market share 
gets. If you sell software, give away services that leverage it. But if 
you lurk and don't contribute to its development or the development of 
the environment in which it operates, then you're sort of stepping on 
your own air hose.


- Bill Thoen


Landon Blake wrote:


I would like to get some comments on a phenomenon I have discovered 
among the OpenJUMP community. I know for sure of one (1) company that 
maintains a separate fork of OpenJUMP, but which monitors our mailing 
list and likely grabs patches form our source code repository. They 
never participate in the forums or make known their use of OpenJUMP in 
any other public manner.


I think there is at least one other company that does this.

I only learn of these companies when I am contacted by private e-mail 
to work for them on OpenJUMP development, usually by some headhunter. 
I actually did a little work for one of these companies (which was not 
a great experience, but that is another story) and I was surprised at 
how important OpenJUMP was to their operation. They even distributed 
it to their customers.


I couldn’t for the life of me figure out why this company wouldn’t 
take a more active role in supporting the OpenJUMP community. I’m not 
necessarily talking about money here, but about writing documentation, 
contributing their own patches, or answering questions on the mailing 
lists. Our community is very informal and open, and an organization 
could likely have a large influence on the direction the program took 
with an investment of some resources.


Is OpenJUMP the only community with these open source lurkers? How 
many of these companies do you think there are? (I’m not talking about 
one guy who downloads an open source app and uses it. I’m talking 
about actual companies with more than one employee.)


Why don’t they get more involved? Are they embarrassed? Do they not 
want their competition to find out about the open source program they 
are benefiting from? Are they violating the terms of the license and 
don’t want to get busted? Do they not understand that their 
involvement is a key part of the program’s survival?


This has become an important question for me recently as the active 
development of OpenJUMP has slowed. We don’t have any organizations 
actively participating in development. (Well, maybe one or two, but 
they have been quiet lately.) I’m the only one working on serious 
improvements or changes, and not just bug fixes. I would really like 
to reach out to these lurkers to get them more involved. Ultimately, 
the survival of the project may depend on it.


What do you think? Send an e-mail to the project list with an 
invitation to contact me privately about getting more involved? Are 
these lurkers worth the time?


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 

Re: [OSGeo-Discuss] Open Source Lurkers

[Abhay]

 Hi Landon,

What I feel it is also part of Me-too effect when such a event happens.

for eg.
If a person from X company is using any of the Open Source Intiative.
His/Her collegue from their own or some other division/company find out they
start there own endavour to get to it without any contribution or effort
been returned or even collabrate with previous person.

And other than that, also there come part of fear where in the company X may
or may not be ready to reveal that output generate is from any utility
of opensource and is as good as the output from Commerical software. They
stake their creditablity to commerical product rather than opensource one.
And just to beat the cost factor of the Commerical License they use Open
Source.

Rgds
Abhay.
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss