[Incubator] Project request

Daniel Brookshier dbrookshier at collab.net
Thu Apr 13 10:22:06 EDT 2006


Let me cover this first:

 >>does not justify to create a separate OSGeo subdomain

When there is a need to have a repository and support of that  
repository, the project and its subdomain are the best choice. This  
is why the system was designed this way. There is no additional cost  
for doing this and it was meant to divide projects up to best be  
managed by their maintainers and access by their users. Unless this  
is a component of another project - please think in terms of a stand- 
alone project.

Now to the edge case other than a component of a larger project. In  
this case we are looking at what could be a family of common data  
conversion tools. If these tools were managed as a set with a common  
governance (say it was led by Arnulf), then a single project is a  
good idea. But... if each of these tools had a different author, then  
separate projects are better.

Here is a summary of reasons:

Commit access - Limit those that commit to a limited reason for  
commit. Too many code bases also means many different reasons for  
commit and process around it.

Information Compartmentalization - Spam is stuff you are not  
interested in. Put too many subjects about different code bases into  
a project and you have spam.

Tool compartmentalization - Simply the web space, svn, ProjectTracker  
etc. are better when the focus is limited to a single code base.  
Commit messages and tracker messages are easier to manage by the  
developers.

  There is a reason that SourceForge and java.net is made up of  
thousands of projects and not a singe svn or cvs repository. The  
system works.

Again, don't think about this as 'worthy of a project', but 'worthy  
of compartmentalization and control'. In this case, it looks like you  
have a good case for a project.

Daniel Brookshier | Community Manager | CollabNet, Inc.
8000 Marina Blvd. Suite 600 | Brisbane, CA 94005 | USA
O 972.422.5261 | C 214.207.6614 | dbrookshier at collab.net


On Apr 10, 2006, at 6:23 AM, Arnulf Christl wrote:

> Hi,
> we (Arnulf) have been asked whether we (OSGeo) could provide an SVN  
> branch for a joint project that we (companies CCGIS & www.krz.de,  
> the county of OBK, ++individuals) implemented to convert the German  
> cadastral base map exchange format EDBS to OGC WKT for storage in  
> PostGIS, rendering in MapServer, access with GeoServer and display  
> with Mapbender.
>
> http://www.mapbender.org/index.php/ALK_mit_Freier_Software
> http://sourceforge.net/projects/edbs2wkt
> http://www.mapbender.org/index.php/EDBS
> http://www.mapbender.org/index.php/FreeZVAut
> etc.
>
> This project comes together with four UMN MapServer MAP files 2  
> symbol files, 8 ttf files with 250 symbols. You need all of this to  
> render the maps conforming to German jurisdiction. Conformancy is  
> required because the output generated by the system is used for  
> building application requests. And yes, every federal state in  
> Germany has its own interpretation... To manage and develop all of  
> this collaboratively SVN access has been requested.
>
> Now - where to put this?
>
> There is definitely an Open Source software project (GPL) involved  
> but it is of type benevolent dictator. Because this project  
> addresses only a tiny subset of the worlds population (Germans with  
> an affinity to survey data) this is fine with me but it does not  
> justify to create a separate OSGeo subdomain. On the other hand it  
> is an exemplary example of combining Public Geodata with Open  
> Source Software to give people at large better access to spatial data.
>
> It could be branched in Mapbender SVN but that does not make sense,  
> same is true for MapServer. Maybe this would best fit into the  
> Public Geodata SVN? Ideas, comments?
>
> Arnulf.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>





More information about the Geodata mailing list