|
Hi. Is there any logical/practical reason for distinguishing between holes/islands in different area classes? For example, take some overlapping water areas just some miles to the south-west from Montreal, or around the large lakes further to the west. Some holes/islands are in the planet-land/planet-sea area class (created from the coastline data) and some in the overlapping lakes (from the natural-water class). When rendering, many of these inevitable disappear. Rendering some land-use areas (like forests) on top of the former layers is just masking this error but does not solve it. Fortunately, the described error type is of logical nature. Not a show stopper. Unfortunately, it is present in (almost) all OSM data based mapping systems publicly accessible. Of course, we can live with these errors but they are destroying the reliability of the related mapping systems. |
|
The whole subjects of areas/polygons, especially areas with holes is a big mess. The reason is simply historic. We don't have an area/polygon/multipolygon object type, so we "simulate" areas by other means: Closed ways, special relation types such as multipolygon and boundary, or tags on ways such as area=yes, waterway=riverbank and natural=coastline. Relations are a relatively late newcomer to the OSM stable of object types and they are complex, so they still are not integrated properly everywhere. Each of these "solutions" work slightly different, and it is practically impossible to get all of this right, even if we knew what "right" is supposed to mean. Basically everybody agrees that we need some kind of "area" datatype, but it is unclear how this is supposed to work exactly. See the wiki for ideas and plans in that direction. Thanks Jochen for the clear answer. I was just expecting something like this. Honestly, the question was slightly provocative. But, even if we manage to create correct area topology structures, the mentioned problem/error class is still remaining. I believe the OSM dev-request forum is more appropriate place for detales on this issue. If interrested, look at "A dilemma, problem, challenge" on that foru.
(23 Jan '13, 21:21)
sanser
|
Would it be possible to include a permalink to a specific example of the problem?
Also (if you haven't seen it previously) have a look at this previous answer about coastline updates.
Thanks for the comment. Note that you will not see these errors just looking into a map based on OSM data. But, the errors are there. Also, the suggested link is irrelevant in this case. It is explaning the delay in a map application while the issue is OSM source data related. For those interrested in this problem I will post a problem spec with examples to OSM dev-request forum with the title "A dilemma, problem, chalenge".