date:20090825

Re: [OSGeo-Discuss] Open File Formats and Proprietary Algorithms

2009-08-25 Thread Ted Habermann

Lots of discussions on standardization of data formats, lots of 
challenges there. One thing that has not been mentioned (I think) is the 
idea of standardizing responses from users about 1) uses of data and 2) 
limitations of data (files too big fits in here). Both of these are 
included in the MD_Usage object that is part of the ISO 19115 Standard 
included in GeoNetwork. Would be very cool to build into GeoNetwork the 
capability to accept user feedback about datasets and to associate that 
feedback with the appropriate datasets in the GeoNetwork catalog and to 
make it available to 1) data providers and 2) future users...


Seems straightforward,
Ted

--
 Ted Habermann ===
Enterprise Data Systems Group Leader
NOAA, National Geophysical Data Center
V: 303.497.6472   F: 303.497.6513
"If you want to go quickly, go alone.
If you want to go far, go together"
Old Proverb
 ted.haberm...@noaa.gov ==

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

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

2009-08-25 Thread Michael P. Gerlek

To be clear, it's not an effort I have the bandwidth for personally.  But if 
there were qualified developers interested in taking it on, I might be in a 
position to offer project guidance and a small amount of funding.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Landon Blake
Sent: Tuesday, August 25, 2009 11:12 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary Algorithms

OK. I'm not an expert on images, but I'd be interested in working with
you. However, I avoid C++ like a lethal strain of the Swine Flu. :]

I may give some more thought to some of Bob's ideas about making it
easier to work with image tiles.

Thanks.

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: Monday, August 24, 2009 3:19 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

I've not given it much thought recently, to be honest.  I'd need to
review the current state of things in OpenJp2 (or whatever it's called)
to see where they are at, what changes would be realistic and viable,
how amenable they'd be to taking patches versus a fork, etc.  Done
properly, the work would have no "geo" specific component at all -- it
would just be a new version of some of the internal algorithms.  The
test case would simply be to encode and decode an 500 GB(?) raw file on
a box with 2 GB (?) of RAM.

I would certainly not want anyone to have to build a whole new jp2
library from scratch, if that's what you meant.  I'd really only be
interested in C++ (or possibly mono-safe C#).

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Landon Blake
Sent: Monday, August 24, 2009 4:11 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

MPG:

When you say "effort" do you mean some sort of library to support JP2
geo side of things?

What programming language would you be most interested in? C++?

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: Monday, August 24, 2009 1:59 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

It would not be a good SoC thing, due to the level of expertise and time
required.

I (LizardTech) would likely be willing to contribute to such an effort.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Fawcett, David
Sent: Monday, August 24, 2009 8:11 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms


I realize that there are likely not a large number of people who have
the expertise and experience to write this kind of code.  

Is this a project that should be shopped around for funding?  Google
Summer of Code?  A grant from our ~benevolent overlord Google?  Some
other foundation or org interested in open data formats?  

David.
-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Thursday, August 20, 2009 4:36 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms



> Do you know why there hasn't been a broader adoption of JP2?

Not through lack of trying on my part :-)

I think the two biggest reasons are:

(1) The algorithms for handling large images in memory really are rocket
science, and no one in the FOSS community has gotten the "itch"
sufficiently bad enough to go and do the work needed inside the existing
open source packages.  Hopefully someday someone will.


___
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


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 Formats andProprietaryAlgorithms

2009-08-25 Thread Bob Basques

Landon, 

Rather than sput off about something theoretical, I'll relate our use of
MRSID deliverables. 

This is our Typical publishing process for MRSID format data that we
receive, which happens fairly regularly. 

Our use case in this instance is for visual inspection of aerial
photography. 

* First we extract JPG tile pyramids from the MrSID format into
MapServer ready tile layers doubling/halving the resolution of the
output for each level of tiles along with generating WORLD files for
each tile. (we actually have a static grid that we use for tiling that
makes this a one time process, since the WORLD files are reusable across
data sets.) 
* Then, index the tiles for each level for Mapserver's use  We start at
Level "0" (L0 = 6" resolution) and increase by doubling resolution until
we have a single tile at the City view level, ~L7. 
* Mapserver is setup with a multi-level display with cutoffs for each
tiled layer at the appropriate scales. 
* This approach guarantees only four tiles at most (as long as the
client viewer pixel width isn't bigger than the tile pixel size of each
tile) are ever retrieved by MapServer to build a composite output image.

The first three steps could be automated into a package that ran
automatically for example from most MRSID deliverables. 

Another use case might be DEM analysis, which might require converting
into other formats as well as the data originating in some other format
besides MRSID. 

Still another use case might be spectral separation and handling the
consequent analysis tasks. 

Anyway, the list goes on and on I sppose. 

bobb 

>>> "Landon Blake"  wrote:

Bob, 

What did you have in mind when you said “pre-processing”. 

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: 

Monday, August 24, 2009 9:21 AM

To: 

OSGeo Discussions

Subject: 

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms 

Landon, 

Just had another thought . . . 

What about setting up a (openSource) tool set specifically for handling
Raster images for pre-processing purposes.  Might even be something that
publishers could re-distribute with their datasets, as in this processor
stack works with our data. 

Just thinking on the run here, no detail (or ramifications though
through [at all  :c) ]) 

bobb 

>>> "Bob Basques"  wrote: 

Landon, 

>It would be interesting to come up with a standard structure on a
computer file system that could be used to accessed tiled raster data,
if this hasn’t been done already. One the file system structure was
defined, it would be fairly easy to write open source software that
accessed this structure and provided individual tiles as a service to
desktop GIS applications.   

Hmm, interesting angle, to expand on your idea a bit more, what about a
processing suite (or set of suites) that process data for different
types of uses, visual display, DEM analysis, etc.  Each "processor"
stack would/could have it's own rules associated with data resolution vs
files sizes, etc.   

bobb 

>>> "Landon Blake"  wrote: 

Bobb wrote: “Here's my reasoning, we're never (ever?) going to hit the
top end on how big files ever get, resolution just keeps going up and
up, so there is always going to be some upper limit that will need to be
breached somehow.  Working out a proper method for segregating the data
up front (dare I say it), as some sort of standard (which can be
adjusted as time passes) will make everything work nicely, then all will
work with available tools when they are available, if tools to handle
larger datasets become available, and the communityI agree with some of the 
points you are making in your argument Bobb.
There is certainly a practical limit to how much you data you should put
in a single file. That is why we have lumber cut to 8 foot lengths. You
don’t need a flatbed semi to carry it to your house. :] 

