Sorry about that. Must have had a brain explosion.

Hi, not sure which area you're referring to but I have been sometimes making relations (without holes) where there are a number of close areas that have a geographic connection - the advice on the OSM wiki calls these enclaves and doesn't discourage it. Note sure if that applies to the area you mention.
I was using 'grass' but now realise that has quite a narrow definition. Now using 'grassland' for something approaching a natural landscape or meadow for more agricultural pasture. Any advice for all the areas under power line easements? They are regularly cut back to a grassland state, but are not natural or pasture. Landcover=grass seems to be discouraged by the OSM wiki.

Thanks, the area=yes is a carryover from using the iD editor (create an area, add it to a relation, delete the area=yes tag) and forgetting to delete the 'area=yes' tag. In iD this is an efficient way of adding a closed way to a relation, but I sometimes draw a closed way instead. Depends on how big I think the area will be.
Does it matter if an isolated outer way is made part of an adjoining relation? I hadn't really thought about it being a problem, so long as the areas were close by and actually had some sort of geographic relationship.
I usually use DCS for the resolution but it is sometimes very indistinct for tree vs scrub areas, and Maxar can be better sometimes.

Hi, OSMI is showing ring not closed on way/1029600990 after a change yesterday and I can't see why. Not sure if it is related to the relation I originally set that up for that Meadow area.
Andrew

I'm guessing that my comments are specific to the iD editor. I'm not familiar with JOSM, but in iD when the 'area' tool is used to create geometries only the area preset tags are available (eg "natural wood" creates a natural=wood tag); likewise only linear tags are available with the line tool. If the line tool is inadvertently used to create a closed way and area presets are required then it has to be first converted to an area by adding an area=yes tag. The end result is the same as it looks like the area=yes tag disappears once the area feature is assigned (unless its part of a relation, it seems). See this issue thread: https://help.openstreetmap.org/questions/27594/can-you-change-a-closed-line-into-an-area

I sometimes start an area with a line and then want to convert the finished closed way to an area. The quickest way is to add the area=yes tag AFAIK. Which seems to be okay unless you then add it to a relation. iD warns by marking the internal of the way gray - and I didn't realise why until you just pointed it out.

How did you find those errors? I can't see how OSMI shows them and an overpass query for area=yes only shows a few that aren't in that changeset. (I am an expert at neither)

Hmm, I'm confused. Not sure what I did to 'change' Putty State Forest. Sorry about that. Was it caused by adding an inner area to its relations? Or maybe by the self-intersection I created (now fixed).
What I wanted was for the cleared area to be shown as 'grass' cover (although it should probably be 'meadow') and Putty State Forest 'Managed Forest' seemed to be the right relation for this area to be the 'inner' of. I have now found the much larger 'wood' that encloses all of this huge area and related the areas to that.
I need to learn JOSM, iD is lacking in showing any relations that aren't on-screen. the larger 'wood' never appears in iD and I mucked up the whole of the northern 'wood' of this region when I inadvertently dissected the internal 'wood' boundary you added a few years ago. iD did not show that boundary as it has no nodes in the on-screen area and reported no error.
PS I probably would have eventually found the error you picked as I've been checking OSMI. The delay is problematic though.

Hi, I'm interested in mapping power distribution networks and wondering what source you are using for many of the power line routes you are mapping. Thanks, Andrew

Local knowledge always wins. Not sure how that mistake slipped through. Aerial images show unpaved but obviously out of date.

I didn't realise that was a thing. Is that bad? Certainly guilty of obsessing too much over detail and need to set myself a limit. The infinite zoomability of OSM doesn't help.
Error fixed. Thanks.

Yes, I am improving though. I think. I seem to get stuck when I'm adding new land cover detail to areas that over time have become a mixture of tagged closed ways and relations.

I think I've fixed those problems. I will check with OSMI tomorrow to see if I've added any new ones.

Thanks!

Now deleted altogether. Decided it was too big a task to map the entire boundary given my (lack of) experience.

Thanks! I don't know what happened here. I was attempting to fix a very messy set of stream areas from a previous version.

Thanks for all the tips! Heading to the big smoke for a few days so won't get a chance to think it all through just yet.
Cheers,
Andrew

Hi @WoodWoseWulf,
most likely inadequate expertise and I've probably missed some basic understanding of closed ways. I can see your point, relations did seem really messy for that example, but I haven't found any reference material on which approach to apply when. Is it just a case of 'scale'? What are the ‘cons’ of closed ways? I’ve redone the park (and swimming area) as closed ways, and merged some of the split ways. Is this now correct?
So, I also did this for all the residential area of Mannering Park. I was motivated by what a strict urban residential area map looked like with wood areas shown, even when they overlap the residential areas (also because I grew up there). The previous version had residential as one closed way within the bounds of the Lake and no 'wood' areas at all. My strategy, in the absence of better knowledge, was to:
1. use the DCS base map to define residential areas strictly, with those that go to the lake edge separate to the areas that don't; splitting the lake edge line at the points where the residential meets the lake and create a relation there. This does look clumsy as I didn’t apply the correct road/residential area interpretation everywhere.
2. similarly for land cover, I have created a way for the landside edge of lakeside woodland, even if it overlaps residential, and joined it to the Lake edge with a relation. (I thought I had done a similar thing along Dora Creek, but this renders differently, so probably not).
Is this all too dodgy?
Much of my experience so far has been defining the natural areas around where I live (Awabakal NR, Jewells Swamp, Belmont Wetlands SP) and relations seemed the best approach (modeled after Glenrock SCA). I have never been sure how to properly map the overlap between natural landcover and human landuse though.
Thanks for your feedback. I am certainly a beginner and open to a better standardised approach if you can advise or point me to a resource.
Andrew

Hi @Warin61, I created it as a boundary to the 'natural' features of that area (as against the admin) thinking that would help fill in the details for the many natural land covers. Since realised that is not needed to do that, and have deleted it.

Thanks @WoodWoseWulf! Was wondering why the renders were leaving out the water. I'm still learning how all this works, but was pretty sure iD didn't report errors on upload. Should it have on such a big relation as the lake itself? Andrew

Thanks! Still much learning to do.
It was originally two closed ways that should have been one and I didn't know how to combine them again so (as I recall) I just joined them on a shared line and clearly got the roles wrong. I have since learnt how to join areas correctly (I think).
Is it wrong to have abutting closed ways with identical tags? I am doing this when there are huge areas to help manage the large number of outer ways (the 'scrub' areas 5km south of here are in three parts)?
Is there a tool I should be using to find these sort of errors? Andrew

Thanks Scott. I was trying to understand how relations behaved and intended to delete straight away. I wasn't aware of sandbox and will use from now on.
---

Published using OSMCha: https://osmcha.org/changesets/114039355