[Tagging] Another multipolygon question

Dave Swarthout daveswarthout at gmail.com
Mon Oct 29 00:10:43 UTC 2018

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,


On Fri, Oct 26, 2018 at 10:07 PM Kevin Kenny <kevin.b.kenny at gmail.com>

> 26. Oct 2018 11:52 by daveswarthout at 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 <
> matkoniecz at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181029/9aa4fc8e/attachment.html>

More information about the Tagging mailing list