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
