|
I'm mapping nature in national parks in Sweden. Wetlands in Sweden often have names. Most consists just of bog, but some consists of both bog and marsh, which means that they must be split into more than one polygon. In cases where two or more separate areas have the same name I just make a multipolygon with several outers and assign the name to the multipolygon relation, which seems to be the defacto method as group and cluster tags aren't really used. However that only works if all areas are of the same type as the tags need to be on the multipolygon relation, not on the outer ways. In this case the areas are indeed all wetlands, but of different sub-types bog and marsh. I don't know of any way to name this as a single entity. Any suggestions? The only one I can think of is to have multiple (multi)polygons and just name all the same and hope renderers that see that the polygons are joined and named the same understand that it's the same entity and thus renders a single name rather than one in each sub-polygon. |
|
We have the same situation in Uganda. We have large wetlands with a single name consisting of different wetland types like bogs, marshes, swamps, mud plains and reedbeds, even tidal flats. These wetlands are many times encroached so might contain other land uses like farmland and residential areas. We solve this by creating a multipolygon relation, surrounding the complete wetland area and give it a single name. We apply the key boundary, eventually protected area with classification, and natural = wetland. The boundary doesn't get a specific wetland tag. All the different wetland type areas, within the boundary are made part of the relation with role inner. Each defined as natural=wetland and each with wetland=(specific type). Now, as you define the inner areas, you can't share the outer boundary multipolygon with the inner areas. Leave a small gap. Bordering outer areas which are not wetland or water bodies can overlap and share their outer ways with the wetland inner areas. DUe to the small gap this renders fine and doesn't give any warnings in JOSM since none of them are overlapping. It also makes it easy to select any wetlands and update their protection classification. The only problem you get and which we didn't resolve is with wetland bordering large lakes, like in our case Lake Victoria. We do let the wetland outer boundary extend into the lake, so we can contain any tidal flats within the boundary. However you get an overlap between the wetland boundary and the lake, which gives you a warning of overlapping water areas in JOSM. We chosen to keep it this way since the tidal flats are important and the lake level rises continuously, so we need to adjust the high water level line. You could however split it in separate relations to avoid this single warning, we have chosen not to do so. You can see some examples, which we still work on between Entebbe and Kampala. This solution renders fine in most applications and Carto. We solved the issue with the outer boundary extending in water bodies like a lake. You avoid any warnings by sharing a node between the lake shore (a closed way or multipolygon) and the boundary. So you can easily extend it into the lake. We map the parts of the wetland in the lake the same way as other parts of the wetland, and include them as inner parts in the wetland relation. They will render with the lake as water body overlayed. We no longer use tidal flats, since the flooded wetland parts are seasonal features or due to rise or decrease in the lake water levels over the years. The part of the boundary in the lake is also part of a second relation of type hazard and defined as a flood zone. The intention is to stop updating the lake shores whenever new satellite imagery comes available. The actual lake shore is somehow the median of the two. These long time high and low water lines don't change that often. You only need to update them when you see the lake has crossed it. I am preparing a wiki page to describe the whole principle, since it can also be used for lake shores where there are no wetlands. I will forward a link here as soon as it is ready. Greetings.
(11 Feb '21, 00:21)
Bert Araali
|
|
You cannot handle this situation with a single multipolygon. You must create as many multipolygons as are needed to define the various wetland types, sharing ways when necessary. That means that some ways might be part of one or more other multipolygons. The rendering engine on the OSM webpage can handle such data structures. Other applications or software products may not be able to do that but we don't concern ourselves with issues of rendering. If they are all part of a single named wetland, then the name would go on the top-level multipolygon, the one that contains the other areas, the individual multipolygons of bog, marsh, or what have you. Hope this helps Hmm, is this considered "legal"? I am familiar with multipolygons, have lots of them already (impossible to map complex nature without them), but the arrangement you suggest I haven't used as I thought it was considered a bad polygon. If I just add a name tag on the outer way surrounding all sub-polygons, I get warning from JOSM (it wants a type tag as well). If I instead make a new multipolygon based on the outer way and name that, JOSM tells me that it needs a type as well. And if I do assign a type (generic wetland without subtype) I get a warning that I have overlapping natural features ("water area inside water area", JOSM doesn't differ between water and wetland in error message). If I make this on a multipolygon or directly on the surrounding outer way doesn't matter. I tried upload a test (both with and without containing multipolygon) to see what OSM-Carto makes of it. It sort of seems like it works, but if you look closer the wetland pattern of the outer polygon is drawn on top of the inner polygons. It seems to me that this is not the way to do it. Which is unfortunate, as it would be quite elegant if it worked. Comments/suggestions?
(11 Dec '20, 14:21)
torger
There's no problem in having multiple polygons with landuse overlapping in OSM. As Alaska Dave says (& I believe they have extensive experience of this approach) such overlaps can be processed to achieve a wide range of desired results in consuming software. Do not worry too much about how OSM-Carto does it because OSM-Carto is optimised for rapid rendering of recently changed data. For many uses of landuse it is necessary to do some preprocessing (e.g., removing overlaps, merging adjacent similarly tagged landuse, punching holes in landuse (for instance road corridors etc. etc).
(12 Dec '20, 20:00)
SK53 ♦
|
