How do I tag this grass so it shows properly?

If someone could help me please have the grass areas (in screenshot) so the wood doesn’t overlap it, that would be appreciated.
Also, if it could be explained how I can do it next time. Thank you.

2 Likes

Here you go:

This kind of situation calls for a multipolygon. This page has instructions on how to create them:
https://wiki.openstreetmap.org/wiki/Relation:multipolygon

1 Like

Wouldn’t that be kind of mapping/tagging for the rendering? At the end of the day something is either a wood or grass, you can’t really have both in the exact same area regardless of someone wants to pretend you can by mapping a pointlessly large wooded area over a field. Maybe I just don’t understand the point in relations, but it seems to me like that’s not their purpose. Like in this case the field could just extend the extra 2 inches to the water area since that part of the park isn’t wooded anyway, instead of needlessly making the whole thing a relation just because the grass area is arbitrarily mapped on the left side of the path when it doesn’t really need to. It’s pretty obvious from the images that the “wooded area” is part of the bigger woods on the right side of the waterway though and don’t take up enough of the park to justify mapping it the way it’s currently mapped.

1 Like

I find what you’ve written somewhat unclear, but I think the gist of it is that it looks to you like the grass extends all the way to the water, making a multipolygon unnecessary. I took another look at the aerial imagery (NJ 2020, Esri, and Bing), and I don’t see any place where there are no trees along the water. In some spots there is only a thin strip of trees, and it certainly could be that this isn’t really woods/forest, but instead it’s a row of trees with grass growing underneath. I cannot tell from the aerial imagery and I haven’t been to this place in person, so I will leave it mapped as is. @Wild_Spike, if you have on the ground experience at this location and can confirm that the grass does go all the way to the water, then @Adamant1 is correct and a multipolygon is unecessary. Instead the woods can be split up into smaller polygons and any thin strips of trees that aren’t thick enough to be woods/forest can be mapped as a natural=tree_row instead.

1 Like

What part of it wasn’t clear? From the rest of what you wrote it seems like you got the gist of it perfectly fine :man_shrugging:

TLDR though: The point in relations isn’t to make things render properly on the main style. Which is how they are being used here.

There’s a thin row of trees along the park of the creek that are essentially in the creek bed, which can can be seen on the Bing Maps. It’s not a wood though and it ends where the creek meets the grass, which is also where I assume the park ends. What is being mapped in the meantime is the foliage from the trees that is only hanging over into the park during certain parts of the season. You can it pretty clearly in the Esri World Imagery (Clarity) Beta images. The creek is clearly part of the wood, but the two or three inches that the area for the woods goes into the park is just grass with a couple of plush tree branches slightly overhanging it due to the season the images where taken in.

Like as an analogy, I have a smallish wooded area behind my house where a few branches over hang a road if it’s the right season and no one has pruned them for a while. The wood is obviously a wood, but the road clearly isn’t a wood. Even though there’s a small amount of tree cover encroaching on it in some of the satellite images. In this case whatever trees in the creek bed should just be mapped as part of the larger wooded area that contains Spring Valley Lake. There’s zero reason it needs to be a separate wooded area.

I found the whole thing confusing, but yes after rereading it multiple times I basically got what you were trying to say.

The multipolygon relation here is being used to model an area of woods with a field cut of of the middle of it, which is what it looks like to me. This is exactly what a multipolygn is for. I understand this isn’t what it looks like to you and that’s fine. Please feel free to remap it in a different way!

2 Likes

I don’t have a problem with that. The reason this discussion was started though is because the original poster didn’t like that the woods rendered over the grass and that’s what I was responding to. Not the justification you came up with after the fact as to why it was OK to map it as a multipolygon relation, Although I will say that everything is “cut out of” everything else. So I don’t personally find that to be a valid reason to turn something into a multipolygon relation. At least not on it’s own and in this case where the grass can just be moved to connect with the creek instead. The Wiki says Multipolgyon relation’s are for mapping “typically complex areas with holes inside, or consisting of multiple disjoint areas.” I don’t think this is super complex and it has nothing to do with multiple disjointed areas either. Therefore, it doesn’t fit the use case. That’s just my opinion though. I’m not here to tell you or anyone else what to do, obviously.

I rather not. I’ trust the person who mapped it originally knows what they are doing or if not, that at least someone closer to them will “correct” it. That’s not really my job though. I’m simply here to give my opinion about it. Obviously they are free to take it or leave it however they want. If their main concern is making the woods not render over the grass then they are clearly going to ignore it. And I don’t really feel like getting an argument or edit war over it. I’m sure someone else will come along and “fix it” at some point anyway. Or not. I don’t really care either way though :yawning_face:

I know this place. The wooded area runs along the southern point, up the side of the river, and back to the parking lot. The grass does not reach the water and the footpath goes through the tree area. The trees are not planted alongside the river. They are natural from the cutout of the field.

1 Like

What I found strange here is that amenity=park overlaps natural=wood and landuse=grass areas. Usually, park areas are clearly delineated and possibly fenced, and then may include natural features for more detailed mapping. But upon some research, this park seems to have been created by designating a part of a pre-existing natural landscape, which was then further upgraded by paths, benches and like. So I don’t think there’s a cleaner way to map this. (Shoehorning a boundary=protected_area would hardly fit).

There actually is. Except it doesn’t seem like with how things are because the current area for the park’s boundary is incorrect. IRL it crosses the creek in several places. If it was mapped that way instead of being completely random then the rest could definitely be mapped cleaner. Same goes for the northern boundary of the park, which isn’t mapped accurately either.