[OSM-dev] Further Database optimisation and data size
immanuel.scholz at gmx.de
Fri Apr 21 07:54:27 BST 2006
> Given the huge processing shortcuts which are made by avoiding
> floating points, and the exemplary 2-3 fold speed improvement for
> select query speed, we should consider avoiding any floating point
> representation throughout the API and use only scaled integers.
Only because MySQL can operate much faster on integer than on floating
doesn't mean, conversations of a couple of numbers have any remarkable
impact in the server.
My opinion is: Having some crude special integer definition in an API is
not good. Having just some floating values is simpler to understand.
> We can probably avoid floating point numbers completely without
> noticeably increasing programmatic complexity, except for the initial
> GPX import.
As long as you don't do anything except + and * with other integers..
Unfortunately, applications usually do stuff like sin(), tanh() or /PI
And I think the complexity increase is much worse than "without
noticeably". Just having floating points is much more natural to deal
with in an application than with "integers of ten million per degree".
If you can make the server behave faster by storing the values as
integers, no problem.
More information about the dev