Browse files

Update the project's roadmap.

  • Loading branch information...
1 parent 5e5c38e commit d358b98384e50ee670644ef586dfdd47597e4e54 @jkoshy jkoshy committed Jun 20, 2011
Showing with 22 additions and 15 deletions.
  1. +22 −15 doc/
37 doc/
@@ -1,35 +1,42 @@
## About
-This page lists the planned evolution of the server.
+This page lists the proposed evolution of the server.
-## Version 0.5
+## Current Status
-* The code is functional, but need not be fast.
+* The code is functional: [planet dumps][osmplanet] can be ingested and their data retrieved using the [API][osmapi].
+* Serving data via the API is quite fast (see [ProvisioningInformation][]), but ingesting a full planet is slow.
* Modules have unit tests.
-* External documentation is upto-date.
-* [Planet dumps][osmplanet] may be ingested and their data retrieved
- using the [API][osmapi].
-* Supported data store: [Membase][].
+* External documentation (i.e., the `doc/` directory) is upto-date.
+* The supported data store is: [Membase][].
-## Version 0.7
+## Future work
-* Performance bottlenecks have been identified and addressed.
-* Full [Planet dumps][fullosmplanet] dumps are supported, along with
- retrieval of history and previous versions of elements (tickets [#14][issue14] and [#4][issue4]).
-* The "front-end" is fully asynchronous ([#2][issue2]).
-* System tests have been added.
-* Wiki and internal documentation is complete and upto-date.
-* Supported data stores: [Membase][] and possibly [Riak][] ([#6][issue6]).
+* We need to support 'full' [Planet dumps][fullosmplanet] dumps, along with
+ retrieval of changesets, element history and prior versions of elements (tickets [#4][issue4] and [#14][issue14]).
+* Performance improvements that have been identified so far could be addressed:
+ * The `/map` API call could be further speeded up by grouping nodes and ways based on geographical proximity.
+ * The ingestion tool needs to be speeded up ([#13][issue13]) and possibly rewritten in a non-interpreted language.
+* Storage efficiency can be improved:
+ * A separate string table for frequently used strings could cut down storage needs.
+ * Slabs could be coded more efficiently ([#9][issue9]).
+* The "front-end" needs to be made fully asynchronous ([#2][issue2]).
+* System tests that verify end-to-end integrity of the ingestion process are needed.
+* More supported data stores: possibly [Riak][] ([#6][issue6]) for a scalable backend, or perhaps [BerkeleyDB][] for a single machine configuration.
<!-- References -->
+ [BerkeleyDB]: "Berkeley DB"
[fullosmplanet]: "Full OSM Planet"
+ [issue9]:
+ [issue13]:
[membase]: "Membase"
[osmapi]: "OSM v0.6 API"
[osmplanet]: "OSM Planet"
+ [ProvisioningInformation]:
[riak]: "Riak"
[wiki]: "Wiki"

0 comments on commit d358b98

Please sign in to comment.