[TuringTest]

> Both have been hugely successful, and both have the same pile of downsides.

Exactly. And the solution should not be to throw away spreadsheets completely and turn them into relational databases, but to create new tools to alleviate the downsides and reduce their impact (possible by exporting the spreadsheet information into a relational database, but without taking away the user's option to continue working with it.)

[Doctor_Fegg]

No one is suggesting throwing away OSM's data model completely. The current suggestion is basically "maybe we should think about a point release to properly address an ugly hack we invented in 2007".

[pramsey]

Right? The emotion of the response seems completely out of scale to the ambition of the reform proposed. "Maybe polygons?"

[sp8962]

Not really even that.

What is currently on the table is simply a way to cleanly differentiate between closed ways that are polygons and actual closed ways. Example roundabout enclosing a park. The problem is that right now this relies on determining this from the tagging. This could well be implemented as a flag on the existing way type and not as an actual new datatype.

There is at this stage no intention to revamp the way how we model areas that are more complex than the single polygons from above, that is with multi-polygon relations.

The more controversial topic is giving OSM way objects partially or fully their own geometry.

The former would have for all practical purposes no noticeable contributor effect outside of geometry changes always creating new versions of ways, contrary to the current behaviour which can be somewhat puzzling for newbies.

The later would be quite drastic, but would provide more benefits for at least some kinds of processing, for others not, as then topology would have to be inferred.

In any case the 90% of the discussion on this topic fretting about tagging is completely misplaced as literally nobody is even remotely considering changing that.

[danShumway]

> but without taking away the user's option to continue working with it

You keep bringing this up, but I still don't understand what about this change would prevent people from working with intermediary/local formats, or why tools working with intermediary/local formats would be harder than building validators at every step of the submission process?

How is this change taking away anybody's ability to do anything with local data on their device? And if the point is that they should be able to submit that data, then validators will be just as much of a problem for them as a file format will be.

Lots of programs work with their own temp formats locally that are specific to their needs. I mean, you don't need to even make a new one, if you like the existing format so much, save temp changes to it, and publish finished changes to the new format.

What am I missing here, why is any of this a problem?