Maps server setup tasks
This page is outdated, but if it was updated, it might still be useful. Please help by correcting, augmenting and revising the text into an up-to-date form. Note: See mw:Maps for the new Maps initiative. Also, see OpenStreetMap or Wikimaps for other efforts. |
Architecture and issues
edit
Database servereditAll the geospatial are stored in a PostgreSQL database running PostGIS extension. Problems to solve:
Rendering machineryeditRendering is a batch, background task, however in some architectures it is being done as a demand-based rendering (a tile that is not found is rendering on-demand). There are different renderers available: Mapnik currently rendering works in a combination of Apache mod_tile and As far as I can tell, Mapnik is by far the most scalable solution of the options. A single server can so far handle the full load of Openstreetmap fairly well. Osmarender in comparison needs 100s of clients to achieve the same. Mapnik is also so scalable because it renders things on the fly and thus does not need to render all those tiles that never get served before they are outdated again. If that is still not enough, there are patches that will allow renderd to become distributed across a lan further increasing scalability ( http://trac.openstreetmap.org/ticket/2005 ). It hasn't yet been merged into renderd, as it turned out that there was no need for it on OSM, but if wikipedia needs it, I can try and get it merged. --Apmon
Mapnik has its advantages, though once the "Mapnik" PostGIS database is setup, it's equally easy to render maps with other software such as Geoserver. Tile software options: Problems to solve:
Tile servingeditAs fast as possible. We probably need to measure here a lot there. Problems to solve:
Stylesheet managementeditA stylesheet gives instructions to the render. Advanced users will probably want to play with new stylesheets for the maps. Problems to solve:
Presentation to the useredit
|
(SourceOpenstreetmap:Develop) |
Ptolemy: production OSM database server
edit- master postgres instance
Server setup
edit- Partition the server
- setup separate partition for postgres db logs
- separate partition for database
Main OSM mirror database
edit- mirror production osm main database
- procedure (scripts) to regularly update our OSM database with new OSM changesets
Questions:
- what will be mirrored? (see [1])
- the current-tables
- the history-tables
- the raw-tables
- how could this be mirrored?
- only current can be imported from a planet.osm
- how often should this be updated?
- is access needed from Ortelius (tile server) or just from Cassini (toolserver)?
- will there be access from Cassini?
Mapnik database
edit- mapnik rendering database (with PostGIS support), done using osm2pgsql
- add and maintain multiple database views, for multilingual rendering
- procedure to update rendering database at regular interval, with new OSM changesets (with osmosis --read-change-interval)
- procedure for regular complete re-imports to solve inconsistencies introduced by the diff-import
XAPI-Instance
editOrtelius: production OSM tile server
edit- Partition the server
- The default.style would be functional, however it would be best to come up with a modified wikipedia style.
- our style also needs to incorporate the multiple database views, which support rendering tiles for each language.
- other styles need a different *.style file to allow rendering other features
- to do
Cassini (toolserver)
edit- php, perl & python with apache2 and on cli
- access to mysql & postgresql
- see jira for a list of packages needed for this
- a way for tools, that uses the osm-databases, to tell the users of the tools about the date/time of the last update and the date/time of the next planned update (similar to the globalsitenotice currently discussed on toolserver-l
- samples on how to use cassini / the dbs in various languages on the wiki
- list of project-ideas on wiki
- will Cassini have it's own PostGIS / OSM database or shared from Ptolemy?
Background info
editServer info: OpenStreetMap#Servers
- Required bits for our purposes:
- database
- mapnik rendering
- slippymap
- api (maybe? for toolserver usage)