When you refer to a standard for splitting data up front, what do you
mean? 

It would be interesting to come up with a standard structure on a
computer file system that could be used to accessed tiled raster data,
if this hasn’t been done already. One the file system structure was
defined, it would be fairly easy to write open source software that
accessed this structure and provided individual tiles as a service to
desktop GIS applications. 

Landon 

From: 

discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org]

On Behalf Of 

Bob Basques 

Sent: 

Monday, August 24, 2009 7:33 AM 

To: 

OSGeo Discussions 

Subject: 

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

All, 

Ok, I'

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms

2009-08-25 Thread Landon Blake

Bob,

What did you have in mind when you said "pre-processing".

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: Monday, August 24, 2009 9:21 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms

Landon, 

Just had another thought . . . 

What about setting up a (openSource) tool set specifically for handling
Raster images for pre-processing purposes.  Might even be something that
publishers could re-distribute with their datasets, as in this processor
stack works with our data. 

Just thinking on the run here, no detail (or ramifications though
through [at all  :c) ]) 

bobb 

>>> "Bob Basques"  wrote:

Landon, 

>It would be interesting to come up with a standard structure on a
computer file system that could be used to accessed tiled raster data,
if this hasn't been done already. One the file system structure was
defined, it would be fairly easy to write open source software that
accessed this structure and provided individual tiles as a service to
desktop GIS applications.   

Hmm, interesting angle, to expand on your idea a bit more, what about a
processing suite (or set of suites) that process data for different
types of uses, visual display, DEM analysis, etc.  Each "processor"
stack would/could have it's own rules associated with data resolution vs
files sizes, etc.   

bobb 

>>> "Landon Blake"  wrote:

