<div dir="auto">There has been some discussion on the HOT mailing list that makes things a bit clearer.<div dir="auto"><br></div><div dir="auto">OSM in general has a fair number of things that have been added in a less than ideal way.  It can be difficult to correct some things as we have guidelines or recommended practises as opposed to hard and fast rules but maproulette has managed to identify a number of areas where there is some agreement about what needs to be corrected.</div><div dir="auto"><br></div><div dir="auto">JOSM validation also tries to identify problem areas so I suspect fixing the underlying data is the better long term solution rather than ensuring all the different rendering systems are more robust.  Robustness costs machine cycles​ as well.</div><div dir="auto"><br></div><div dir="auto">Cheerio John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 Mar 2017 4:43 pm, "Sandor Seres" <<a href="mailto:sandors39@gmail.com">sandors39@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_3799381040175542496WordSection1"><p class="MsoNormal">I am new to this list and therefore apologize for eventual misinterpretations and wrong stile. The motivation for the mail is a worrying mail on the local list about the purer osm2pgsql based maps and about the “broken polygons” fixing strategies. The mentioned white spots in the Scandinavian forests are just an illustration. By simply dropping broken polygons, empty spots will be typical for any area types and for any corners of the Planet. <u></u><u></u></p><p class="MsoNormal">As I understand, osm2pgsql is an application doing data preparation from the OSM source data up to a DB used by many mapmakers for rendering. We can see that almost all OSM based public mapping system use this database and consequently repeat the same anomalies. Therefore, maybe, making the osm2pgsql more robust could be a better strategy. There is still a large potential for such strengthening. Just waiting for “do-ocracy” reparations is really a long-term strategy. Anyway, users starting from the source OSM data will not be affected by any of these strategies.<u></u><u></u></p><p class="MsoNormal">The “Fixing broken polygons”, especially programmatic/mass fixing, could be more dangerous to all users. Just look at the many possible self-crossing fixing options. Loosely defined notions open for different interpretations and different sets of error criteria. Consequently, for the same object type we may have (and we do) different error classes and reparation tools. Besides the typical polygon interpretations as area (ESRI polygon redefinition) or as a closed polygonal line, we simply can’t find in the documentation what “outer”, “inner”, “hole” … notions actually mean. The interpretation (individual perception) of these notions is left to us and there we have a source of misunderstandings. For instance, if we assume that “outer” border polygons define the interior candidate points (points inside and on the border) and “inner” border polygons define (in the same way) exterior points of area than self-crossings, touching polygons, polygon overlaps, crossings… are not errors at all. <u></u><u></u></p><p class="MsoNormal">However, my point here is still something else. The “broken multipolygon” (whatever that means) issue is just “the tip of the iceberg”. There is still remaining huge number of anomalies caused by area object relations from different area classes. I intentionally use the anomaly notion, as a moderate form for error, because many people/mapmakers may liv with them. But a modern GIS system and a vector layers based digital cartography cannot tolerate them. Let me present some arguments and illustrations. Let us look at a map extract from the mentioned Scandinavian forests here <a href="http://osm.org/go/0Tt1PZIt-" target="_blank">http://osm.org/go/0Tt1PZIt-</a> . The example could be taken from any corner of the Planet and, as mentioned, there is huge number of similar cases. At the first glance, everything looks correct and nice (and it is). However, we see immediately that something is still wrong. The forest type symbols are placed directly over the water. In another style, typical land related names are on the water like here <a href="http://osm.org/go/0Tt1PZIt-?layers=T" target="_blank">http://osm.org/go/0Tt1PZIt-?<wbr>layers=T</a> . Looking at the source data we can see that the lake in the middle is placed over an empty space (intentionally, not a hole) where the border of the lake runs slightly in and outside the forests. At the same time, we can see many forest areas inside the mentioned empty space overwritten with the lake that has no holes. Consequently, there are many missing islands in the lake and many missing forest areas in the extract. Note that only on that little extract there are more than 40 of the described anomalies. What more, there are many lakes with borders running in/out of forest areas (corridor border overlaps), having considerable parts over a forest and holes in forests, partly overlapping several disjunctive forest areas and so on, and the contrary. Extending the case to the Planet and other area types combinations we may feel the extent of the issue. There were attempts to compensate these problems in renderings like rendering the holes, rendering smaller over larger objects and so on. These actions generally do not work. Simply, they do good some places and damaging at other places. So, the question is whether and what can we do with the problem. Just waiting for do-ocracy based reparations is, obviously, irrational. Fortunately, the source data has a large potential to remove most of the mentioned anomalies. Let me present some hints in bullets for the forests, lakes and river combinations.<u></u><u></u></p><p class="m_3799381040175542496MsoNoSpacing">Assume {F0} is a set of all forest outer border polygons (closed polygonal lines) and {F1,L0,R0} is a set of all inner forest, outer lake and outer river border polygons (the orientations and the relations are irrelevant). Then, you can prove the existence of minimal disjunctive simple area coverage of the forests. In other words, you can find a set of isolated simple areas (one outer and zero or any number of inner polygons) where any area point is on/inside of at least one element in {F0} and never on/ inside of any element in {F1,L0,R0}. This coverage is the topological area difference, or subtraction, {D}=U{F0}-U{F1,L0,R0}, where U stands for union. To find this coverage is really a nice challenge for researchers in topology, algorithms and, of course, in programing. Some data preparation tools already have procedures for making this coverage for some  major area type combinations like the planet_sea/global_ocean, forests, lakes, rivers and some more. An extract from such coverage for forests, lakes and rivers combination is presented in this image <a href="https://drive.google.com/file/d/0B6qGm3k2qWHqLWMtcVRIVklXUmc/view?usp=sharing" target="_blank">https://drive.google.com/file/<wbr>d/<wbr>0B6qGm3k2qWHqLWMtcVRIVklXUmc/<wbr>view?usp=sharing</a> . Note that whatever Z/rendering order one takes the image is always the same. The only difference may appear in the borderline colours if hard edge rendering is used but even this difference disappear with the “smooth edge” anti-aliasing technology.<u></u><u></u></p><p class="MsoNormal">Regards, Sandor.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div><br>______________________________<wbr>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk</a><br>
<br></blockquote></div></div>