DOC

ITQ 20026

By Mark Webb,2014-05-07 15:36
11 views 0
ITQ 20026

    The State of Open Source GIS

     Prepared By: Paul Ramsey, Director

     Refractions Research Inc.

     209 560 Johnson Street

     Victoria, BC, V8W-3C6

     pramsey@refractions.net

     Phone: (250) 885-0632

     Fax: (250) 383-2140

    Last Revised: May 30, 2004

TABLE OF CONTENTS

    1 SUMMARY.......................................................................................................................... 3 1.1 OPEN SOURCE ................................................................................................................ 3 1.2 OPEN SOURCE GIS ......................................................................................................... 5 2 IMPLEMENTATION LANGUAGES ................................................................................ 6 2.1 SURVEY OF ‘C’ PROJECTS ............................................................................................... 6 2.1.1 Shared Libraries ..................................................................................................... 7

    2.1.1.1 GDAL/OGR ....................................................................................................... 7

    2.1.1.2 Proj4................................................................................................................... 9

    2.1.1.3 GEOS ............................................................................................................... 10 2.1.2 Applications ......................................................................................................... 11

    2.1.2.1 OpenEV ........................................................................................................... 12

    2.1.2.2 UMN Mapserver ............................................................................................... 13

    2.1.2.3 GRASS ............................................................................................................ 14

    2.1.2.4 OSSIM ............................................................................................................. 15

    2.1.2.5 QGIS ................................................................................................................ 16

    2.1.2.6 Thuban ............................................................................................................. 17

    2.1.2.7 GMT ................................................................................................................ 18

    2.1.2.8 PostGIS ............................................................................................................ 20 2.2 SURVEY OF ‘JAVA PROJECTS ....................................................................................... 21 2.2.1 Shared Libraries ................................................................................................... 22

    2.2.1.1 GML4J ............................................................................................................. 22

    2.2.1.2 WKB4J ............................................................................................................ 22

    2.2.1.3 JTS Topology Suite .......................................................................................... 23

    2.2.1.4 GeoTools .......................................................................................................... 24 2.2.2 Applications ......................................................................................................... 25

    2.2.2.1 GeoServer ........................................................................................................ 25

    2.2.2.2 DeeGree ........................................................................................................... 26

    2.2.2.3 JUMP / JCS ...................................................................................................... 27

    2.2.2.4 OpenMap.......................................................................................................... 28

    2.2.2.5 uDig / JUMP2................................................................................................... 29

     - 2 -

1 SUMMARY