Bobb wrote: "Here's my reasoning, we're never (ever?) going to hit the
top end on how big files ever get, resolution just keeps going up and
up, so there is always going to be some upper limit that will need to be
breached somehow.  Working out a proper method for segregating the data
up front (dare I say it), as some sort of standard (which can be
adjusted as time passes) will make everything work nicely, then all will
work with available tools when they are available, if tools to handle
larger datasets become available, and the community feels there is a
reason/need that these new larger files need to be handled, then they
get to change the standard." 

I agree with some of the points you are making in your argument Bobb.
There is certainly a practical limit to how much you data you should put
in a single file. That is why we have lumber cut to 8 foot lengths. You
don't need a flatbed semi to carry it to your house. :] 

When you refer to a standard for splitting data up front, what do you
mean? 

It would be interesting to come up with a standard structure on a
computer file system that could be used to accessed tiled raster data,
if this hasn't been done already. One the file system structure was
defined, it would be fairly easy to write open source software that
accessed this structure and provided individual tiles as a service to
desktop GIS applications. 

Landon 

From: 

discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org]

On Behalf Of 

Bob Basques

Sent: 

Monday, August 24, 2009 7:33 AM

To: 

OSGeo Discussions

Subject: 

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

All, 

Ok, I'm probably going to get someone irritated, but here goes . . 

Why not approach this from the other end of the spectrum and work at
making the original files smaller.  Work with the providers to make the
images smaller in the first place, or at least come up with a maximum
practical size to work with, I mean if this is the only (or biggest
reason) for implementing JP2, then getting folks to make the smaller
deliverables seems like a better long term approach. 

Here's my reasoning, we're never (ever?) going to hit the top end on how
big files ever get, resolution just keeps going up and up, so there is
always going to be some upper limit that will need to be breached
somehow.  Working out a proper method for segregating the data up front
(dare I say it), as some sort of standard (which can be adjusted as time
passes) will make everything work nicely, then all will work with
available tools when they are available, if tools to handle larger
datasets become available, and the community feels there is a
reason/need that these new larger files need to be handled, then they
get to change the standard. 

bobb 

>>> "Fawcett, David"  wrote: 

I realize that there are likely not a large number of people who have
the expertise and experience to write this kind of code. 

Is this a project that should be shopped around for funding?  Google
Summer of Code?  A grant from our ~benevolent overlord Google?  Some
other foundation or org interested in open d

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

2009-08-25 Thread Landon Blake

OK. I'm not an expert on images, but I'd be interested in working with
you. However, I avoid C++ like a lethal strain of the Swine Flu. :]

I may give some more thought to some of Bob's ideas about making it
easier to work with image tiles.

Thanks.

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: Monday, August 24, 2009 3:19 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

