Adam Franco <adamfra...@gmail.com> writes: > Steve, I think that cutting wilderness/etc areas out of the NF polygon is > logically problematic as these *are* part of the NF, just with extra > restrictions. You don't leave the NF when you enter the wilderness area. > ...One significant issue with this is that > "adding them back in by operator" would have to be handled by data > consumers to understand the model, a new and extra burden.
I considered that possibility might or would arise even as I was writing what I wrote and after considering what you write here, I do agree. I was attempting to take a shortcut to keep things simple, but this stuff is anything but simple! > I'd rather see a tagging structure that was logically consistent, where a > query of "is this point in the NF?" always returns the correct answer for > any point. This might be more complex than just a multipolygon and use > parent/child relations (that was intentional language choice on my part). That is an admirable goal, seems correct (to me) and I almost hungrily await a data model than can capture it. > Here's an example: > - Parent relation: > - name=Xxxx National Forest > - operator=United States Department of Agriculture, Forest Service > - ownership=national Ah, OK, If you really DO mean "parent" relation and we move into using super-relations, got it; that's OK if it is what you mean to express, please use the word "super-relation" (a relation of relations). In a super-relation, the term "parent" can apply to "the" (root) of the super-relation, and "a child relationship" happens between the "parent super-relation" and each of the member relations (which are its "children"). Thank you for making that explicit. I fully anticipated that a "more correct" method to do this (complex NF data relationships in OSM) might necessarily "move up" to super-relations, so here we go! For these readers not familiar with super-relations, buckle up and study about them, they are both complex and powerful, so understanding the data relationships can be difficult. But, sometimes (as I suspect here), there isn't any other good method to do what needs doing. I've been using super-relations in very large bicycle route relations (e.g. ECG) for many years, and while complex, they both break things apart into sensible chunks and logically put things together in a way which (to those practiced familiar with how super-relations work), can and do nicely express complexities both understandably (more-or-less!) and which are topologically (geometrically, mathematically / logically, route-sensibly...) correct. > *(NOT protect_class=6 as that will not be true for all members) * > - One (or more) child multipolygons for all of the "normal" areas: > - boundary=protected_area > - protect_class=6 > - protection_title=National Forest > - Child multipolygons for each wilderness area (if any): > - boundary=protected_area > - protect_class=1b > - protection_title=Wilderness > - name=* > - Child multipolygons for each recreation area (if any): > - boundary=protected_area > - protect_class=5 > - protection_title=Recreation/Landscape > - name=* > - Additional child multipolygons for otherwise designated parts of the > NF not included above. Dang, that seems quite workable! At least at the "human builds complex super-relation structure" level, it makes sense to me. Whether renderers make sense of it highly depends on the renderer: some parse super-relations, some don't. I invite Mr. Joseph Eisenberg to say what Carto might do. (Or even intends to do?) I'm literally nodding my head and smiling that ANYbody posted this here: very cool! I like! Adam, I feel like ringing a bell and saying "we have a winner," but let's vet this more widely. I'm excited, but let's pick it apart some more. > Such a structure could have only a single object for those NFs that have a > single uniform protection class, but expands gracefully to more complex > situations where those exist. Hm, some examples would help me wrap my head around this better. I agree for "single," but I'd like to see what you mean by "more complex situations." > The big challenge with this scheme is that I > think that the parent relation may need to be a boundary relation > <https://wiki.openstreetmap.org/wiki/Relation:boundary> instead of a > multipolygon relation because ways may be shared between children, eg the > border between a protect_class=6 and a protect_class=1b area would be a > role=outer of both, potentially resulting in an invalid multipolygon > <https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Overlapping.2C_unclosed_member_ways_belonging_to_the_same_role>. Yes, that would break JOSM's Validator plug-in, for sure (not potentially, I've seen this and done this and the only way to upload the MP is "in Error" or after it is corrected so that there are no shared outer ways). > That said, I'm not quite sure of the nuances of valid/invalid multipolygons > that are children of a parent relation and I'd be happy to be wrong on this > point. It's rich, deep and almost beyond my ken. I think I can understand it, I think many who are reading this can, too. Speaking for myself, we're out on the hairy edge of my understanding of MPs, super-relations, differences between boundary and MP and how the sort of "higher math" of tagging segments differently, then stitching them together into either polygons or members of MP relations affect whether the MP / relation is or isn't valid. Thank you, Adam! This thread HAS momentum, let's keep it rolling! SteveA _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
