Matt Amos wrote: > we already do checks for data corruption, unfortunately they're > vulnerable to race conditions. 0.6 will fix that in 4 days ;-)
I can't wait ;) >>> If the API would start to do geometry inspection, then you'd have to add >>> loads of additional checks as well. For example for self-intersecting >>> areas or ways with length==0 even because first and last node, while >>> being different, have the same coordinates, and whatnot. >> Lets check for it :) (I'm serious) I was even surprised we seem to go on >> PostgreSQL but don't go PostGIS. > > i don't consider consecutive duplicate nodes to necessarily indicate > corrupt data. its up to the client to interpret the user's intent - > and if the user genuinely wanted consecutive duplicate nodes then > thats fine by me. True, but you are going to restrict k/v pairs ;) And that is a thing some users want too ;) [I don't think I ever needed it] > i can't think of any use for consecutive duplicate nodes, *yet*. there > might be people already using this for something, or we might find a > use for it in the future. for the moment, i consider this to be a > minor client UI bug which can be most easily fixed by the clients, not > by the server. I think it was you that was previously so smart on IRC about not overengineering your database types. This is exactly the same case, don't allow it unless someone actually has a use for it. Stefan _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
