Wrong. The road was split by the river, a washout not worth the trouble to repair.

I was there. You weren't.

Version 5 looked the most correct. man_made=pier, waterway=fuel. (I never knew about the latter.)

No. Try man_made=pier instead.
osm.wiki/Tag:man made=pier

This changeset:
changeset/108779287
relation/1513365

PS, I fixed it.

Hi Lizzy.

When editing forest polygons, please make sure they pass validation before uploading. You left an inner member overlapping the outer boundary, which resulted in a large white rectangle (broken polygon) in an otherwise green area.

It's also a good idea to double-check the map afterwards, to ensure everything renders as intended.

Thank you, and happy mapping.

Example: way/914029246

Hi Hendrikklaas.

Why do you consistently NOT load existing data for an area before adding stuff? Here, you've duplicated your own effort, and added landuses, overlapping almost-identical ones that you added earlier.

(If you see a polygon breakage, that's unrelated - unless you map under different names - and should already be fixed.)

Hi <KC>.

You deleted a pedestrian level crossing across 170 Street, that I added to OSM, that the city built as a temporary replacement for a removed bridge, that does not appear on imagery.

I have put it back. It is a very useful detail when arriving by foot or bike.

Please adjust your procedures to double-check the validity of items you wish to remove. Thank you.

Also source=Geobase Roads for correct road names, survey.

Hi Fracture98.

Sorry, I've had to revert this changeset, as it appears to have broken the river polygon all the way to Saskatchewan.

The river-area relation needs to be of type multipolygon (and have no name, as that's already on the waterway down the middle). Note also that separately, there's a waterway relation gathering together all the waterway segments down the middle. Unrelated to the river-area polygon.

Until you get more comfortable with relations, I'd recommend double-checking afterward that things still look right. Cheers.

The exception I would make (and have done on occasion) is if there's signage explicitly prohibiting access, and/or a locked gate. In this case, access=private.

But simply "Private Road" signage does not mean, in practice, keep out. In this case, no access tag.

(Replying to PM'd reply...)

The local mapper you discussed this with, and I, have slightly different interpretations. As best I can tell, these (typically all) oilpatch roads are on public land, with private infrastructure at the end, with private maintenance, but general public allowed to pass - for hunting, camping, etc. Thus, I would remove the access tags, and will here since you indicated you're okay with that, thanks.

Besides, access=private would likely break routing for the most common user, oilpatch workers.

Wrong comment. Should be: added island and ponds.

Hi. No worries; just wanted to point out the ambiguity on paved-ness in general. I regret not being explicit earlier when adding roads because now I'm cleaning up after myself.

Tertiary here was a judgement call on my part. Little traffic, yes, but it's fairly long and serves a handful of destinations including a semi-significant trailhead. Cheers.

Hi yegbin. I assume it was just inadvertent that you removed surface=unpaved from the tertiary road.

I've noticed some renderers seem to assume paved for unclassified, and thus would for tertiary too. (I've added hundreds of simple highway=unclassified over the years, then had to go back and add surface=unpaved because the results looked so goofy.)

Hi Hendrikklaas. You've added many oilpatch roads here as access=private. May I ask, how do you know this?
From my local experience, these roads are usually open to the public (being on public land), though signage occasionally indicates a private road (privately maintained) meaning access arrangements are required for commercial traffic only (meaning, to help pay for it).

Routing won't work if these are incorrectly marked as private. Thanks.

I meant former, not latter.

And since both forms are legal, this isn't the dreaded tagging for the renderer, which deals in false tagging. This is a bug workaround.

Hi ec90.

Caution please, when editing relations such as these forests. I highly recommend double-checking after the fact, that your changes render as expected.

Here, you added two lakes, but added them as inner members (good) of the wrong relations (oops). In the case of one, it straddled the forest outer boundary, breaking that relation and resulting in a large white rectangle - which caught my attention. I've fixed it up.

Happy mapping,
VP

Also source=survey.