[OSM-dev] Further Database optimisation and data size

[Nick Hill]

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 
key word.