|
Different tack for wooded open space / park land. If a park / protected area has an administrative boundary, as either a way or a relation, and I create a new relation that includes it and possibly additional area outside it and is tagged as woodland, should the new relation take precedence and render the entire area as woods? I don't think the original objects have tags that affect the renderer other than their original protected_area border. Major non-wooded objects such as ponds, parking lots, etc should be able to then get carved out as "inners" in the meta-relationship. How deep can relationships nest?? Can "outer" and "inner" components be relationships and ways as needed? This is in the interest of tagging a la my prior question to avoid messing with the underlying objects. Part of the intent is for expansion, bringing more woodlands outside the boundary into the larger relation where appropriate. So far, though, the approach doesn't seem to work, failing to render the woods at all in default Carto on the OSM site. How do I accomplish what I need here? |
|
If I'm understanding your question correctly, putting aside any other technical mistakes, this is caused by Secondarily, That's part of the point, simply adding natural=wood OR landuse=forest to the original relation is what people were objecting to, "woodland doesn't follow cadastral boundaries" and all that. So I'm trying to lay down real, genuine woodlands in new relationships to avoid messing with the underlying objects. Again, see previous comment, I did not put in the original Lynn Woods. And in fact I'm trying to avoid stepping on the toes of its other editors. I realize you're trying to help, but I'm just confused by comments on other tags that I wouldn't expect to have any effect on MY new overlay. Thus, the original question. Why would the original Lynn Woods [relation ...3480] be affecting tile display of my Lynn woods woodland [rel. ...6649] ?? What's happening right now, and this may be because of tile caching, is that different renderings show up randomly at different zoom levels. I've waited, I've tried to dirty some tiles, and it's still just behaving stupidly on the website. I know a lot of this stuff is contentious and has been for years, and I'm trying to do minimal but reasonably "correct" things within that framework rather than stir up those old arguments.
(16 Jul '22, 12:28)
_Hobbit
|
|
"I guess a related question is, can a relation be an "inner" of another relation and work correctly?" I think this is the root of the issue. In the context of OSM-Carto (the Standard rendering), the answer to your question is no. The relations for the ponds and golf course that you've added as "inner" on the In order for this to work, you'll need to explicitly add the member ways of those ponds and golf course to the Thanks, while thrashing around further I was becoming more afraid that was the truth of it. It's odd that a well-enclosed relation can't serve the purpose, implicitly pointing at all the segments as a group. Wouldn't that amount to less stored data overall? https://wiki.openstreetmap.org/wiki/Multipolygon_Examples strongly implies that an "inner relation" is kosher, and iD doesn't object to arranging things that way, so it's easy to be confused. What happens if an "inner" object penetrates the path of the outer one, such as a pond that's half surrounded by woods and half by something else? And what happens if an inner way component or two is missed, thus not correctly closing the inner loop? Is the entire thing invalid?
(18 Jul '22, 23:01)
_Hobbit
A well-enclosed relation can be a member of another relation. That's completely kosher and some renderers may fully support that. OSM-Carto unfortunately doesn't (at least at this time). If an inner crosses an outer, or an inner or outer ring are unclosed, that would generally be considered a broken multipolygon. If the woods only encompass half of a pond, you'd need to split ways at that point and "wrap" the woods around the one half of the pond's shore.
(19 Jul '22, 00:00)
alester
|
Hi, Please be aware that the Lynn Woods area you referred to in the prior question as a park, the outline of which is used in two different relations, being Relation: Lynn Woods Reservation (1153480) and Relation: Lynn woods (14356649). Both of these multipolygon relations have an outer border that is not part of the overall border. One multipolygon includes the large area of Walden Pond the other does not. So it is no surprise that the area does not render as expected. I think your first move should be to correct the multipolygon relations and remove one of them.
I'm never sure whether to "answer" or "comment" in these things, that's confusing AF...
There are two relations because one of them is the overlay one I'm trying to build. I want to tag it as woods, in one or both of the hotly-debated methods landuse=forest and/or natural=wood, and then carve the ponds and other non-wooded features out of it as inners.
Original "Lynn Woods" that I directly modified and then un-did because people objected: https://www.openstreetmap.org/relation/1153480 as I found it
New overlay where I'm trying to do the "right thing" and allow for further expansion of rendered woodland that exists outside the boundary: https://www.openstreetmap.org/relation/14356649 Note that "woods" is not capitalized in the name of this one for now.
Mostly, since others built the original Lynn Woods as the protected_area with its funny border and never had a protected_class, I cannot take responsibility for that.
I guess a related question is, can a relation be an "inner" of another relation and work correctly? I cannot find any information about that specific thing in the Relation wiki documentation. iD didn't object to it, so I assume it's fine.
When I look directly at relation 143556649 right now, highlighted in orange, it doesn't even show the inners of the ponds and golf course. Why? They're completely contained, wtf.
It's not a good practice to upload test data to the live database as this just further confuses any original problems. It would be good to remove the test data, saving it offline for further testing.
"test data"? What?