|
Now that OpenGeo have a number of compelling packages and standards (eg. OpenLayers), it is useful to look at how they should ideally work together. The full white paper can be found on the OpenGeo website, but here is the introduction:
Putting maps on the web used to be very very difficult. It required
specialized software, and more important, specialized knowledge about
the kinds of data and processes used to create cartographic products.
The difficulties arose in the gap between the general public
understanding of "what is a map" and the geographic specialist
understanding of "what is a map".
Specialists understand a map to be made from a number of "layers",
topography, transportation, hydrography, land cover, human construction
and so on. The manipulation of these layers, and the building of
algorithms to analyze them is a field unto itself: "geographic information systems" or "GIS".
Because the specialists were the first market for web mapping tools,
their tools tended to embed the specialist understanding of what
comprised a good mapping solution: it should expose multiple layers,
the combinations of layers should be quite flexible for the end user,
and the end user should provide the data to make the map. Specialists
have access to lots of data, and they like to be able to turn their
layers on and off.
Members of the general public usually have very simple mapping
problems. They have one piece of data (a single "layer", in the
specialist terminology) and they want to see it on a map. Using the
specialist web mapping software to achieve their goals is tough,
because in order to see their data "on the map", they first have to
build "the map" – the collection of all the things that aren't their
data, but that provide the locational context within which their data
resides, generally called a "base map".
Building a "base map" involves finding all the relevant source data
(topography, roads, water, place names, etc) for the working area, and
establishing rendering rules (colors, line widths, labeling) for every
scale of display. Even for specialists, tracking down data and
establishing attractive multi-scale rendering rules can take several
days.
Google Maps, Microsoft Virtual Earth, and others, "solved" the
general public mapping problem by providing "the map" as a default
feature of their technology. They provided the "base map" – initially a
simple street map, later augmented with imagery – and the user was
expected to provide the rest. The user needed to know a little standard
web programming (JavaScript) but needed no special knowledge of GIS
data or techniques.
Once freed from the awkward initial step of building their own base
map, non-specialists rapidly colonized the online mapping space. As
they did, two things happened:
- the clients of the specialists saw the new consumer tools, and
wondered why the tools their specialists were providing were so clunky;
and,
- the non-specialist's demands for functionality soon outstripped what Google and Microsoft were willing to provide.
As time goes on, the demands for functionality on the part of
non-specialists are moving upwards and converging with the demands of
simplicity from organizations formerly served exclusively by specialist
GIS staff.
The full white paper can be found on the OpenGeo website.
 |
Twitter @geowebguru
Subscribe to this comment's feed