Fly around the World

Background to submission guidelines

In principle we're offering two interfaces:

  1. Online-interface to the DB - at best you have the ability to talk the PostgreSQL wire protocol (using 'libpq') and do some SQL,
  2. Shapefile-import into a predefined bounding-box.

Both methods have their pros and their cons. The first one makes the job of the DB maintainer very easy because his only duty is to ensure, that the thing is up and running. The respective client application has the ability to modify _existing_ objects by adding or moving polygon nodes. Some further explanations are here:

Chapter 4. Using PostGIS

As an example an entry in the database looks like this - this is part of a single lake:

Query:

landcover=> select wkb_geometry from lakes_lake where ogc_fid = 10000;

Result:

 002000000300007FFF000000010000000C4048F838600000014050CC45A00000004048F[...]

 

For better readability PostGIS allows a numeric representation of the data. Query:

landcover=> select asText(wkb_geometry) from lakes_lake where ogc_fid = 10000;

Result:

POLYGON((49.9392204284668 67.1917495727539,49.9442481994629 67.1901702880859,[...]))

Currently we have one so called "layer" in the database for all "topographical objects" of one sort. Analogous to the current TerraGear landcover scheme there is one layer that contains all polygons which are attributed to the "lakes/lake" type, one for "landcover/evergreenbroadcover" polygons, one that contains all polylines of the "rivers/stream" type, one that contains all points of the "towns/town" type.
Now if somebody wants to drop a river into a place where currently no river exists, then he can simply stuff the respective polyline into a shapefile and we'll add that to the respective layer. This is an easy task.

If someone wants to modify an existing river, then he has to tell us about the layer and the area within he has made changes. We expect a so called "bounding box" and we are going to make a selection based on this bounding box. Every object that lies entirely in the bounding box or somehow crosses the border of the bounding box will be part of the selection. The bounding box can be a polygon of almost every shape that somehow makes sense.
We now will cut a hole by removing everything from the respective layer that lies in the selection of the bounding box. The user-supplied shapefile containing modified data now has to contain _all_ data that is affected by the bounding box selection. This means: If you want to modify one large river and the bounding box selection that is given to us affects some smaller river in the neighbourhood as well, that was _not_ modified by the user, then we expect the user to give us a shapefile that contains the modified large river _plus_ the unmodified smaller one(s). So please be careful about the bounding box you define in order not to lose anything.

We'll convert shapefile submissions into database SQL scripts which then are applied to the database. This easily enables us to track the changes in case we are required to answer copyright-related questions and eventually back out certain changes if copyright issues urge us to do so.
If someone is sure about his PostGIS-related skills we'd be happy to recieve SQL scripts instead of shapefiles. This _could_ be a way for FGSD to tightly interact with the database even in cases where a direct online connection is impossible. When the times has come I'm convinced Frederic will tell us what we're going to expect.

Before going into production with new data (currently the database contains the stock VMAP0 selection that was previously used) we will alter the database layout to ease some jobs. We are going to put slightly different object types into one layer and allow the user to add attributes to their respective objects. For example you can expect us to put all polygon-based landcover data into one layer and attach the respective object type to each polygon. Shapefiles are enabled to carry such attributes. Adding to that we'll stuff all types of rivers into one layer and let the user/contributor attach certain attributes to their rivers such as width and colour.
Thomas Foerster did a nice example where he attached the width to every node of the polyline thus creating a _very_ realistic display of rivers.