In the last days I worked on configuration capabilities of the Lalm. Configuration is necessary for several reasons.
Technical reasons include different database backends, different java setups, different describers and so on. Some of them are planned, others are already realized. Let’s dive a little bit into the available options.
Options for Data Sources
Initially I didn’t think about supporting different data sources, but there’s one big problem with OSM data: it’s a really big bunch of bits and bytes. Even importing the database takes many hours and needs lots of processing power on the server – once initially and then to keep up to date.
While I didn’t care about the update process, yet, I have to get a server where I can run the development snapshot of the Look-and-Listen-Map. Thanks to Wikimedia (Deutschland) I’m able to run it on the toolserver, but there’s not enough spare capacity to use „my own“ dedicated osm database. I have to share the Mapnik scheme database used by the wikipedia map projects for rendering. These databases contain everything I need – but sometimes in a horrible schema, so that queries might take incredibly long. For my local test setup here, a pretty common page request to navigate one way takes several minutes as it needs one full sequential table scan over the ways table for every node of the way currently. Of course the database schema could be changed to speed up that, but that would break the other projects on toolserver, so I’m happy at least the storage behind the postgresql-server at the toolserver is fast enough.
For local testing a separate set of tables using the snapshot scheme created by osmosis is possible to use, too.
Which one to use is possible to configure in the file lalm.properties, including table prefixes, authorization data and – of course – the DatabaseService-Implementation to use. Here currently MapnikDatabaseAPI (using the mapnik hstore schema), SnapshotDatabaseAPI (for the snapshot schema) and last but not least OverpassAPI, using the Overpass API as a web service combined with a local memory cache are implemented (not finished, yet).
Options for Describers
How to describe the geodata as text? I have a lot of ideas, and I think it should be possible to change that according to the users needs, the lalm providers decisions or for testing purposes.
Describers are Tapestry components and it’s possible to choose different implementations by configuring them.
Debugging options: it should be possible to show or hide debugging data, run in productionMode (or not) and more