Geoscience Reference
In-Depth Information
Mapping parties
(the fun stuff)
WMS
services
Yahoo!
imagery
GPX traces,
photos and notes
Etcetera
www.osm.org website
Map editing
software
Mapzen
Openlayers
('slippy map')
Map tiles
Potlatch
Merkaator
JOSM
Mapnik +
mod_tile
t@hngo
server
My SQL
Mapnik
style-sheets
Geodata
tiles@home
clients
tiles@home
(osmarender)
Post GIS
Import
scripts
Mod_tile
cache
osm 2
pgsq 1
TRAPI
XAPI
Etcetera
API 0.6
Mapnik renderer
(til.osm.org)
Planet dump,
planet diffs
Post greSQL
backend
Osmosis
Etcetera
FIGURE 14.1 OpenStreetMap component overview, downloaded from http://wiki.openstreetmap.org/wiki/
Component_overview.
movements or uses of smart transit passes constitute data. Mobile devices may be tracked from base
stations, but as they also acquire GPS, they can themselves record user positions. Android develop-
ers of course can benefit from open-source software and application build support systems, but these
uses are not strongly connected with most GC. Exceptions include the use of sensor networks and
animal tracking, to which we will return below.
Another is the application programming interface in OpenStreetMap, which supports data input
from volunteer contributors, rather than the elaborate visualisation and search interfaces provided by
leading web, navigation and mobile geospatial applications. Figure 14.1 shows the OpenStreetMap
component overview, which is not atypical in its complexity. Without the availability of the compo-
nents developed outside the OpenStreetMap community, it would have been extremely hard to have
achieved the progress we can all see and benefit from in the rapid updating of street maps, espe-
cially in places without adequate mapping agencies. The 2011 State of the Map conference, focused
on OpenStreetMap, and the 2011 FOSS4G OSGeo conference were held consecutively in Denver,
Colorado, by design, as many developers participate in both meetings.
14.2.3 d ePendency c hallengeS
As already noted, developers wishing to integrate software components in stacks must pay careful
attention to the versioning of the components and to the impacts of upstream changes on down-
stream components. The terms upstream and downstream refer to the ordering of the components,
with data flowing from upstream to downstream components. If the specification of an upstream
component changes, those following it will need to be modified. If the changes are forced by real
bugs being fixed, or security holes being blocked, downstream components must react in appropri-
ate ways. However, some changes occur for other reasons, such as code cleaning, reimplementa-
tion or the resolution of licence issues in otherwise functioning code. In most cases, upstream
developers then attempt to reduce changes in their interfaces with downstream components to an
unavoidable minimum.
Open-source projects are typically most constrained with respect to developer time for main-
tenance, including the revision of functioning code to accommodate upstream changes that may
not improve downstream performance. This has been seen often enough when GUI toolkits are
Search WWH ::




Custom Search