Spatial Database

On further reflection and reading, I've decided that the core of this mapping tool must be a spatial database. A spatial database is basically a normal DBMS with geometric (spatial) datatypes and queries.

Using one of these databases, one can say things like 'give me all the segments of rivers that are within this county', 'tell me all the roads and rivers that intersect, and their point of intersection', and 'tell me all provinces adjacent to this one'. This is an exciting power, and one that I think that Iapetus would greatly benefit from.

Requirements for a spatial database system

These requirements were lifted from Spatial SQL: A Query and Presentation Language. It is such a nice list that I want to respect it in my system.

Max Egenhofer says that any spatial database system must fulfil the following requirements:

  1. The database must support geometric atoms like points, lines and regions.
  2. The query results must be displayed graphically, including graphical and visualization of non-graphical data.
  3. Multiple query results must be combinable into a single display. This allows traditional layering views.
  4. It is possible that query results should provide a rendering of context that was not explicitly part of the query. I have to think longer about this one before I decide whether I like it or not.
  5. The graphical query results should allow some form of interaction: such as selection of objects and regions for subsequent queries, etc.
  6. A dedicated language is required to control the rendering of the graphical results. This is related to my requirements to render different styles of maps from the same underlying data. I don't know if I will support a full language here, at least at first.
  7. A legend must be rendered, that explains things in the graphical presentation.
  8. Rendered objects must have labels, although rendering and placemement of labels is a hard problem in its own right.
  9. You should be able to zoom in, and queries must be restrictable to the currently zoomed view.

What do we do?

It is clear that some form of spatial database is a requirement. When I started reading the papers, it was clear to me that these people were solving the same problems as I, and that they'd been thinking about it longer.

Treating your data as a real database, with geometric and non-geometric attributes is wonderful, spatial joins and selections is vital, and the graphical display of results as a way of rendering different views of a map seems like an excellent idea.

Having the data in a database is also fun from the simulation-style stuff I want to run on top of this.

So do I write one or use an existing one? I should probably review the existing ones, see if any of them are any good.

The problem is I'm having trouble finding existing systems.

I will likely end up writing my own in the end anyway, because that's the sort of person I am.

Relationship with Java

Problems here. I mostly want to do my programming and scripting with Java, and this kindof blows it. Do I want to build up a Java data structure as a query? I think that in the end, some Java classes will render the results of the query, just because I have a hard time believing that some scripting language will give me the power I want and need. Although -- we may in fact want to customize the rendering quite a bit by the query.

Need to read more about it. Think about what's involved.