NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

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?

asked 16 Jul '22, 06:22

_Hobbit's gravatar image

accept rate: 0%

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.

(16 Jul '22, 08:07) BCNorwich

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: 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: 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.

(16 Jul '22, 12:19) _Hobbit

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.

(16 Jul '22, 12:37) _Hobbit

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.

(17 Jul '22, 08:03) BCNorwich

"test data"? What?

(17 Jul '22, 13:43) _Hobbit

If I'm understanding your question correctly, putting aside any other technical mistakes, this is caused by landuse=forest on the =nature_reserve. It has been considered as synonymous with natural=wood for tree areas due to disorganized use. Therefore it is usually rendered the same as natural=wood as tree areas. This tag should be removed.

Secondarily, boundary=protected_area needs to be used on a type=boundary, meaning there is a conflict with =nature_reserve as a type=multipolygon. Since =protected_area itself has some problems, and you are not determining its protected_class= or iucn_level= yet, I suggest you remove it as well, keeping it as a type=multipolygon + =nature_reserve. (it is technically not correct to use type=boundary + leisure=nature_reserve although this is the most common representation, like how place=city is often redundantly added on the boundary=administrative)

permanent link

answered 16 Jul '22, 09:02

Kovoschiz's gravatar image

accept rate: 16%

edited 16 Jul '22, 09:05

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 natural=wood relation will not be considered when rendering the trees. That's why you see trees rendered across the entire area.

In order for this to work, you'll need to explicitly add the member ways of those ponds and golf course to the natural=wood relation, specified as inner or outer depending on whether they need to be cut out of the wood relation (the water, inner) or included (the islands, outer).

permanent link

answered 18 Jul '22, 19:44

alester's gravatar image

accept rate: 28%

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? 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

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 16 Jul '22, 06:22

question was seen: 987 times

last updated: 19 Jul '22, 00:00

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum