Re: [OSM-dev] GSoC: POI search
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
Re: [OSM-dev] GSoC: POI search
Mitja, Thank you for proposing your project for GSoC. 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). I think that your proposal is to develop a separate API that specialises in Points of Interest in order to provide a faster response. I can see that one big benefit of this is that the amount of data in the database will be reduced, as you will be able to drop any un-tagged nodes (again I am not sure of the proportion, but I suspect it will be quite a large reduction). 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. 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? 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. 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. 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?). Regards Graham. On 20 March 2010 14:17, Mitja Kleider mi...@kleider.name wrote: Hi, I would like to introduce my idea for GSoC. We already have many POI details in the database (opening hours, website/wikipedia article, phone, ...) that are not very accessible to the end user. There is also a growing demand for an easy way to display icons for rare tag combinations, like new OSM for the blind tags, fuel stations for electric cars, pubs for smokers, and so on. My experience is also that mappers are highly motivated if they can view their special details. I was inspired by the demo introduced at SOTM09 [1] and the OpenStreetBrowser [2] and tried to build a map with clickable POI overlays (no tiles, but OpenLayers markers) that would provide the tagged details as human readable text when the user clicks an icon. This is in a proof of concept state and turned out to be useful (i.e., for the OpenLinkMap [3]). If you want to support any possible tag combination with reasonable performance and also be up to date (at least daily updates, aiming for real-time) in my opinion none of the existing API solutions is suitable. This is where the project idea [4] comes into play: MonetDB seems to have the right capabilities and can be extended with spatially ranked text search features. The project could provide the API (including text search) and usage examples, i.e. an OpenLayers example to build a map for end users (and mappers) making the existing data more accessible in terms of search and presentation. I would like to hear your comments and suggestions. What do you think? [1]http://xapidemo.openstreet.nl/ [2]http://www.openstreetbrowser.org/ [3]http://olm.openstreetmap.de/ [4] http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2010#Point_of_Interest_search_and_presentation Regards Mitja ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Dr. Graham Jones Hartlepool, UK email: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC: POI search
Hi, I would like to introduce my idea for GSoC. We already have many POI details in the database (opening hours, website/wikipedia article, phone, ...) that are not very accessible to the end user. There is also a growing demand for an easy way to display icons for rare tag combinations, like new OSM for the blind tags, fuel stations for electric cars, pubs for smokers, and so on. My experience is also that mappers are highly motivated if they can view their special details. I was inspired by the demo introduced at SOTM09 [1] and the OpenStreetBrowser [2] and tried to build a map with clickable POI overlays (no tiles, but OpenLayers markers) that would provide the tagged details as human readable text when the user clicks an icon. This is in a proof of concept state and turned out to be useful (i.e., for the OpenLinkMap [3]). If you want to support any possible tag combination with reasonable performance and also be up to date (at least daily updates, aiming for real-time) in my opinion none of the existing API solutions is suitable. This is where the project idea [4] comes into play: MonetDB seems to have the right capabilities and can be extended with spatially ranked text search features. The project could provide the API (including text search) and usage examples, i.e. an OpenLayers example to build a map for end users (and mappers) making the existing data more accessible in terms of search and presentation. I would like to hear your comments and suggestions. What do you think? [1]http://xapidemo.openstreet.nl/ [2]http://www.openstreetbrowser.org/ [3]http://olm.openstreetmap.de/ [4]http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2010#Point_of_Interest_search_and_presentation Regards Mitja ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
