-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Stabiszewski wrote: >> question: >> How would you go about zooming out? >> What would be the requirements to allow zooming out until >> you know where in a complete country or continent you are? > > I think it should be possible to define min and max zoom levels. > >> I found this to be quite a problem with interactive rendering. >> (One small part of the screen may show Berlin with thousands of roads.) > > You have to drop more and more minor roads while decreasing the zoom level. > We would have to test it. But don't think it is a good idea to use > pre-rendered tiles on mobile devices. > Software like TomTom renders its maps very nicely and this is my reference > here ;)
Adam's WhereAmI software for Series 60 phones that uses his binary protocol does quite a good job, but in general everything disappears one zoom level earlier than you want it to. It's still beta software, but it's looking very promising, and I haven't seen enough mention of it on this list. http://www.symbianos.org/projects/47 >> We would need a way to allow for level-of-details without storing things >> twice and without loading large numbers of tiles into memory just so we >> can get one way or node out of each one. >> >> How would you go about ways that span tiles? Ways and areas that >> intesect tiles without having any node inside the tile? > > Well, first you have to define tiles that are large enough. I'm thinking > about a tenth (0.1) of a degree in both directions atm. This would be > something like 11.1km in latitude direction and something like half of it in > longitude direction here in Europe. Why not project into mercator before splitting into tiles, like the slippy map does, then it will be the same distance in both directions. Otherwise you just have to do the projection in the end device. Also, I'd work in binary fractions rather than degrees. So 0000 is 0 degress, 1000 is 180 degrees, 0100 is 90 degrees, 1100 is -90 or 270 degrees etc. 32 bits gets you 0.9cm at the eqator, which is much more accurate than our maps. The tiles become defined by the higher order bits of the location, and they work out the same as the tiles used by slippy maps, and the maths becomes all unsigned integers that are easy to process on the ARM processors found in nearly all mobile devices. You just use unsigned ints, and the right thing happens at the date line and the meridian. > Ways that span over several tiles would get additional nodes at the borders. > The same for the ways, that don't have any nodes inside a tile. How about return 1 extra node for each way that is above or to the left of the tile, but not below or to the right. When you join the tiles together, you then get every node only once. Robert (Jamie) Munro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHXnhMz+aYVHdncI0RAjtLAKDxvS0dTu333H0Q0tZPgAwFhYjpWwCeOdby wEs8GoJSd0ofnOmXh80Daak= =iE08 -----END PGP SIGNATURE----- _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/routing
