<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-GB link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=NO-BOK style='color:black'>John,<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>The outer border polygons exactly overlap but the areas have different hole structures (covers case of identical geometries). For instance here <a href="https://osm.org/go/y3Q5zNY-"><span style='color:black'>https://osm.org/go/y3Q5zNY-</span></a> (missing islands, how many?).<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Outer polygon section of a smaller area exactly overlaps an outer border section of a larger area like here </span><span lang=EN style='color:black'><a href="https://goo.gl/aAvEkM"><span style='color:black'>https://goo.gl/aAvEkM</span></a> (exact fragment overlaps, how many?).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='color:black'>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 <a href="https://goo.gl/DtF2nA"><span style='color:black'>https://goo.gl/DtF2nA</span></a>. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='color:black'>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 <a href="https://goo.gl/7HUX43"><span style='color:black'>https://goo.gl/7HUX43</span></a> or here <a href="https://goo.gl/TjfP9o"><span style='color:black'>https://goo.gl/TjfP9o</span></a> or here <a href="https://goo.gl/H8E3L5"><span style='color:black'>https://goo.gl/H8E3L5</span></a> or here <a href="https://goo.gl/ZY64u3"><span style='color:black'>https://goo.gl/ZY64u3</span></a> ... 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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='color:black'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='color:black'>Finally, anomalies/</span><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Regards, Sandor.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:jwhelan0112@gmail.com">john whelan</a><br><b>Sent: </b>22 November 2017 00:19<br><b>To: </b><a href="mailto:talk@openstreetmap.org">OpenStreetMap talk mailing list</a><br><b>Subject: </b>[OSM-talk] finding overlapping buildings</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Verdana",sans-serif'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Verdana",sans-serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Verdana",sans-serif'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Verdana",sans-serif'><o:p> </o:p></span></p></div></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Verdana",sans-serif'>Thanks John<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>