Geoscience Reference
In-Depth Information
simplifying the geography markup language (GML), was a wise step, in that it permitted the incor-
poration of a widely adopted lightweight data representation within a family of standards. Software
development benefits from disciplined standards and from rapid but occasionally chaotic progress;
we very often need both approaches and benefit from drawing them together where feasible.
While OGC pays considerable attention to interchange standards, other open standards specifi-
cations are of relevance for GC. Dunfey et al. (2006) present an open architecture vector GIS using
scalable vector graphics (SVG), easing visualisation because of the adoption of this standard by the
World Wide Web Consortium. SVG viewers of various kinds have been developed, some closed,
some open source, but all capable of rendering the same input data because the specification itself
is an open standard. Open-source software components may be used in connection with develop-
ment, but often to “glue” together data in known, sometimes standard, specifications; prototyping
using interpreted languages is an often chosen solution. Batcheller and Reitsma (2010) show how
open-source components may be integrated to permit spatial data discovery through feature level
semantics in this context.
While the availability of open standards, and of open-source software components, provides us
with a great deal of flexibility in application implementation, Schweik et al. (2009) point to advan-
tages in course design and training. The use of open-source software for training allows the trainer
to tailor the software to the needs of the course and removes the burden of acquiring and administer-
ing software licences. When using proprietary software, in addition to practical costs, the structure
of the course is “tailored” by the chosen software, perhaps diverting attention from the core focus.
However, much open-source software, in particular desktop GIS, appears to imitate popular
proprietary software, for example, Quantum GIS (QGIS) and the former ArcView desktop GIS may
well perform very similarly in training. In addition, courses are often obliged to take into account
the needs of participants to acquire familiarity with established proprietary systems before starting
work where these systems are deployed as standard. The tension between generic GIS and geospa-
tial training giving graduates general skills and software-specific training is very real, especially
where the software presupposes the dominance of a graphical user interface (GUI). Where generic
skills are taught in relation to scripting, interpreted languages and command-line interfaces, the
needs of participants to acquire abilities that can be applied at work from day one may be readily
met using any suitable mixture of open-source and proprietary software.
Steiniger and Bocher (2009) and Chen et al. (2010) give recent overviews of open-source GIS
software, but with constraints on what they see as general suitabilities and functionalities. It seems
that their preference for applications rather than component stacks has affected the ways in which
software is perceived. Preferences for GUIs have in particular obscured the fact that developing
GUIs absorbs a great deal of developer effort. Most open-source projects face their hardest con-
straints in the mobilisation and precise deployment of developer effort, because developers assign
themselves to tasks. Typically, open-source projects face choices between GUI toolboxes, with some
developers preferring one cross-platform toolbox, others preferring alternatives. All such projects
hit road bumps when the chosen toolbox “upgrades” in a way that is not backwards-compatible,
meaning that much GUI work has to be repeated and possibly supported for both the older and the
newer versions of that toolbox.
In the remainder of this section, we will consider the importance of programming language
environments, component stacks and mechanisms for joining components together and finally the
challenges that arise from trees of dependencies engendered between components.
14.2.1 l
anguage
e
nVironMentS
Câmara et al. (2012) following Ramsey (2007) distinguish between the language environments
characterising open-source geospatial software. Many projects use the compiled C and/or C++ lan-
guages; in the latter case, use varies between projects using modern C++ with templates and oth-
ers using C++ more as C. Historically, the adoption of compiled languages by projects has been
