[OSGeo-Board] The stack - what is it?
Gary Lang
gary.lang at autodesk.com
Thu Mar 9 22:51:11 PST 2006
This is great. Thanks. it gives me a lot of stuff to chase down and learn.
I'm pulling together a punch list of things to do because I would like the community to be able to tell us what things they want us to focus on in the first year and beyond. The highlights are captured on the wiki on the Mission page (http://wiki.osgeo.org/index.php/OSGeo_Mission):
Here's what is up on the Wiki today:
1) To provide resources for foundation projects - infrastructure, funding, legal, ...
2) To promote freely available geodata - free software is useless without data (Public Geospatial Data Project)
3) To promote the use of open source software in the geospatial industry (not just foundation software) - PR, training, outreach, ...
4) To encourage the implementation of open standards and standards-based interoperability in foundation projects.
5) To ensure a high degree of quality in foundation projects in order to build and preserve the foundation "brand".
6) To make foundation and related software more accessible to end users - binary "stack" builds, cross package documentation, etc.
7) To provide support for the use of OSGeo software in education via curriculum development, outreach, and support (Core Curriculum Project).
8) To encourage communication and cooperation between OSGeo communities. ie. Java/C tribes, *NIX/Windows, international
9) To operate an annual OSGeo Conference, possibly in cooperation with related efforts (ie. EOGEO).
10) To award the Sol Katz award for service to the OSGeo community.
Progress Report from where I sit:
1) Infrastructure: up and running. ready to take on projects. MapGuide went up quite easily. Developers already using it.
2) Funding: initial money provided. More available. Need to have a proven funding process (non-ADSK) in place by the sixth month as proof that we can be self-sustaining, in my mind, and non-ADSK money being provided by month 10. This is important for clear independence, which is important for everyone, including Autodesk.
3) PR: We're doing OK so far given what we are doing. Training: not started. Outreach: ad hoc. Committees being formed.
4) So far so good, though I think in terms of having an effect or influencing, the outreach needs to be developed.
5) Ad hoc. The brand is under development. Unclear how quality is to be measured.
6) We are just now starting to talk about the stack.
7) Not started. Committee formed?
8) Encourage communication between OSGeo communities: no information about this, though having an OSGeo seems to help.
9) Operate the annual conference. This is in 4 months, yes? Unclear where we are on this.
10) We have not discussed this. I assume the timing of this is related to 9)?
Please give me feedback: do I have the current status of 1) - 10) right? Also, let's list who we think are the "owners" of 1) - 10) tommorrow.
On 6), it feels to me like a good service OSGeo might provide is to build something like FWTools in combination with something like this: http://www.apachefriends.org/en/xampp.html, as well as PostGIS, tested and delivered on Linux, OS X, and Windows. Does this make sense to others?
What is the success of FWTools to date? # downloads? # list members? #committers? Should it be an OSGeo project?
Gary
-----Original Message-----
From: Frank Warmerdam on behalf of Frank Warmerdam (External)
Sent: Thu 3/9/2006 7:08 PM
To: board at board.osgeo.org
Cc:
Subject: Re: [OSGeo-Board] The stack - what is it?
Gary Lang wrote:
> Could you guys give me some help?
>
>
>
> I believe the table below enumerates most of the pieces of software
> people need/want throughout the GIS ecosystem. I have a couple of requests:
>
>
>
> 1) If I’m missing something (i.e. more rows needed) or have misstated
> something please let me know.
Gary,
I wouldn't organize things on these particular break points, though they
do seem plausible. You might want to read over the white paper refractions
prepared a bit over a year ago that tried to give a survey of open source
gis components and how they fit together.
http://www.refractions.net/white_papers/oss_briefing/2005-02-OSS-Briefing.pdf
> 2) Could you guys help me fill out the third column with G/FOSS
> package/project names?
I'll give my thoughts on some packages fitting these roles, though my
knowledge isn't comprehensive. Sorry for losing your original nice
formatting.
> The discussion around build machines has me thinking about the “full
> stack” mission of the OSGeo. I’d like to see what’s doable in delivering
> this entire stack.
>
> Let’s discuss the stack tomorrow at our meeting, time allowing.
I will mention that I believe Arnulf was speaking partly in terms of an
SDI stack. Basically RDBMS -> web services -> client services. Not
necessarily trying to fulfill all traditional GIS and image processing
functions. But it is educational to take a broader look.
> *Geographic Data Management*
>
> Database administration tools for managing data access by users, locking
> of data during edit and maintenance of metadata.
There are a few spatial database options, the most sophisticated and
mature of which is PostGIS on top of Postgres. I am not familiar with
any sophisticated middle where for managing data in PostGIS or other
OS geospatial RDBMSes. There are client applications like uDig for
editing it, but I wouldn't say they are sophisticated about locking in
a multi-user editing environment. Perhaps GeoServer's WFS-T and it's
locking on top of PostGIS would file some of that role.
> *Tabular Attribute Data Management*
>
> Software environment and capabilities for storing and managing database
> attributes linked to map features in the GIS database. May involve use
> of a vendor-proprietary system for attribute storage or a commercial
> relational database management package.
I'm assuming this is addressed by Postgres or MySQL and the various
fronts ends available, though I'm not sure I'm clear on what middle/client
side stuff you would be looking for.
> *GIS Data Import/ Export Utilities*
>
> Utility programs bundled with the GIS package for translation of GIS or
> CAD data to or from another format, including common industry-standard
> formats like DXF, SIF, DLG or SDTS.
I would claim that GDAL/OGR are the swiss army knife of data translation
in the OSGeo world. GRASS also has a substantial number of additional
translators.
> *GIS Data Entry and Editing*
>
> A range of interactive and batch processing functions for entry of map
> data through such means as board digitizing, coordinate geometry entry
> (COGO), scanning and heads-up digitizing, along with capabilities for
> editing GIS data, performing error checking and resolution, map
> rectification and transformation of coordinate systems and map projections.
Client applications such as uDig and QGIS fill much of this role. GRASS
also has a variety of vector editing capabilities, though I believe QGIS
is now used as a front end for some of these GRASS editing needs.
I *think* uDig is a natural editing front end for PostGIS and WFS-T's
though I'm a bit fuzzy on what is complete and what is under development.
There are also a variety of other packages with some degree of vector
editing such as OpenEV, Thuban, JUMP (actually quite good I think but
somehow supceeded by uDig?).
> *Map Design and Composition*
>
> Interactive capabilities for the design of map plots and displays,
> automatic creation of thematic maps and legends, and modifying map
> symbology and annotation for custom map displays.
I think GRASS is the most sophisticated at producing map output
suitable for printing. I believe several of the client applications
(thuban, uDig, JUMP, QGIS) have some capability. I have also seen
a significant number of people producing map output with GMT (the
Generic Mapping Toolkit).
> *Basic Geographic Query and*
>
> *Analysis Functions*
>
> Basic tools for performing attribute or map-based queries and displays,
> basic distance and area measurements, query and access to scanned
> documents, buffer generation, polygon overlay operations and other query
> and analysis functions.
I believe that GRASS, uDIG, JUMP and perhaps QGIS have some of interactive
and display functions. Underlying analysis is the vector domain is
mostly built on GEOS and it's Java parent JTS.
> *Network Analysis*
>
> Spatial analysis operations based on linear networks (e.g., road or
> pipeline systems), including such operations as shortest path tracing
> and region allocation. Network analysis capabilities in GIS packages
> often allow users to design network models based on attributes of
> network segments.
I have read about some network analysis modules available for PostGIS.
I believe GRASS also includes network analysis capabilities.
> *Terrain and 3-D Data Processing*
>
> *and Analysis*
>
>
> Capabilities for storing three-dimensional data normally in a grid or
> triangular integrated network (TIN) format with functions for 3-D
> analysis such as contour mapping, 3-D display, draping of map features
> over a 3-D display, slope and aspect analysis, etc.
I think GRASS has some TIN capabilities. Most terrain oriented
applications use gridded DEMs for terrain storage. OpenEV includes
3D viewing capabilities. GRASS includes a variety of terrain analysis
and the NVIS front end package for 3D visualization.
> *Raster Image Processing Capabilities*
>
> Capabilities for the manipulation and processing of raster images (e.g.,
> digital aerial photos or orthophotography, satellite images), including
> functions for the import and rectification of raw imagery, digital image
> enhancement and automated classification of multi-spectral imagery.
I think OSSIM addresses serious image processing, mosaicing, rectification
and related capabilities. GDAL utilities can also be used for some of this.
GRASS also has some of this.
> *Application Development Languages*
>
> Programming environment for customizing applications accessing software
> functions provided by the package, including proprietary languages
> included with the GIS software package or industry standard tools (e.g.,
> C++, Visual Basic, Delphi) that may be used for application development.
GRASS is very scriptable (in sort of an AML'ish sense - forgive the
comparison Markus!). Several packages provide good C/C++ APIs (GDAL/OGR,
OSSIM, GRASS). Several packages offer good support for scripting languages
(GDAL/OGR, MapServer, GEOS). GeoTools is the obvious base SDK for anyone
working in Java. GeoTools itself could (I think) be best described as a
Java GIS SDK. Of the scripting languages I think Python is best supported.
There is some degree of support for Perl, PHP, Ruby, and C#.
> *Data*
> >
> A GIS system is incomplete without access to large quantities of quality
> data.
Many formats are accessible. A variety of large free datasets can be found
at geotorrent.org. (landsat mosaics, VMAP, TIGER/Line, etc).
The obvious missing comonent is the whole web services, web mapping and
related. You also didn't mention geocoding - we have a couple existing
options, and SRC has indicated an interest in open sourcing their geocoder
as well.
Generally I think we (the broad open source geospatial community) is
strong in web services, basic SDKs, simple visualization. Via GRASS we
have a variety of esoteric GIS analysis capabilities. Via PostGIS we
have a solid spatial RDBMS.
We are weak in data management tools, sophisticated editing (specially
for a multi user environment) and quality map production.
Some of our more interesting analysis capabilities are available in
GRASS but can seem inaccessible to new or casual users.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGF, http://osgeo.org
---------------------------------------------------------------------
To unsubscribe, e-mail: board-unsubscribe at board.osgeo.org
For additional commands, e-mail: board-help at board.osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 9118 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/board/attachments/20060309/93ebda77/attachment.bin>
More information about the Board
mailing list