[OSM-dev] Further Database optimisation and data size
nick at nickhill.co.uk
Fri Apr 21 10:42:10 BST 2006
Joerg Ostertag wrote:
> I really don't want to increase the complexity of the API by having to deal
> with integers for values which are floats in reality .
There is nothing inherently less real expressing co-ordinates in whole
units of 100 nanodegrees than expressing co-ordinates in fractional
degrees. Degrees are arbitrary.
This is more to do with a person's own prejudice of being more familiar
with whole units of degrees. There is nothing wrong with that.
However, as an engineer, if working with units of 100 nanodegres results
in an overall better system (perhaps with a factor of 2 or 3 improvement
in terms of size and speed) it would seem natural to use such a system.
Working with Radians may be even better, as you can usually then
discount Pi from calculations. However, I concede that Radians would be
a substantial conceptual leap to take.
Referring to Imi's issue about floating point sin/pi calculations. I
have found that the discipline enforced when I work with whole numbers
gives rise to interesting optimisation ideas and shortcuts. However, it
does take a little longer to implement, and without good commenting,
harder to understand. Whole numbers are and probably will always require
much less processing than floating points. Given how processing
intensive OSM promises to be, such efficiencies will be important.
Wikipedia has had to spend very large sums of money for database and API
processing. A wikipedia article look-up may only require 2-6 chunks of
data to pass into and through the API. A single OSM view may, by
comparison, require retrieval, integration and display of thousands of
discrete chunks of data. In the medium term, efficiency will become a
More information about the dev