[OSM-dev] [Maps-l] History API Server

80n 80n80n at gmail.com
Wed Dec 9 20:52:00 GMT 2009


Something like this is well within the capabilities of XAPI and I had
already downloaded a copy of the full history and was just starting to think
about what should be done with it.

80n

On Wed, Dec 9, 2009 at 8:27 PM, Peter Körner <osm-lists at mazdermind.de>wrote:

> Hi
>
> Now that we have a full Histoy Planet Dump (Thank you Lars, Matt and all
> who helped with that!), we can again start talking about a History
> Server and a History Api.
>
> What I'm thinking of is an extension of the 0.6 API, that includes calls
> like this:
>
> GET /api/0.6/[way|relation]/#id/#version/full
> GET /api/0.6/node/#id/#version/ways
> GET /api/0.6/node/#id/ways?time=#time
> GET /api/0.6/[node|way|relation]/#id?time=#time
> GET /api/0.6/[node|way|relation]/#id/full?time=#time
> GET /api/0.6/map?time=#time
>
> and maybe others like
>   GET /api/0.6/[nodes|ways|relations]/#id1,#id2,...,#idN
>   GET /api/0.6/[nodes|ways|relations]/#id1/#ver1/.../#idN/#verN
>
> This would make it easy for a client to fetch the state of a city at any
> given time. It would also enable a client to get the complete geometry
> of a way or a relation in any given version or at any given time.
>
> This would make it easy to create animations like the "year of edits"
> for a town or maybe also a country on demand and with real mapnik styles.
>
> The version-based calls (especially GET /api/0.6/node/#id/#version/ways)
> would make it possible to visualize the changes made in a given changeset:
>   if a way was changed, it is contained with each node and each node's
>   version, so a client can fetch all those nodes from api and re-build
>   the way's exact geometry before and after the change
>
>   if a node is changed, the ways depending on it are not included in the
>   changeset and with the current api it's not possible to fetch the
>   geometry of the ways depending on this node as they were before the
>   change
>
> I know that there are implications on how versions are counted (one
> version of a way could stand for more than one geometry, as its nodes
> could have been moved without the version of the way being incremented)
> but they can be solved by simply defining sth. like
>   GET /api/0.6/way/#id/#version/full returns the full geometry of the
>   way #id, as it was when version #version of was created.
>
> Still all possible geometries of the way could be accessed via the time
> predicates.
>
> When taking this idea further, a historic api could even implement
> "minor versions" on ways/relations, thus enabling a client to address
> any change in the geometry of a way (should read: any change on one of
> it's nodes) explicitly.
>
> Such an api could create heavy load on the underlying database, what is
> AFAIR the main reason why such calls aren't implemented in the current
> api. But unlike on the main api, queries to an such a history api don't
> need to be answered in miliseconds. When a /map query for a city on 1st
> jan 2007 takes 15 minutes, well that's ok. I's still faster than to
> download the corresponding planet dump, import int into postgis and
> catch up with the diffs, so what?
>
> My questions to you are
>  - do you think such an server/service/api would be of use for a greater
>    audience?
>  - who would be willing to develop, and who would be able to host such a
>    service?
>  - do you think these calls can be implemented without having 10 queries
>    crash the database?
>
> I think ptolemy, the new-new Wikimedia Toolserver has enough space (2336
> GB of raw HD space -- physical, bot logical!) and enough power to run
> such an api -- that's why I CCed Maps-L -- maybe Ævar can say if he
> thinks this would be possible.
>
> Thank you for reading and commenting,
> Peter
>
> _______________________________________________
> Maps-l mailing list
> Maps-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/maps-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20091209/33cf37d3/attachment.html>


More information about the dev mailing list