Re: [OSM-talk] Openstreetmap-carto switching to ocean polygons
Joseph, I am not sure you will get some response to “...it needs testing...” especially not from GIS and vector map-makers. To do such analyses one should start from the source data, should have a robust tool-set and be willing to invest lot of work and time to compare, measure, run applications and so on. If the “switching” issue is only a low scale rasterization and display efficiency related then the whole issue IMO is irrelevant (arguments). However, in GIS and vector map-making, especially from the scientific point of view, the coastline land polygons vs. ocean polygons issue is essential. This issue was many times up to discussion and they were various data versions of these polygons available, some used in the OSM main map layers. Some years ago I made a pretty detailed analyses of the coastline large land/water polygons and their generalized (scale level) versions and published the results here https://lists.openstreetmap.org/pipermail/dev/2016-June/029295.html . Last several days I have invested to repeat some of the work done in the link to see the present state of the polygons in focus. Many of the mentioned anomalies in the former article are still there though by reduced extent. Some short related notes: -The former polynomial polyline smoothing is replaced with a cartographic vector smoothing model. Much more realistic. -Inland waters are moved to lakes and that allows radically faster water/ocean polygons creation by remaining land polygons inversion. -The land polygons data contain large number of small polygons of land-on-land type. -There are still several replicated consecutive nodes on land polygons. -The global ocean (the large water) polygons still contain anomalies along the World frame (inversion problems). -Simplified water polygons are created by simplifying and inverting land polygons. This is never the same as simplifying water polygons. -The split polygon versions contain large overlaps and these for GIS and vector map-makers present more trouble than good. Finally I would strongly underline the following note. Using generalized version of water polygons without synchronization with other object classes (lakes, rivers, forests...) causes serious logical and aesthetic cartographic problems. For instance, large objects in one class disappear while small objects in other classes still are present (collapse synchronization), objects with radically different details are connected or slightly overlap and so on. An example of simplified water polygon and not simplified lake connection can be seen here https://osm.org/go/Z1a9HCF6g-?layers=TD=100084105 . This link also illustrates the mentioned erroneous small polygons in the coastline land polygons that are missing islands in lakes or rivers. Sandor. Sent from Mail for Windows 10 From: Joseph Eisenberg Sent: 26 February 2019 04:10 To: talk@openstreetmap.org Subject: [OSM-talk] Openstreetmap-carto switching to ocean polygons There is a new PR on the Openstreetmap-carto Github page which will switch this “standard” style (used on the main OSM page) to water polygons instead of land polygons. However, some users reported problems with the simplified water polygon shapefiles when this change was attempted in 2016. We believe the problem is no longer present, because the German map style is using these shapefiles without problems, but it needs testing. If you were one of the affected users, please try out the change on your server. The branch is available at: https://github.com/jeisenbe/openstreetmap-carto/tree/ocean-polygons New PR: https://github.com/gravitystorm/openstreetmap-carto/pull/3694 Old issue: https://github.com/gravitystorm/openstreetmap-carto/issues/2101 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Multiple errors in the same location
When multiple errors appear in the same location the question is what to do? The simplest option is, nothing. Wait until a mapper is correcting all the related errors. Most of the detectors, inspectors, renderers, data preparation tools… select this option today. Consequently, all publicly available maps repeat the same errors what is, of course, wrong. Let us take an illustrative example here https://osm.org/go/cCcWZjGW . A careful analyses shows that there are several serious errors in this location. Let us mention some. 1.There are two radically different partly overlapping lakes in the location. 2.None of the lakes are close to fit into the hole in the forest area. 3.The forest and any of the lakes overlap considerably. 4.The island in one of the lakes is just partly invisible (overwritten by the other lake). 5.The obsolete natural=land tag is used for several node objects in the lakes. 6.The place=islet tag is used for several nodes without the name tag and value (so, meaningless). If there were just a few cases like described one could contact the corresponding mappers or just make a note description on the location. Unfortunately the number of cases like the illustrated is so large that neither of the mentioned source data correction models is feasible. Yet, it is worth to mention that some data preparation chains perfectly resolves this complex error issue in their GIS or map-making systems. Sandor Sent from Mail for Windows 10 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Detect and remove sharp angle/spiky configurations on buildings
Some days ago there was a question on an OSM forum whether such algorithm exists and used by some of the OSM users. Honestly I even did not know that such an issue exists and probably I am not alone. The reason to that is either that the spiky configurations are hardly visible in maps or that robust users handle them as a special case when process tiny outgrowths in their data generalisation programs. A closer look at the issue has shown that the issue is real and rather general. Spiky configurations exist on most of the area borders, roads, roundabouts and so on, there is a huge number of them and almost all are errors. To provide strong arguments about the former statement I have made an algorithm, a simplified version of the tiny outgrowths detection and removal, and applied the corresponding program to the OSM UK buildings. The algorithm on a certain abstraction level, its use and the processing results are described in details in an article here https://drive.google.com/open?id=1MaLdnSnc454xKjn3eL95vDQKeoIW8zGU . There are around 120K spiky buildings in OSM and out of these 2834 in the UK. In addition, the paper presents many examples how the spiky buildings look before and after the correction. Also, the paper contains links to the output data of the demo/test processing and how these could be used for visual analyses. So, if interested, enjoy the paper. Regards, Sandor. Sent from Mail for Windows 10 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Waterway rel with mix of line & poly
Jem, you have, of course, fixed the issue already. That was the right ting to do. Though, there are many, many similar cases and not only in natural=water tagged geometries. Many users run a geometry-model based recognition program that detects and repairs these problems even not knowing they were there. However, two comments from the last mail deserve some further comments. >> Relations should not be used to collect thing together. >>? That is what they can be used for. See the site relation as an example. Yes, “they can be used for” but here OSM wiki is explicit “should not be used” (obligatory restriction). Besides, when I see/search the OSM wiki using the “site relation” key I got this https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site. It is a proposal just like many other “collecting thing together” proposals like multiobject, group, cluster... Using these proposals in private database versions is up to the users but should not be used in OSM data source. Otherwise, mappers can cause damage to others, serious professional mismatch and huge data and work redundancy. Just look at this https://osm.org/go/cAO2c--?relation=1124369. Why, just for the Wikipedia link or some never used names? >> MP relations should be restricted to the areas which have inners:... >> No. They can be used to collect a series of outer ways to form the boundary >> of a feature e.g. an administration boundary usually shares ways with >> adjacent >>administrations Irrelevant contrast. However, the second line perfectly illustrates how to present an administrative (political) AREA feature using MP. Because of many rendering issues related to overlapping areas, if only the area boundary is needed, OSM wiki has introduced the “boundary” as a new tagging key and using MP declared deprecated for that purpose. The suggestion in the first line is not acceptable for now. Simply, we don’t have other tools to represent areas with just one border line when the number of border nodes (considerably) exceeds the node number limit in the “way”. Sandor Sent from Mail for Windows 10 From: Warin Sent: 21 September 2018 01:33 To: talk@openstreetmap.org Subject: Re: [OSM-talk] Waterway rel with mix of line & poly On 21/09/18 06:11, Jem wrote: Thank you both. That's very helpful. On Thu, 20 Sep 2018 at 22:25, Dave F wrote: Hi Short answer: Yes There's a few problems here: Relations should not be used to collect thing together. ? That is what they can be used for. See the site relation as an example. There shouldn't be tags on the ways which conflict with those in the relations True. MP relations require a 'type' tags and 'inners' & 'outers' roles True In this case the Southern section shouldn't be a polygon Did not look. MP relations should be restricted to the areas which have inners: https://www.openstreetmap.org/relation/2571440#map=19/51.15275/-2.05045 No. They can be used to collect a series of outer ways to form the boundary of a feature e.g. an administration boundary usually shares ways with adjacent administrations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] VECTOR TILING in applications
Tiling strategies and models are very well known and developed today. Especially uniform raster and vector tiling models in services where the tiles are pre-generated for efficient transmission and rendering. However, vector tiling is much, mush more than that. It is a powerful tool in many application. Let us mention some of the applications where a special vector tiling radically increases the efficiency. The examples are selected based requests/interest on OSM forums. 1. Detecting objects being inside a large polygon from a large set of objects. The issue is illustrated by OSM buildings and the polygon of Africa. If a usual “objects in polygon” algorithm manages the task, it will probably use very long time. Using an efficient vector tiling based algorithm the task can be accomplished just in several seconds. 2. When we do visual inspection of the result in 1. we can see that many buildings are partly in the sea. Whether these cases are mapping errors or not is irrelevant here but the issue triggers a task to detect buildings in Africa being partly in the sea for further actions. By using the usual filtering models it is almost impossible to solve this task or it will last even longer than in 1. The progressive vector tiling, the multitiling procedure helps to solve this task in seconds. 3. When RW area estimates are needed for large areas in a projection (e.g. Mercator) we inevitably meet the accuracy problem. We need to create area fragments and apply known position based correction factors. Here, again, a progressive tiling helps us to solve the issue on-the-fly. 4. Sometimes, when using Polygon Algebra based operations with area arguments the results might be so complex and complicated that we could never be sure that what we see is really what we wanted. For instance, if we need the intersection, the common area of several highly complex areas. In similar cases we need a reliable, simple and fast verification model. Vector tiling might provide an excellent validation model for these cases. The mentioned applications are described in details here https://goo.gl/tuR5Wr. In the paper there are many supporting illustrations, examples and explanations as well. There are many hints for interested that they could repeat the experiments in an arbitrary programming language. The progressive tiling, the multitiling is also described and illustrated. Its comparison to the usual vector tiling shows its pre-dominance and the reality of the on-the-fly tiling in vector based GIS systems and vector map making. Regards, Sandor. Sent from Mail for Windows 10 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] finding overlapping buildings
John, yes, the buildings in Africa are really messed up. But yet, they are there in contrast to some largest digital map-makers. Just take a look on some examples like here https://goo.gl/CYVahc or here https://goo.gl/UWuBcf or here https://goo.gl/9iNYCm or here https://goo.gl/jUuqmS. There are several 10s of thousands similar errors like in the examples. But even though the absolute number is large, it is only a percent or two compared to the total number of buildings in Africa. And as I told you it is possible to repair almost all the above illustrated anomalies. It is challenging and I am working on it using the source data (XML dump) from some weeks ago. So, if you are patient for several days, you will get the buildings for Africa probably with the best preparation and based on the potential in the source data. The data will be in shp format accompanied by some statistics, additional geometries for control and a short documentation. Of course, if you don need these I will not bother you. But at least, you could use the stuff as an option to compare if you use other models. Anyway, the subject might not be of interest for other members so if you still want the buildings we could just switch to bilateral communication about some details (for instance Africa, the continent and Madagascar, eventually some small islands, in which projection(s) and so on). Regards, Sandor. Sent from Mail for Windows 10 From: john whelan Sent: 28 November 2017 22:13 To: Frédéric Rodrigo Cc: OpenStreetMap talk mailing list Subject: Re: [OSM-talk] finding overlapping buildings The problem is how do you fix them? Having something directly in JOSM is useful. They tend to appear in clusters so step one is find the cluster. Step two is sort the duplicates out. There really is some very poor mapping of buildings and this at least identifies the ones that there should be no disagreement about whether they should be deleted or not. One day we'll sort out what to do about the very badly mapped buildings that at least two other mappers have referred to as junk but that's another story. Cheerio John ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] finding overlapping buildings
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
