Graham Jones wrote: > I think that you correctly identify that fast data access is essential > to have a good user experience for an interactive map. The > interactive map demonstrations that are currently available can feel a > bit sluggish (presumably because of XAPI response times, but I am not > sure).
Yes, usually the problem is either slow response times or too much data for the browser (or slow parsers). > I think that your proposal is to develop a separate API that > specialises in Points of Interest in order to provide a faster > response. Exactly. If the performance allows it, the complete planet data will also be available via Stefan's DBSlayer interface (XAPI-like or SQL queries). > The other potential improvement may be to avoid the use of specialised > geographical queries - if they are written in a very general way for > bounding polygons rather than simple rectangular bounding boxes, you > should be able to get better performance by doing it yourself. Probably I will write some kind of filter for polygons because bbox queries can be very fast using MonetDB's sideways cracking optimization. > What I do not understand is the benefit of using a different database > engine rather than PostgeSQL - is there a fundamental difference > between the one you propose and PostgreSQL that will make it faster? The most fundamental difference is the horizontal storage of the data. Several internal optimizations will also increase performance. > There are plenty of people on this list that know more about big > databases than me, so I hope they will comment on the potential > performance improvements that you are aiming to achieve. Maybe Stefan wants to comment this. If you are interested, there are scientific publications on performance, too. > The other thing that will need to be considered (not really necessary > for the GSoC application though) is what we will do with it once this > code is produced. If it works well I can see it being complementary > to XAPI, so we would need to think about a server (or servers) to run > it on. I am planning to rent a server at least for the beginning. If the service is used and popular, we can think about a long term solution. > From a GSoC point of view, to turn your idea into a proposal it would > be good to think about your timeline for development of the project - > how long to spend on design (database schema, performance set up > etc.), coding the API and testing performance (presumably with > comparisons to other data sources?). Yes, I still have to write a timeline. I find it rather difficult to estimate how long the single subprojects will take. For most data sources the performance difference should be obvious, the most interesting other source is probably the new osm2pgsql hstore solution (introduced on this list about a week ago). Regards, Mitja _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
