Malcolm Herring wrote: > I don't like this proposal because the structure is made up of nodes > rather than ways. This will make for extremely tedious construction as > well as create much more data. Also it is too different from the > existing multipolygon method of creating generic area geometries. This > proposed structure would mean that all the tools & consumer apps would > face big re-writes.
Sadly, there is no way to not rewrite tools and apps after area type introduction, even if we just rename multipolygons to areas and be done with it. For example, how do you tell closed way from an area in an editor? On the other hand, tools like osm2pgsql and osmium will not only become quicker and simplier, because they won't have to make assuptions on what is area and what isn't, but they will screen most data consumers (e.g. mapnik) from this change. As for creating much more data, it is simply untrue. The proposal would replace ways+relation for most cases with a simple area object on same nodes, and for complex cases it will function similar to a multipolygon relation. Construction would be easier, since we would have knowledge of inner and outer sides, even when we have only some of nodes or ways. > There is nothing wrong with multipolygons except for the fact that they > are relations. This leads to chaos when multiple area geometries need to > be associated but do not form a logical single geometric entity. If an > area data type were defined that incorporates the existing multipolygon > structure, then all existing code that parse and create multipolygon > relations would not need re-writing. That was the basis for my thoughts: I started with an idea to just make areas a special kind of relation, basically rename multipolygons. But it would imply converting all regular polygons (there are 120 million just building outlines, compared to 7 million multipolygons in total) to 2 objects: way + area. That would be bad. So I solved the problem for other two types of areas: small polygons (just added node references) and coastlines (reversed way references). Multipolygon code would still be used for assembling areas, but it would be unnecessary in most cases, since in most cases of "polygon with a hole" a simple, node-based area would be enough. > My other wish is that disjunct outers be dis-allowed. Where multiple > complete areas need to be associated, then this is the proper use of > relations. Why? How would you draw an administrative district with an exclave? IZ _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
