A sled-specific map, that would be a perfect user of this data; too bad it's gone.

Note that with the changes I made farther south, it isn't tagged the same as a park, but some renderers will display it the same as one. BTW, I just checked the latest openandromaps (which are outdoor-focused and work well in Locus Map, ditto), and with my tweaks, PS001 etc. do show up as protected areas there. These are maps a sled rider might carry in their phone.

Your call. Feel free to undo my changes to PS001 etc. farther south (or ask me to) if you feel these areas don't belong on standard maps.

Cheers,
VP

Hi Scott.

I came across these polygons while editing in the area, also some similar polygons farther south while editing a few months ago.

Do you find these polygons serve a purpose in their current state? I ask because they don't render on the standard map, and I'm not aware of any map where they *would* render.

For the polygons farther south, I've taken the liberty of adding a few tags, eg boundary=protected area, and now those are indeed more visible. For example, relation/7550130/history

If this makes sense to you, you might like to consider similar changes to the polygons in other areas, such as here.

Note that I'm reluctant to use the "name" tag for something that more truly is a description, and I'd been unable to find any official names for the areas I'd modified down south.

Cheers,
VP
Alberta mapper visiting BC. :)

Hi alester. Greetings from Alberta.

Do you still feel leisure=park is most appropriate for these areas? I'm inclined to think, boundary=protected_area, possibly also leisure=nature_reserve, with protect_class=5, 7, or 21, for all three of which the wiki mentions recreation.

The current definition of leisure=park suggests open city-style play space, somewhat at odds with forests and even glaciers. It's always bugged me a bit, seeing "parks" on glaciers.

I've been mapping in BC lately, and - if you're in agreement with this - would be happy to change these over. What do you think?

PS, it should also be connected to any streets it touches, for proper routing. EG, at the south end in this case.

Hi JdP11.

Did you notice there was already a cycle path here? Now there are two, but I can assure you - as I've ridden it a few times - there's only one, shared by pedestrians and cyclists.

If you consider this one more accurate, you might want to delete the other. Cheers.

Hi Rps333.

Weird, isn't it? The name of the lake you added here (which is correct according to CanVec, a source I actually trust for names) doesn't match the name of the provincial park surrounding it - which I added straight from the provincial source.

You probably wondered the same thing. Anyway, no action required, except maybe a little head-shaking. (I noticed this while map-surfing instead of doing something useful.) :)

I removed them. In JOSM, search "ele AND type:node AND -child", manually select all but peaks, delete.

It's detritus from raw-GPS imports, and I clean this stuff up as I see it. Need caution, though, to avoid deleting peak nodes that actually display, but the rest are just clutter.

You removed oneway=yes from Cloverdale Hill?

Sorry, I put it back. Sign says/said, it's a permanent change. My note tag repeated that detail.

Hi AG.

Are you sure about the name "Scona"? I searched the Edmonton website, and found virtually no references to that name, other than "Scona Road". Also, I found no references at all to "Scona area", which sounds like a made-up label.

Unless something's changed too recently for the search engines to know about, I'm pretty sure the name is "Strathcona".

Also... Are you sure it makes sense to tag a "town" within a "city"? I searched the wiki but found nothing to support that.

I also have my doubts about "Avenue District", which likewise isn't findable on the Edmonton website... These names jump out at you at low zoom.

One change per changeset?!? Bloody inefficient. I'm done with this app.

Was originally misspelt, still is, sorry.
https://locations.timhortons.com/ca/on/toronto/3075-danforth-ave.html

I can guess. The grocery store likely has a "Tim Hortons" (no apostrophe) coffee shop inside; they're everywhere in Canada.

As is, of course, it's tagged incorrectly. If you're willing to assume it's still there 10 years later, feel free to fix it up.

I still think natural=shingle is most appropriate, but I'm not willing to brawl over it, or change what you've mapped. :)

Riverbed has little more than a wiki mention to support it (no rendering I know of). And note, the picture on the wiki page for shingle natural=shingle does look like it could've been taken in the Rockies anywhere.

But one thing I just realized: Intermittent water renders mostly like water (and exactly like water with some renderers). But 99+% of the time, that ground looks like "not water", so choosing something that renders closer to "not water" should be more accurate. No?

Anyway, in the end, your call. Cheers.

Correction, as I remember now, CanVec has used "beach", equally wrong.

Ah, interesting. I hadn't noticed "riverbed" before. But I see it's only rarely used, and thus few if any maps would render it.

In my experience around the Rockies, "shingle" seems suitable given the surface is generally rounded rocks of various sizes. CanVec imports have used "sand", which is just wrong.

Here's a shingle example: osm.org/#map=17/50.96091/-115.08901

Cheers,
Tom / VP

Hi badenk.

I see that in various places (like here), you're marking braided rivers as intermittent=yes. May I suggest natural=shingle as perhaps more accurate? Thank you.

Hopefully this is unrelated (because I don't want to get involved in this...)

Because JOSM complained after I did a minor fix to the river inside Jasper town, I added natural=water (it was missing) to a long section of the river, to correspond with the water=river tag. Don't know if that affects this discussion at all, but thought I'd better mention it. way/712606179

Also missing an apostrophe.

But a rectangular hole in a sea of green would count as "wrong data", no? At low zooms this suggests missing forest, which isn't the ground truth. This "wrong data" would be worse than "bad import", to use your hierarchy.

It would be great if you and your friends could stop nuking CanVec without at least replacing it with something - even coarse would do - to replace it, so the net result would be an improvement.