I've not given it much thought recently, to be honest.  I'd need to
review the current state of things in OpenJp2 (or whatever it's called)
to see where they are at, what changes would be realistic and viable,
how amenable they'd be to taking patches versus a fork, etc.  Done
properly, the work would have no "geo" specific component at all -- it
would just be a new version of some of the internal algorithms.  The
test case would simply be to encode and decode an 500 GB(?) raw file on
a box with 2 GB (?) of RAM.

I would certainly not want anyone to have to build a whole new jp2
library from scratch, if that's what you meant.  I'd really only be
interested in C++ (or possibly mono-safe C#).

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Landon Blake
Sent: Monday, August 24, 2009 4:11 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

MPG:

When you say "effort" do you mean some sort of library to support JP2
geo side of things?

What programming language would you be most interested in? C++?

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: Monday, August 24, 2009 1:59 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms

It would not be a good SoC thing, due to the level of expertise and time
required.

I (LizardTech) would likely be willing to contribute to such an effort.

-mpg


-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Fawcett, David
Sent: Monday, August 24, 2009 8:11 AM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms


I realize that there are likely not a large number of people who have
the expertise and experience to write this kind of code.  

Is this a project that should be shopped around for funding?  Google
Summer of Code?  A grant from our ~benevolent overlord Google?  Some
other foundation or org interested in open data formats?  

David.
-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Michael P. Gerlek
Sent: Thursday, August 20, 2009 4:36 PM
To: OSGeo Discussions
Subject: RE: [OSGeo-Discuss] Open File Formats and Proprietary
Algorithms



> Do you know why there hasn't been a broader adoption of JP2?

Not through lack of trying on my part :-)

I think the two biggest reasons are:

(1) The algorithms for handling large images in memory really are rocket
science, and no one in the FOSS community has gotten the "itch"
sufficiently bad enough to go and do the work needed inside the existing
open source packages.  Hopefully someday someone will.


___
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


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

2009-08-25 Thread Landon Blake

Jody,

 

Thank you for all of your comments. They were insightful. 

 

I should point out that I don't get really bothered by the private
contacts, which aren't that frequent, and was more interested in finding
a way to get lurkers more involved. It seems this is more challenging
than I first realized.

 

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 Jody Garnett
Sent: Tuesday, August 25, 2009 6:31 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Open Source Lurkers

 

Evening Landon:

 

As you have gathered from the responses thus far that lurkers are
actually the larger part of the user community - and do not really
represent an opportunity to acquire new developers for your project.

 

The point is that they are part of the user community; and are probably
not in a position or motivation to become part of the development
community.

 

Some tips for involving them:

- make sure project wiki; issue tracker etc is very open to input

 

What to do when they email you directly:

- This is a hard one; they are asking for free support; and are too shy
or unable to go to the public email list

- I answer (or point out docs) and remind them that LISAsoft offers
commercial support; and that free support from fellow users is available
on the email lists

- If they have an issue I may turn their issue into an item on the bug
tracker; and invite them to add comments with more details. I find it
easier to show how to make a good bug report  (but other developers have
helpful links about how to make a bug report).

 

What happens next is kind of up to the reaction...

 

If they launch into the issue tracker; or user list; and start
interacting with community members:

- if it is a documentation or api question I will write a wiki page and
ask them to review.

- If it is a bug - It is time to start talking about patches; creating
them; attaching them to the bug tracker; and so on.

- The first time I will facilitate this process; often using IRC or
something

- Chances are if they have started down this road they are going to have
a successful open source experience and after a few months (6 months to
a year) it is time to start talking to them about commit access and
taking a larger role. 

 

If they persist in contacting me directly:

- If they are contacting me by my work email address - I usually feel
comfortable phoning and/or asking talking to their boss about commercial
support options at this stage :-)

- If they persist in contacting me directly; I will start to CC my
responses to the public email list (I change my note about commercial
support to a link to all the organizations offering commercial support
as it is not great to advertise).  There is the risk of of course deeply
offending someone and/or getting them in trouble - this is balanced by
the risk of being taken advantage of. 

- Chances are If they start down this road I will hook them up with one
of the companies supporting GeoTools (on a good day it will be a company
I work for)

 

What is fascinating to me is how well some of the distributed version
control technologies are geared towards allowing groups to have a shadow
copy of a project. Maybe I should reword that as an "internal" version
of a project; it is actually  a really good practice; offering a balance
between "Sticking behind on a stable version" vs the risk of "using the
latest". It really provides a programming team to control the software
they are getting from the community at a different pace then the release
cycle; it is also really good in that these teams can live and breath
patches - and can hire you to fix problems.

 

What is more difficult is explaining about how LGPL means that the work
they do internally needs to come out :-) But that is a topic for another
day ...

 

Cheers,

Jody

 

On 22/08/2009, at 4:55 AM, 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

Re: [OSGeo-Discuss] Geodata as Public Record in U.S.

2009-08-25 Thread Bob Basques

Take the space off the end of the link "%20", 

It works if you paste in this link: 

http://home.centurytel.net/wilsonlandsurvey/docs/GIS%20Data%20as%20Public%20Record.pdf
 ( 
http://home.centurytel.net/wilsonlandsurvey/docs/GIS%20Data%20as%20Public%20Record.pdf
 ) 

bobb 


>>> Bill Thoen  wrote:

Richard Greenwood wrote:
> A friend of my prepared this analysis of geodata distribution and fees
> at the county government level in the US:
> http://home.centurytel.net/wilsonlandsurvey/docs/GIS Data as Public
> Record.pdf
>   ( 
> http://home.centurytel.net/wilsonlandsurvey/docs/GIS%20Data%20as%20Public%20Record.pdf%20
>  )>
This comes up as 404 (not found) Is that the correct URL?

___
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] Geodata as Public Record in U.S.

2009-08-25 Thread Richard Greenwood

My first post had a space at the end of the URL. Try:
http://home.centurytel.net/wilsonlandsurvey/docs/GIS Data as Public
Record.pdf


