John, by a step of abstraction, you are touching one of the most complex and complicated issues related to the OSM source data. Namely, replications and overlaps as its consequences. Let us focus on area overlaps and especially on the kind you have mentioned – when the overlapping geometries, with high probability, represent the same object or parts of it. There are 100s of thousands of these in the source data. The consequences are large/huge number of errors/anomalies present in all today publicly available OSM based maps. I am not sure what JOSM (and other tools) can do with these errors but obviously very little because they are there. The issue has been up for discussion several times on this and other OSM forums. The majority of the replications are cased by bot/programmatic/mass edits. We have really large number of edits-over-edits-over... and, as you know, checking whether two almost overlapping geometries represent the same real-world object is far beyond a simple exercise and the power of a “script” solution. This many replications are the reason why we don’t like (even don’t want) extensive use of mass edits, quick fixes and similar options (exception, with DWG’s approval). There are several typical area overlapping classes/types. To be short, just in few words and links to illustrative examples (arguments) from the lake area objects. The outer border polygons exactly overlap but the areas have different hole structures (covers case of identical geometries). For instance here https://osm.org/go/y3Q5zNY- (missing islands, how many?). Outer polygon section of a smaller area exactly overlaps an outer border section of a larger area like here https://goo.gl/aAvEkM (exact fragment overlaps, how many?). Corridor replica (overlaps) when some border polygons of two geometries are so close to each other that with a very high probability the geometries represent the same real world object, like here https://goo.gl/DtF2nA. Just to mention some and of course, many combinations of the former cases. While a solid/robust data preparation should detect and correct/repair (and it does) the mentioned overlap cases, still there is an overlap class raising a dilemma what to do. These are when a smaller area is strictly inside of a larger in the same class, e.g. lakes (the smaller outer is strictly inside a larger outer and outside any holes of the larger) like here https://goo.gl/7HUX43 or here https://goo.gl/TjfP9o or here https://goo.gl/H8E3L5 or here https://goo.gl/ZY64u3 ... not to mention the confusion in the Venezia lagoon. Trusting the tags only, these areas are redundant and should be ignored but according the Wiki rules and trusting the geometry these smaller areas should be holes. Having in mind only raster map-making, the mentioned anomalies/errors are not so important (blue is blue for lakes, green is green for forests...). At the same time for the OSM based GIS and vector map-making the overlaps present serious issues/problems. Just take the procedures like defragmentation, data generalization, tiling, rectangular clipping and so on. Finally, anomalies/errors in the OSM source data in certain cases represent a valuable attribute. There is no richer and larger source of serious and complex issues for research and academia related to topology, polygon algebra, algorithms, programing... than the OSM source data. So, insisting on corrections, especially by mass editing, should not be a OSM strategy. These errors are there, some will go and many new will come. Instead, strengthen you data preparation tool and offer it to users with arguments. But please, do not touch the source data. What you think is an error probably not error to me/others and your corrections will just make more troubles to me/others. Regards, Sandor.
Sent from Mail for Windows 10 From: john whelan Sent: 22 November 2017 00:19 To: OpenStreetMap talk mailing list Subject: [OSM-talk] finding overlapping buildings Can someone describe a method I can locate these in JOSM. I'm not after crossing buildings but just those that are mapped twice so two buildings with 50% or more overlap. Straight duplicates aren't a problem but ones that are drawn twice by two different mappers are. Yes I know it shouldn't happen but it does. Thanks John
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
