I don't approach this as getting solved in one multipolygon. I might use two multipolygons, one tagged wetland=bog, another tagged wetland=marsh, both tagged natural=wetland. Add name=* as appropriate. Closed ways (plus other things, with other tags) do overlap (these two seem they should not). Let renderers deal with such issues.
Different than natural=* tagging, there is also a proposal that includes an "unadorned" boundary=protected_area tag (on a closed way or a relation), without a protect_class tag (one is not known or is "less known"). This might, someday, render as a simple green line. This conveys what is (an often legal) boundary, so it isn't natural=*. See if this proposal (https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap your logic (and OSM's syntax, a boundary=protected_area tag, or its semantics, a perhaps-someday-drawn rendered green line) around this. Untangling natural, leisure and boundary tagging is ahead in OSM, things do get better. How (the Carto, for example) renderers draw natural=* on top of one another is actually a rich topic: it can be said these behaviors are renderer specific. (Yes, Carto "drawing order" is not necessarily perfectly defined). These are complex topics, getting better as proposals gain approval (a working strategy so far). The example of natural=* tagging below is a topic of some confusion among mappers. For example, I don't believe Carto rendering is perfectly predictable without first knowing "size of all overlapping polygons." This can make "accurate" (or pleasing) natural tagging challenging or unpredictable in some circumstances. I believe at least some of what is rendered has to do with the size (and order entered?) of overlapping polygons. In short, I "tag the data I know" at the complexity I'm comfortable tagging them, as accurately as I know how, using OSM's wiki to describe tagging. Multipolygons differ from relations like them which aren't (like those tagged boundary=*), independently as far as renderers are concerned. It is easy to get confused, confusion exists in the map: semantics are blurry in some cases. This gets better with worldwide consensus, over years. This (how we learn to best tag and render) is an ongoing long-term OSM process. As a mapper, "tag accurately first," then let renderers interpret. SteveA > On Dec 11, 2020, at 11:53 AM, Anders Torger <and...@torger.se> wrote: > > Unfortunately I don't think that is possible. > > Multipolygons may only contain ways that have either role as inner or as > outer. It may not contain other relations (still possible to upload, but not > considered right according to the wiki). What should the ways be? > > We can't make the separate wetland parts as inner ways, (as areas formed by > the inner ways are subtracted from the multipolygon), and even if we try it > becomes illegal as inner ways cannot share segments with the outer way. We > can't make the parts as outers either as they share segments. The outer must > be the surrounding outline without the shared segments splitting the wetland > in parts, and there are no inners (unless the parts themselves has inners). > > So then we have a multipolygon with just an outer. I could just as well be a > plain polygon made from a single closed way. This would work if drawing order > was defined, and that was the method I tried first. The container polygon > must have a natural tag as well (the logical would be wetland here without > further sub-classification). > > However the drawing order is not defined (I think, not 100% sure), so this is > by the renderer interpreted as a wetland lying on top of the other wetlands. > OSM-Carto will still render the insides, but the fill pattern of the outer > polygon is drawn on top. > > On 2020-12-11 18:09, Brian M. Sperlongano wrote: > >> Hello Anders, >> >> I would recommend creating a multipolygon relation (type=multipolygon) with >> each of the wetland pieces, and set the name= and appropriate natural= and >> wetland= tags on the relation. >> >> On Fri, Dec 11, 2020, 11:11 AM Anders Torger <and...@torger.se> wrote: >> Hello, >> >> I was on this list a while back expressing some frustration over >> limitations when tagging nature and thought about getting involved in a >> process for change, but I came to realize that it's not feasible for me >> in my current life situation, so I've decided to continue be a normal >> mapper as before, doing what I can do with features that exist today. >> >> Anyway, if to be a mapper at all, I still like to solve some of my >> naming issues in the best/least bad ways possible today. I'm currently >> mapping a national park in Sweden, Muddus. It's in Laponia and consists >> of mighty wetlands and old forest. These wetlands are named, like is >> common in Sweden and Sami lands. For us navigating in wildlife, names in >> nature are important. >> >> A wetland polygon can be named in OSM, so the situation is better than >> for example for named slopes (also common). However, a wetland here can >> consist of both bog and marsh (and it's important to make the >> difference, since one is easy to walk on, the other not so much). That's >> two different natural types and thus can't be in the same multipolygon >> (as outers). >> >> Asking on OSM Help website for a solution I got the answer to make a new >> containing multipolygon and set the name on that. That would be quite >> elegant for sure, but JOSM warns about that, can't have a name without a >> type, and if I set the type, say natural=wetland without any subtype, I >> get a JOSM warning that I have natural features on top of eachother. If >> I still upload it OSM-Carto does render out the name but you can see >> that the wetland pattern of the outer polygon is drawn on top of the >> contained polygons, so it does not seem to be the way to do it. >> >> The least bad way I've come up with is to just name all polygons >> belonging to the same wetlands the same, and hope for that in the future >> smart renderers will understand that polygons with shared borders and >> shared name is the same named entity. >> >> Any ideas or suggestions? >> >> /Anders >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
