Am 02.01.2012 13:16, schrieb GerdP:
Hello Steve,
Steve Ratcliffe wrote
reg. "local information": I totally agree, but I found no better way, and it saved a lot of time on my system.
Personally I think that the way you have done it in the patch is much more natural than the existing way!
Ok, so than the patch is fine for me as well.
It is also possible to make the Coord structure smaller, since only 24 bits of the latitude and longitude fields are used, so both of the byte values could be located in the un-used 16 bits. Also there are only three values of highwayCount that matter: 0, 1, and more-than-one, so only two bits are required for that. I originally did it that way, but because of a mistake I gave up and went back to a separate field. This would save a bit of memory, but it is only worth doing if it results in a significant improvement in performance.
I also thought about this, but I wasn't sure how many bits are really used, and I got the feeling that such bitmask tricks are somehow outaged. I think I'll give it a try. I see two ways: 1) Keep the Coord class, but place these bits somewhere in the two interger fields 2) Use a long and map all fields in some mapping routines. This will be more complex, but could allow to use arrays (long[]) to store coords, and I guess this would mean> 50% memory saving for Coords.
Gerd
Thanks for trying the modification. The reason why I insisted a bit on how the reduce the memory footprint is the coastlinefile option. Using this option often requires a lot of memory because the complete coastlines of a big area must be loaded into mkgmap at once. Reducing the memory footprint of the Coord objects should reduce the required memory a lot in this case. But I don't think that the somehow cryptic changes are worthy. So I am fine with your original patch. WanMil