Geoscience Reference
In-Depth Information
Yi et al. 2008), landscape ecology (Steiniger and Hay 2009), water resources management (Chen
et al. 2010) and courseware for geographical information systems (GIS*) education (Schweik et al.
2009). Roberts et al. (2010) provide much insight into the ways in which open-source and propri-
etary software solutions intermesh in ecological geoprocessing. Finally, a further general survey is
provided by Steiniger and Bocher (2009), in which the categories of the different software varieties
and the range of open-source licence conditions are discussed in detail. Here, we will accept their
broad definition of free and open-source software, termed open source for brevity, without further
discussion, as the distinctions seem clear, are largely shared by Rey (2009) and so do not require
repeating at length.
Our task here is rather to review central issues and projects of importance for GC related to
open-source software and the enriching of workflows that may be achieved by adding open-
source components to otherwise proprietary approaches. The open-source components are dis-
tinguished by the availability of source code under free and/or open-source software licences; by
access to infrastructures, such as version control systems for source code, bug trackers, mailing
lists and at least partly organised communities; and by the documentation of external dependen-
cies in the build and install system. As will be shown in the succeeding text, these qualities may
vary a good deal across projects, with consequences for the ease of software stacking (or other-
wise) experienced in practice.
We will proceed by examining software component stacks for GC first, looking at language
environments, software component stacks (defined in Section 14.2.2) and crucially at dependency
challenges. Next, we describe selected open-source geospatial projects within the narrow definition
of projects associated with the Open Source Geospatial Foundation (OSGeo), which provides key
shared infrastructure for projects, as well as major annual international conferences. Drawing on
my own experience, we go on to see how OSGeo (see Section 14.3) projects have been interfaced
with the R statistical language and environment, providing examples of how GC may be advanced
by using R for programming, scripting and analysis. Alternatively, the Python language and envi-
ronment, or other candidates, could have been chosen. It is worth noting that tools for spatial statisti-
cal analysis are being provided by PySAL, which may be integrated using Python with the many
other geospatial applications with Python interfaces. My experience has however mostly been with
R , and this determines the focus chosen here. We round off by discussing future prospects.
14.2 SOFTWARE COMPONENT STACKS FOR GC
Before discussing software component stacks for GC, we should acknowledge the importance of
open standards for geospatial data interchange. Unless data formats and protocols are agreed, it
is very difficult to generate the synergies required for constructive collaboration. Kralidis (2008)
points out the importance of concepts such as that of spatial data infrastructure, whether estab-
lished within national jurisdictions, within supranational jurisdictions or by international standards
organisations. A fuller coverage of the relationships between spatial data infrastructures and free
and open-source geospatial software is given by Steiniger and Hunter (2012). The work of the Open
Geospatial Consortium (OGC), with members drawn both from software companies, research insti-
tutes and the broader user community, has been central in this respect. The availability of publicly
adopted OGC standards has made it possible for software developers of all varieties to share key
specifications that enable data to be passed from component to component in controlled ways.
Kralidis (2008) also helpfully distinguishes between formal, de facto and ad hoc standards,
which provide the flexibility needed to move ahead somewhat faster than standards committees
are usually able to do. The adoption of the keyhole markup language (KML) as an OGC standard,
* GIS will be used in the remainder of this chapter to mean geographical information system.
https://github.com/pysal/pysal.
Search WWH ::




Custom Search