On this topic, note that there are now full history daily diffs available that can be used to keep such a database up to date.<br><a href="http://planet.openstreetmap.org/history/">http://planet.openstreetmap.org/history/</a><br>
<br>When up to date information is not critical, they're a little easier to deal with than the <a href="http://planet.openstreetmap.org/minute-replicate/">http://planet.openstreetmap.org/minute-replicate/</a> diffs because they are exactly time aligned, and in daily chunks.<br>
<br>In theory it is possible to replay these history diffs sequentially from day one to the current time and end up with a hopefully similar result to the full history dump.<br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 7:52 AM, 80n <span dir="ltr"><<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>80n<br><br><div class="gmail_quote"><div><div></div><div class="h5">
On Wed, Dec 9, 2009 at 8:27 PM, Peter Körner <span dir="ltr"><<a href="mailto:osm-lists@mazdermind.de" target="_blank">osm-lists@mazdermind.de</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">
Hi<br>
<br>
Now that we have a full Histoy Planet Dump (Thank you Lars, Matt and all<br>
who helped with that!), we can again start talking about a History<br>
Server and a History Api.<br>
<br>
What I'm thinking of is an extension of the 0.6 API, that includes calls<br>
like this:<br>
<br>
GET /api/0.6/[way|relation]/#id/#version/full<br>
GET /api/0.6/node/#id/#version/ways<br>
GET /api/0.6/node/#id/ways?time=#time<br>
GET /api/0.6/[node|way|relation]/#id?time=#time<br>
GET /api/0.6/[node|way|relation]/#id/full?time=#time<br>
GET /api/0.6/map?time=#time<br>
<br>
and maybe others like<br>
GET /api/0.6/[nodes|ways|relations]/#id1,#id2,...,#idN<br>
GET /api/0.6/[nodes|ways|relations]/#id1/#ver1/.../#idN/#verN<br>
<br>
This would make it easy for a client to fetch the state of a city at any<br>
given time. It would also enable a client to get the complete geometry<br>
of a way or a relation in any given version or at any given time.<br>
<br>
This would make it easy to create animations like the "year of edits"<br>
for a town or maybe also a country on demand and with real mapnik styles.<br>
<br>
The version-based calls (especially GET /api/0.6/node/#id/#version/ways)<br>
would make it possible to visualize the changes made in a given changeset:<br>
if a way was changed, it is contained with each node and each node's<br>
version, so a client can fetch all those nodes from api and re-build<br>
the way's exact geometry before and after the change<br>
<br>
if a node is changed, the ways depending on it are not included in the<br>
changeset and with the current api it's not possible to fetch the<br>
geometry of the ways depending on this node as they were before the<br>
change<br>
<br>
I know that there are implications on how versions are counted (one<br>
version of a way could stand for more than one geometry, as its nodes<br>
could have been moved without the version of the way being incremented)<br>
but they can be solved by simply defining sth. like<br>
GET /api/0.6/way/#id/#version/full returns the full geometry of the<br>
way #id, as it was when version #version of was created.<br>
<br>
Still all possible geometries of the way could be accessed via the time<br>
predicates.<br>
<br>
When taking this idea further, a historic api could even implement<br>
"minor versions" on ways/relations, thus enabling a client to address<br>
any change in the geometry of a way (should read: any change on one of<br>
it's nodes) explicitly.<br>
<br>
Such an api could create heavy load on the underlying database, what is<br>
AFAIR the main reason why such calls aren't implemented in the current<br>
api. But unlike on the main api, queries to an such a history api don't<br>
need to be answered in miliseconds. When a /map query for a city on 1st<br>
jan 2007 takes 15 minutes, well that's ok. I's still faster than to<br>
download the corresponding planet dump, import int into postgis and<br>
catch up with the diffs, so what?<br>
<br>
My questions to you are<br>
- do you think such an server/service/api would be of use for a greater<br>
audience?<br>
- who would be willing to develop, and who would be able to host such a<br>
service?<br>
- do you think these calls can be implemented without having 10 queries<br>
crash the database?<br>
<br>
I think ptolemy, the new-new Wikimedia Toolserver has enough space (2336<br>
GB of raw HD space -- physical, bot logical!) and enough power to run<br>
such an api -- that's why I CCed Maps-L -- maybe Ævar can say if he<br>
thinks this would be possible.<br>
<br>
Thank you for reading and commenting,<br>
Peter<br>
<br>
_______________________________________________<br></div></div>
Maps-l mailing list<br>
<a href="mailto:Maps-l@lists.wikimedia.org" target="_blank">Maps-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/maps-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/maps-l</a><br>
</blockquote></div><br>
<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
<br></blockquote></div><br>