On Tue, Aug 25, 2009 at 8:27 AM, Bill Thoen wrote:
> Richard Greenwood wrote:
>>
>> A friend of my prepared this analysis of geodata distribution and fees at
>> the county government level in the US:
>> http://home.centurytel.net/wilsonlandsurvey/docs/GIS Data as Public
>> Record.pdf
>> <
http://home.centurytel.net/wilsonlandsurvey/docs/GIS%20Data%20as%20Public%20Record.pdf%20
>
>
> This comes up as 404 (not found) Is that the correct URL?
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>



-- 
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Geodata as Public Record in U.S.

2009-08-25 Thread Bill Thoen


Richard Greenwood wrote:
A friend of my prepared this analysis of geodata distribution and fees 
at the county government level in the US:
http://home.centurytel.net/wilsonlandsurvey/docs/GIS Data as Public 
Record.pdf 


This comes up as 404 (not found) Is that the correct URL?

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

Re: [OSGeo-Discuss] Open Source Lurkers

2009-08-25 Thread Jody Garnett


Evening Landon:

As you have gathered from the responses thus far that lurkers are  
actually the larger part of the user community - and do not really  
represent an opportunity to acquire new developers for your project.


The point is that they are part of the user community; and are  
probably not in a position or motivation to become part of the  
development community.


Some tips for involving them:
- make sure project wiki; issue tracker etc is very open to input

What to do when they email you directly:
- This is a hard one; they are asking for free support; and are too  
shy or unable to go to the public email list
- I answer (or point out docs) and remind them that LISAsoft offers  
commercial support; and that free support from fellow users is  
available on the email lists
- If they have an issue I may turn their issue into an item on the bug  
tracker; and invite them to add comments with more details. I find it  
easier to show how to make a good bug report  (but other developers  
have helpful links about how to make a bug report).


What happens next is kind of up to the reaction...

If they launch into the issue tracker; or user list; and start  
interacting with community members:
- if it is a documentation or api question I will write a wiki page  
and ask them to review.
- If it is a bug - It is time to start talking about patches; creating  
them; attaching them to the bug tracker; and so on.
- The first time I will facilitate this process; often using IRC or  
something
- Chances are if they have started down this road they are going to  
have a successful open source experience and after a few months (6  
months to a year) it is time to start talking to them about commit  
access and taking a larger role.


If they persist in contacting me directly:
- If they are contacting me by my work email address - I usually feel  
comfortable phoning and/or asking talking to their boss about  
commercial support options at this stage :-)
- If they persist in contacting me directly; I will start to CC my  
responses to the public email list (I change my note about commercial  
support to a link to all the organizations offering commercial support  
as it is not great to advertise).  There is the risk of of course  
deeply offending someone and/or getting them in trouble - this is  
balanced by the risk of being taken advantage of.
- Chances are If they start down this road I will hook them up with  
one of the companies supporting GeoTools (on a good day it will be a  
company I work for)


What is fascinating to me is how well some of the distributed version  
control technologies are geared towards allowing groups to have a  
shadow copy of a project. Maybe I should reword that as an "internal"  
version of a project; it is actually  a really good practice; offering  
a balance between "Sticking behind on a stable version" vs the risk of  
"using the latest". It really provides a programming team to control  
the software they are getting from the community at a different pace  
then the release cycle; it is also really good in that these teams can  
live and breath patches - and can hire you to fix problems.


What is more difficult is explaining about how LGPL means that the  
work they do internally needs to come out :-) But that is a topic for  
another day ...


Cheers,
Jody

On 22/08/2009, at 4:55 AM, 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 involve

Re: [OSGeo-Discuss] Open File Formats and Proprietary Algorithms

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

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms

RE: [OSGeo-Discuss] Open File Formats andProprietaryAlgorithms

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

RE: [OSGeo-Discuss] Open Source Lurkers

Re: [OSGeo-Discuss] Geodata as Public Record in U.S.

Re: [OSGeo-Discuss] Geodata as Public Record in U.S.

Re: [OSGeo-Discuss] Geodata as Public Record in U.S.

Re: [OSGeo-Discuss] Open Source Lurkers

10 matches

Site Navigation

Mail list logo

Footer information