Re: [OSM-dev] How did Mapquest do the localized rendering schemes?
On 28 December 2011 07:48, Toby Murray toby.mur...@gmail.com wrote: On Tue, Dec 27, 2011 at 12:38 PM, Stephan Knauss o...@stephans-server.de Thanks for the pointer to the styles. Any Idea how they determine which style to use for which geometry? I did not see anything that looks like a way to select the one style or the other based on the geographic location. Can you do the location check while rendering or would it be a preprocessing step during import? I did not see an additional region column so no idea how the selection was done. I thought this was the case but after a little searching, I came up with proof. MapQuest added this feature to Mapnik: http://lists.openstreetmap.org/pipermail/talk-us/2010-November/004820.html So it is apparently determined at render time. No clue how though :) I don't know either but here is how I'd try to do this: at high zoom levels where it's unlikely that a single tile has to use multiple stylesheets you could run renderd with each stylesheet as a separate layer and select the right layer at mod_tile level, I think this could be really fast. At low zoom levels you could preprocess stylesheets to make a single big stylesheet with the sql queries having the polygon checks added to them. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] osm2pgsql get_way not exists
Hello, I'm working on keeping planet database up-to-date. Not successful yet, it tends to lag behind due to IO speed/configuration (on raid-5 with sata 10K disks - it should work, right?), 12-hour update takes 11-14 hours for me. Anyway, the current question is that osm2pgsql (with verbose output) gives in relation processing following: processing relation (1) at 0.03/sget_way failed: ERROR: prepared statement get_way does not exist (7) Arguments were: -2945, Error occurred, cleaning up get_way failed: ERROR: prepared statement get_way does not exist (7) Arguments were: -3192, Error occurred, cleaning up get_way failed: ERROR: prepared statement get_way does not exist (7) Arguments were: -3325, Error occurred, cleaning up Is this something to worry about, or just a way in a relation is missing? -- Jaak ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql get_way not exists
Hi, On 01/-10/-28163 08:59 PM, Jaak Laineste wrote: Hello, I'm working on keeping planet database up-to-date. Not successful yet, it tends to lag behind due to IO speed/configuration (on raid-5 with sata 10K disks - it should work, right?), 12-hour update takes 11-14 hours for me. Anyway, the current question is that osm2pgsql (with verbose output) gives in relation processing following: processing relation (1) at 0.03/sget_way failed: ERROR: prepared statement get_way does not exist From when is your version of osm2pgsql? A few weeks ago, I noticed that this was happening if you are using the -e tile expiry option of osm2pgsql. I thought I had fixed this issue with my commit from the 18th of December. What is the command-line option you are using? (7) Arguments were: -2945, Error occurred, cleaning up get_way failed: ERROR: prepared statement get_way does not exist (7) Arguments were: -3192, Error occurred, cleaning up get_way failed: ERROR: prepared statement get_way does not exist (7) Arguments were: -3325, Error occurred, cleaning up Is this something to worry about, or just a way in a relation is missing? Yes, this is an error during processing and will cause it not to work correctly. I think it doesn't corrupt the data, so the next time you call osm2pgsql and these errors don't occur, it should fix it self and clean up the db (left over pending ways). Kai ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[Potlatch-dev] Couple of new under-the-hood refinements
I've just committed two new features to P2 that should make it feel a lot snappier. First of all, when you pan to a new area, P2 only asks for the areas that aren't yet loaded, rather than the whole bbox. In other words, less data gets downloaded from the server. You can see that it's making multiple smaller requests because the display at the top right will read Loading data (3)... or similar. The Gnarly Algorithm to work out which requests were needed was put together (and subsequently refined) by Matt, and Tom helped me convert it from Ruby to AS3, so thanks both! This should help with the problem Andreas Hammershøj reported at http://lists.openstreetmap.org/pipermail/dev/2011-December/023945.html , though I'm also planning to add an option for a secondary read server (e.g. Overpass API) too. P2 currently flushes its internal data store once 3,000 ways have been loaded, but I'm planning to raise this limit once the quadtree branch (https://github.com/systemed/potlatch2/tree/quadtree) is ready. Secondly, P2 now uses native cursors (a Flash 10.2 improvement) for the custom pointers when drawing. These are much less jerky than the old-style Flash pointers. As ever, both of these will hopefully be deployed on osm.org soon, but if you're building your own P2 from the systemed repo, you can try them now. cheers Richard ___ Potlatch-dev mailing list potlatch-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
