During rebuild, gosmore only mmaps the wayType data which is roughly 1GB. During one stage, it iterates through the node data and update the wayTypes they point to so that bounding boxes can be computed.
Nothing stops you from adding code to that stage that will test if each node falls inside a polygon (e.g. place) and then modify that way. I don't believe that writing software for adjusting speeds for built-up places is worth all the effort. Reasons : * Place boundaries can't be surveyed by OSM members. Can only be guessed from aerial photos or imported from other sources. * Applies to few countries. * This extra info will seldom make a substantial difference in the route proposed by the routing system, because all the roads will typically go through the built up place. Other efforts, like adjusting for sharp turns, traffic signals, number of junctions etc. are all more important. On Sun, Oct 19, 2008 at 1:49 AM, Sascha Silbe < [EMAIL PROTECTED]> wrote: > On Sun, Oct 19, 2008 at 01:05:02AM +0200, Lambertus wrote: > > Does gosmore check place=... areas to determine whether a way is inside a >>> built-up area to adjust the speed accordingly? In that case I'll have to dig >>> into the Gosmore source again to see how Nic got it this fast. :) >>> >> No, afaik Gosmore does not do that. >> > OK. That was what I asked about - those checks are quite expensive, so I'm > looking for ideas how to speed them up. > > Gosmore doesn't use much ram while parsing the planet data so I'm pretty >> sure it will scale linear whatever the amount of data. >> > The amount of RAM used for temporary data is quite low, but the whole > database is mmap()ed into memory. I thought Gosmore does the same?! > > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iQEVAwUBSPp2ELpz82VMF3DaAQIFlQf+LzezW6I51PbBoKwSzFVYv7ZdByjtBuDk > U8J0Si6j2tUCiQ7kMykeMjXPcMTN8mqib5prU0NHqoJHM02s0EP1/jV9OHfjguTo > JQnEzmLplLe7v22C7ekP7EBjb++HpTZ3pRXB3mjMsMYi30Vqy7e3EwKe864Vm3PN > 6eq2Pw/hoCVn6zB1C0wu5+WZL7UqB18NPphiZkM280Sg9t5phtcUjNUMKj9+HLC8 > VO44MMUkjeJsbxlPgqD9O2mi0PCCeRRksb16OJcNjULXYRt7wO1iSQbHgJRIt35q > 73hpK3cBPt5tCD4Ke2+HS+d/HozjxMOJunLA8yta6dEhZrezrj9x5Q== > =I4Dh > -----END PGP SIGNATURE----- > > _______________________________________________ > Routing mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/routing > >
_______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