1.1 Open Source

    “Open source” software is technically defined as software in which the source

    code is available for modification and redistribution by the general public. There

    are a myriad of different open source software licenses, and the “Open Source

    Initiative” (http://www.opensource.org) has taken on the role of general arbiter of

    license correctness.

    However, it is easy to become overly distracted by licenses and source code when

    evaluating open source software (OSS), or considering OSS as a corporate or

    project strategy. Fundamentally, successful OSS projects are not created by

    releasing free source code they are created through the growth of communities

    of shared interest.

    For example, Apache is not a successful open source project because the code is

    freely available. There are numerous web server projects that have freely

    available and open source code. Apache is the preeminent open source web

    server because it commands a powerful community that shares an interest in

    maintaining Apache as a top-drawer web server. The Apache community

    includes corporate giants like IBM and HP, government agencies, and academic

    contributors. It also has a role for individual contributors. These diverse actors

    can work together collaboratively because the Apache software and the Apache

    organization have been engineered together to maximize transparency and

    openness:

    ? The software itself is designed in a modular manner. At a basic level,

    contributors can aid the project by writing special purpose modules which

    add otherwise obscure functionality. For example, mod_auth_pgsql allows

    Apache to do basic HTTP authentication by reading user names and

    passwords from a PostgreSQL database. This is obscure functionality, usable

    by maybe a few thousand users, but it adds an incremental value to the

    product, and the modularity of the software makes it easy to add.

    ? The software is extremely well documented. A successful project must

    reduce the amount of friction experienced by new contributors to a minimum,

    to maximize the amount of useful effort directed at the project. Time spent

    figuring out undocumented software internals is time not spent productively

    working on the code.

    ? The software core design and development process is transparent. All

    the mailing lists used by the core team for discussions of design ideas and

    future directions are public. Anyone can contribute to the discussion,

    although the core team will make the design decisions in the end. The source

    code is available throughout the development process, via a CVS (concurrent

    versioning system) archive, not just at release time.

     - 3 -

? The core team itself is modular and transparent. The core development

    team is made up of programmers who self-select. New members are added

    based on their contributions to the source code. When a core member ceases

    contributing to the project, they are removed after a set time period. There is

    a governance structure that openly allows access to the core team based on

    programming merit, not corporate or government affiliation.

    The strength of open source projects therefore should be evaluated not simply on

    technical merit or on legal licensing wording. OSS products should be evaluated

    like COTS (“commercial off-the-shelf”) products, comparing both the technical features and the vitality of the community that maintains and improves the

    project.

    Evaluations of OSS projects should ask:

    ? Is the project well documented? Does the web presence provide direct

    access to both the source code and documentation about the internals of the

    code? Is there tutorial level documentation for all three user categories (user,

    administrator, programmer) to get people up and working with the software

    quickly?

    ? Is the development team transparent? Is it clear who the core

    development team is? Is the development team mailing list public? Is the

    current development version of the code available online? Is membership in

    the team attainable via a merit-based process?

    ? Is the software modular? (This criterion is more applicable to some projects

    than others, depending on design constraints.) Is there a clear method to add

    functionality to the project that does not involve re-working the internals? Is

    this method documented clearly with examples? Is there a library of already-

    contributed enhancements maintained by the wider user / developer

    community?

    ? How wide is the development community? Are multiple organizations

    represented in the core development team? Are core team members

    financially supported in their work by sponsoring organizations? Is the

    development community national or international? How large is the user

    mailing list? How large is the developer mailing list?

    ? How wide is the user community? (This criterion is basically a standard

    COTS criterion more installations imply wider acceptance and testing.)

    What organizations have deployed the software? What experiences have they

    had?

    The more of these questions which are answered in the positive, the healthier the

    OSS project under examination is.

     - 4 -

1.2 Open Source GIS

    The Open Source GIS space includes products to fill every level of the OpenGIS

    spatial data infrastructure stack. Existing products are now entering a phase of

    rapid refinement and enhancement, using the core software structures that are

    already in place. Open Source software can provide a feature-complete

    alternative to proprietary software in most system designs.

    CascadingWMSServerJUMP

    WebJUMPBrowserGeoTools

    ThubanOpenEVTheInternet

    Local AreaGRASSHTTP/CGINetwork

    HTTP / XML

    HTTP / XML

    OpenGIS Web Map Server (WMS)

    University of Minnesota Mapserver

    HTTP / XML

    OGR Vector LibraryGDAL Raster Library

    JDBC / SQL

    PgNet / SQL

    GeoServer

    OpenGIS WebFeature Server (WFS)

    OpenGIS SQL DatabaseGIS Vector Files:Rasters and Images:PostGIS / PostgreSQLESRI Shape, MapInfo,TIFF, ERDAS, JPG,Spatial DatabaseSDTS, IGDS, GMLGIF, PNG

     - 5 -

    2 IMPLEMENTATION LANGUAGES Open Source GIS software can be categorized into two largely independent

    development tribes. Within each tribe, developers cross-pollinate very heavily,

    contribute to multiple projects, and have high awareness of ongoing

    developments. The two tribes can be loosely described as:

    ? The „C‟ tribe, consisting of developers working on UMN Mapserver, GRASS,

    GDAL/OGR, OSSIM, Proj4, GEOS, PostGIS and OpenEV.

    ? The „Java‟ tribe, consisting of developers working on GeoServer, GeoTools,

    JTS, JUMP/JCS, and DeeGree.

    The PostGIS/PostgreSQL project by virtue of standard database interfaces like

    libpq (C/C++), ODBC and JDBC (Java) is used by both tribes more or less equally. However, because it is written in C, PostGIS is a natural member of the

    C tribe and uses many of the C-based GIS support libraries. Mapserver is used

    by some Java developments via JNI (Java Native Interface) bindings, or via the

    OpenGIS WMS protocol.

    Both the C and Java development areas have a high degree of internal project

    linkage, with a great deal of leverage being applied through code reuse and

    linking libraries.

    2.1 Survey of ‘C’ Projects

    The „C‟ projects are, in general, more mature than the Java projects, having been in development for a longer period of time, and having had more time to attract

    active development communities. The core of the „C‟ projects are the shared

    libraries (shown in grey below), which are re-used across the application space

    and form the base infrastructure for common capabilities, such as format

    support and coordinate re-projection.

    PostGISGEOS

    OpenEV

    OSSIMOGR/GDAL

    GRASS

    Mapserver

    Proj4

    QGIS

    GMT

    Thuban

     - 6 -

2.1.1 Shared Libraries

    The shared libraries provide common capabilities across the various C-based

    applications, allowing applications to easily add features which would ordinarily

    involve a great deal of implementation.

    2.1.1.1 GDAL/OGR

    The GDAL/OGR libraries are really two logically separate pieces of code: GDAL

    provides an abstraction library for raster data and modules for reading and

    writing various raster formats; OGR provides an abstraction library for vector

    data and modules for reading and writing vector formats. However, the two

    libraries are maintained within the same build system for historical reasons and

    because both libraries are maintained by the same person.

    Maintainer: Frank Warmerdam (warmerdam@pobox.com) Web Site: http://remotesensing.org/gdal/

    Implementation Language: C++

    Source License: MIT

    Because the source license for GDAL/ORG is BSD, the library is also used in

    several proprietary GIS packages, and the maintainer derives some income

    through maintaining the capabilities of the package for these proprietary users.

    GDAL supports the following raster formats:

    Maximum Long Format Name Code Creation Georeferencing File Size Arc/Info ASCII Grid AAIGrid Yes Yes No limits Arc/Info Binary Grid (.adf) AIG No Yes -- Microsoft Windows Device BMP Yes Yes 4GiB Independent Bitmap (.bmp)

    BSB Nautical Chart Format BSB No Yes -- (.kap)

    CEOS (Spot for instance) CEOS No No -- First Generation USGS DOQ DOQ1 No Yes -- (.doq)

    New Labelled USGS DOQ DOQ2 No Yes -- (.doq)

    Military Elevation Data DTED No Yes -- (.dt0, .dt1)

    ERMapper Compressed ECW Yes Yes Wavelets (.ecw)

    ESRI .hdr Labelled EHdr No Yes -- ENVI .hdr Labelled Raster ENVI Yes Yes No limits Envisat Image Product (.n1) Envisat No No -- EOSAT FAST Format FAST No Yes -- FITS (.fits) FITS Yes No Graphics Interchange Format GIF Yes No (.gif)

     - 7 -

    Maximum Long Format Name Code Creation Georeferencing File Size Arc/Info Binary Grid (.adf) GIO Yes Yes GRASS Rasters GRASS No Yes -- TIFF / GeoTIFF (.tif) GTiff Yes Yes 4GiB Hierarchical Data Format HDF4 Yes Yes 2GiB Release 4 (HDF4)

    Erdas Imagine (.img) HFA Yes Yes No limits Atlantis MFF2e HKV Yes Yes No limits Japanese DEM (.mem) JDEM No Yes -- JPEG JFIF (.jpg) JPEG Yes Yes 4GiB (max

    dimentions

    65500x65500

    ) JPEG2000 (.jp2, .j2k) JPEG2000 Yes Yes JPEG2000 (.jp2, .j2k) JP2KAK Yes Yes NOAA Polar Orbiter Level 1b L1B No Yes -- Data Set (AVHRR)

    Erdas 7.x .LAN and .GIS LAN No Yes 2GB Atlantis MFF MFF Yes Yes No limits Multi-resolution Seamless MrSID No Yes -- Image Database

    NITF NITF Yes Yes OGDI Bridge OGDI No Yes -- PCI .aux Labelled PAux Yes No No limits Portable Network Graphics PNG Yes No (.png)

    Netpbm (.ppm,.pgm) PNM Yes No No limits USGS SDTS DEM SDTS No Yes -- (*CATD.DDF)

    SAR CEOS SAR_CEOS No Yes -- USGS ASCII DEM (.dem) USGSDEM No Yes -- X11 Pixmap (.xpm) XPM Yes No

OGR supports the following vector formats:

    Format Name Creation Georeferencing Arc/Info Binary Coverage No Yes

    ESRI Shapefile Yes Yes

    GML Yes No

    IHO S-57 (ENC) No Yes

    Mapinfo File Yes Yes

    Microstation DGN No No

    OGDI Vectors No Yes

    Oracle Spatial Yes Yes

    PostgreSQL Yes Yes

    SDTS No Yes

    UK .NTF No Yes

    U.S. Census TIGER/Line No Yes

     - 8 -

2.1.1.2 Proj4

    Proj4 is a coordinate re-projection library, capable of executing transformations

    between cartographic projection systems, and also between different spheroids

    and datums (where datum grid shifts are available).

    The Proj4 library was originally written by Gerald Evenden as an academic

    project in geodesy. The current maintainer is Frank Warmerdam, who began

    maintaining Proj4 after Evenden ceased actively working on the project. Evenden

    remains active on the mailing list, and is currently providing new mathematical

    projections, though not providing code maintenance.

    Maintainer: Frank Warmerdam (warmerdam@pobox.com) Web Site: http://remotesensing.org/proj/

    Implementation Language: C

    Source License: MIT-style

    Projections supported by the Proj4 library (projection code and common name):

    aea : Albers Equal Area mill : Miller Cylindrical aeqd : Azimuthal Equidistant mpoly : Modified Polyconic airy : Airy moll : Mollweide aitoff : Aitoff murd1 : Murdoch I alsk : Mod. Stererographics of Alaska murd2 : Murdoch II apian : Apian Globular I murd3 : Murdoch III august : August Epicycloidal nell : Nell bacon : Bacon Globular nell_h : Nell-Hammer bipc : Bipolar conic of western hemisphere nicol : Nicolosi Globular boggs : Boggs Eumorphic nsper : Near-sided perspective bonne : Bonne (Werner lat_1=90) nzmg : New Zealand Map Grid cass : Cassini ob_tran : General Oblique Transformation cc : Central Cylindrical ocea : Oblique Cylindrical Equal Area cea : Equal Area Cylindrical oea : Oblated Equal Area chamb : Chamberlin Trimetric omerc : Oblique Mercator collg : Collignon ortel : Ortelius Oval crast : Craster Parabolic (Putnins P4) ortho : Orthographic denoy : Denoyer Semi-Elliptical pconic : Perspective Conic eck1 : Eckert I poly : Polyconic (American) eck2 : Eckert II putp1 : Putnins P1 eck3 : Eckert III putp2 : Putnins P2 eck4 : Eckert IV putp3 : Putnins P3 eck5 : Eckert V putp3p : Putnins P3' eck6 : Eckert VI putp4p : Putnins P4' eqc : Equidistant Cylindrical (Plate Caree) putp5 : Putnins P5 eqdc : Equidistant Conic putp5p : Putnins P5' euler : Euler putp6 : Putnins P6 fahey : Fahey putp6p : Putnins P6' fouc : Foucaut qua_aut : Quartic Authalic fouc_s : Foucaut Sinusoidal robin : Robinson gall : Gall (Gall Stereographic) rpoly : Rectangular Polyconic gins8 : Ginsburg VIII (TsNIIGAiK) sinu : Sinusoidal (Sanson-Flamsteed) gn_sinu : General Sinusoidal Series somerc : Swiss. Obl. Mercator gnom : Gnomonic stere : Stereographic goode : Goode Homolosine tcc : Transverse Central Cylindrical gs48 : Mod. Stererographics of 48 U.S. tcea : Transverse Cylindrical Equal Area gs50 : Mod. Stererographics of 50 U.S. tissot : Tissot hammer : Hammer & Eckert-Greifendorff tmerc : Transverse Mercator hatano : Hatano Asymmetrical Equal Area tpeqd : Two Point Equidistant imw_p : International Map of the World Polyconic tpers : Tilted perspective kav5 : Kavraisky V ups : Universal Polar Stereographic

     - 9 -

kav7 : Kavraisky VII urm5 : Urmaev V labrd : Laborde urmfps : Urmaev Flat-Polar Sinusoidal laea : Lambert Azimuthal Equal Area utm : Universal Transverse Mercator (UTM) lagrng : Lagrange vandg : van der Grinten (I) larr : Larrivee vandg2 : van der Grinten II lask : Laskowski vandg3 : van der Grinten III latlong : Lat/long (Geodetic) vandg4 : van der Grinten IV longlat : Lat/long (Geodetic) vitk1 : Vitkovsky I lcc : Lambert Conformal Conic wag1 : Wagner I (Kavraisky VI) leac : Lambert Equal Area Conic wag2 : Wagner II lee_os : Lee Oblated Stereographic wag3 : Wagner III loxim : Loximuthal wag4 : Wagner IV lsat : Space oblique for LANDSAT wag5 : Wagner V mbt_s : McBryde-Thomas Flat-Polar Sine (No. 1) wag6 : Wagner VI mbtfpp : McBride-Thomas Flat-Polar Parabolic wag7 : Wagner VII 2.1.1.3 GEOS mbtfpq : McBryde-Thomas Flat-Polar Quartic weren : Werenskiold I mbtfps : McBryde-Thomas Flat-Polar Sinusoidal wink1 : Winkel I merc : Mercator wink2 : Winkel II GEOS is the “Geometry Engine, Open Source”, a C++ implementation of the JTS mil_os : Miller Oblated Stereographic wintri : Winkel Tripel topology library. GEOS provides C++ implementations of all the simple features

    objects found in the OpenGIS “Simple Features for SQL” specification, and

    implementations of all the methods defined for those objects.

    Topological calculations are easy to visualize, but hard to implement in generality.

    The GEOS/JTS algorithms are robust for all the spatial predicates (geometric

    comparisons which return true/false values). The GEOS/JTS algorithms have

    only a few known failure modes in the spatial operators (geometric functions

    which produce geometric results).

    Important GEOS Methods Predicates Operators Relate(Geom) Intersection(Geom) Touches(Geom) Union(Geom) Disjoint(Geom) Difference(Geom) Intersects(Geom) Buffer() Contains(Geom) Distance(Geom) Crosses(Geom) Length() Within(Geom) Area() Overlaps(Geom)

    IsValid()

    Maintainer: Refractions Research (info@refractions.net) Web Site: http://geos.refractions.net/

    Implementation Language: C++

    Source License: GPL

     - 10 -

Report this document

For any questions or suggestions please email
cust-service@docsford.com