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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l

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?

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l

I think ptolemy, the new-new Wikimedia Toolserver has enough space (2336 GB of raw HD space -- physical, bot logical!)