[Openstreetmap-dev] again issues with server rounding

Erik Johansson erjohan at gmail.com
Fri Feb 10 15:21:01 GMT 2006


On 2/10/06, Immanuel Scholz <immanuel.scholz at gmx.de> wrote:
> I have a problem with the thing, that the server does not save the full
> double precision of a coordinate but round it to some "DECIMAL(2,6)".
[...]
> will the algorithm be the same when OSM switch to postgresql?

Could you give test cases for these rounding errors, and put it in a
ticket? If the rounding is a problem then documenting the magnitude of
it is needed. Then, perhaps we can solve that problem, it's very
specific so it's not really something Steve or Mikel have to do. You,
me or whoever can do that.


But IMHO your problem is not with rounding algorithms but it feels
more like a versioning issue, this will happen whether it's the server
which "moves" the nodes or another user. E.g. Lets try insert some
more things in your list:

> My concrete problem:
> - User enters a new node in JOSM
> - save the data to disk
> - upload the data.
> Now the node location is rounded in the server.
> - User restart JOSM without saving
* Someone edits the nodes the offline user uploaded.
> - reload the data from disk.
* offline user changes data
> (Without server communication, JOSM must think that the node was not
> uploaded before.)
> - User upload the node again.

How do you solve these extra points?


> Solutions:
> - Ignore the issue. Improve the offline clients to merge double nodes
> later. This could lead to many senseless histories for created and deleted
> nodes.

This is a good feature to develop, it would help resolving versioning
issues. But it's not very fun to do and you can't get it perfect. But
it sure would be a good idea to force your users to have a copy of OSM
data before they edit, and then check for changes each time you upload
to the server. Actually that should be an requirement.


> - Exact specification of the rounding procedure enables offline clients to
> compare nodes by their lat/lon location and warn users about already
> specified nodes.

What if the server changes the rounding algorithm? As you said what
will happen when we switch to PostgreSQL


> - A server function to round input values and return the rounded one. This
> seems inperformant to me and I suspect it can not be implemented efficient
> in the server.

This would be the only long term solution, but is it really the
problem? It really seem like a versioning problem to me.

--
/Erik




More information about the dev mailing list