You can make any number of relation members with role “inner”. So if the refuge has outlying areas which have a hole in them, the way(s) around the outside are role=outer and the way(s) around the hole are role=inner.
It really is “multipolygon”: as many polygons as you want, with as many holes and donut shapes as you need. -Joseph On Mon, Oct 29, 2018 at 9:12 AM Dave Swarthout <daveswarth...@gmail.com> wrote: > Okay, next question. > > I added the Laguna Atascosa National Wildlife Refuge to OSM yesterday . (I > don't do much mapping in Texas but that place is special because I once did > a water quality assessment there as a volunteer.) It's a fairly large > multipolygon and the main relation holds the bulk of the refuge territory. > However, there are scattered about several other areas, some of which are > also multipolygons, that are part of the refuge. > > Simple areas can be easily included as "outers" in the main relation (Rel > ID:885828). But what about other pieces that are multipolygons? I could > simply add them as separate relations with identical tags but handling such > areas that are connected administratively but not physically would seem to > be one reason multipolygons were invented. But I'm thinking there must be a > more elegant method. And what about inner areas that are also > multipolygons? This case cannot be handled by my simplistic approach. > > How should I deal with this? > > Thanks in advance, > > Dave > > On Fri, Oct 26, 2018 at 10:07 PM Kevin Kenny <kevin.b.ke...@gmail.com> > wrote: > >> 26. Oct 2018 11:52 by daveswarth...@gmail.com: >>> >>> Thanks, That helps a lot. I don't work with routes (yet) but it when I'm >>> adding inners to riverbank multipolygons I always add them in the order >>> they would appear if you were traveling downstream. It just makes sense to >>> me although there's probably no programmatic reason to do it. >>> >>> On Fri, Oct 26, 2018 at 5:55 AM Mateusz Konieczny < >> matkoni...@tutanota.com> wrote: >> > Order of elements is saved in OSM database. >> >> That appears to be the answer to a different question. >> >> The 'sort' operation in the JOSM relation editor changes the order of the >> elements. If the layer is uploaded, the new order of elements, as produced >> by the 'sort' operation, will replace the old order in the OSM database. >> >> This is usually what I want with a multipolygon. With a route, I find >> myself undoing or further altering a 'sort' operation much more often, >> because there are often things about routes that JOSM doesn't get quite >> right. (Example - a dual carriageway where both ways end in link elements >> looks as if the route has floating endpoints, and the sort operation messes >> up one of the directions.) Even there, though, the 'sort' is usually Pretty >> Close to right, and is often usable as a starting point. Moreover, I'm not >> sure that it can be improved. The topology of a route isn't always quite >> right in the field, and some of 'getting it better' amount to 'read the >> mapper's mind,' something computers are ordinarily not well equipped to do. >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
