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 <[email protected]>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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/maps-l >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
