OpenStreetMap logo OpenStreetMap

Changeset When Comment
73804929 over 5 years ago

Sounds reasonable, thanks.

BTW, there's also "River Valley Area", which is an odd name I've never heard used, and which - due to the extended length of the snaking park system along the river - gets rendered on one of my maps prominently in ... Parkallen. Technically correct - centroid of the river - but misleading much like those widely separated aboriginal_lands. A possible solution would be to label individual parks, which I think we do, and label the uber-park as something else.

Anyway, not my area, so just some thinking out loud. Cheers.

46982991 over 5 years ago

Great job on the trail system!

85970679 over 5 years ago

Done, thanks!

85970679 over 5 years ago

Hi TokyoJoe.

Where does the "Stafford Lake" name come from? Your changeset doesn't say, and this is version 1.

According to GeoBase Hydrography, the name is "Chin Lakes". I was going to change it, but realized you've edited it quite recently.

72951664 over 5 years ago

PS, OAM added aboriginal_lands support on my suggestion, after I noticed how they've popped up all over AB, likely all your work. OAM is pretty sweet for this and a variety of other reasons. :)

72951664 over 5 years ago

Is role=label a supported tag? It sounds familiar, but I haven't used it.

Unfortunately, the only renderer I know that puts the label at the centroid is an offline one, openandromaps, with updates only every few months. If you know of a pre-existing role=label in Alberta somewhere, I could check quickly because I have it already downloaded.

Of the online maps I'm aware of, most put the label on the largest member, as you know. Opentopomap.org puts it on every member, at least with lakes. There doesn't seem to be a standard for how to render the labels, not that I've seen anyway.

86373543 over 5 years ago

Hi. While you're in there, you'll probably want to make the parking lot an inner member of the surrounding wood relation. That'll remove the trees.

72951664 over 5 years ago

PS, the effect is noticeable with OpenAndroMaps which use the centroid labelling style. It looks perfectly reasonable when the related objects are close together, eg Headwall Lakes. (The OSM standard map seems to choose the largest object and put the label there.)

72951664 over 5 years ago

Hi AG.

Might I suggest, for aboriginal lands that are scattered far apart but have some logical connection, such as relation/9442907 , not using a relation to group them? This causes some renderers to, logically, put the name label at roughly the centroid of all the elements. In the case of the example given, that's roughly 100km from the nearest land it applies to. Rather confusing.

Another example that jumped out at me: relation/8438227#map=10/54.0800/-111.0687 .

On the map, you see the label, but no shading anywhere nearby to represent any aboriginal lands. Where are they?

At the cost of a bit of duplicate tagging, I'd suggest dropping the use of relations unless they're effectively adjacent. Thank you.

85895740 over 5 years ago

May I suggest removing name="Private Road", as that's not a name? The access=private already covers that. Thanks.

85860964 over 5 years ago

Hi. @Arctic%20gnome appears to be the local boundaries expert, so I usually leave this kind of stuff for them. You might try pinging them directly to see if they know about the change.

Worth mentioning: even though municipalities sometimes proudly pronounce themselves "city", that doesn't make them city by OSM standards; the wiki has rules about that. (Edmonton has too many neighbouring "cities" on the map, but it's a battle for another day.)

85769914 over 5 years ago

Feel free. Actually, people watch changeset comments (there's a tool for that too, http://resultmaps.neis-one.org/osm-discussions?c=Canada , so if you're not sure about something, ask about it in your own changeset, and someone will probably answer.

Happy mapping,
VP

77347678 over 5 years ago

Done. I actually cycled past there yesterday and confirmed it's standard gauge, or at least not narrow or miniature.

85769914 over 5 years ago

It looks correct to me. Changes don't show up immediately, as you might know, but for me the removed section is showing as gone, at least at some zoom levels. Later the other zooms will catch up.

BTW, you can review your changes with this handy tool: https://overpass-api.de/achavi/?changeset=85769914

77347678 over 5 years ago

Hi. You changed rail at Fort Edmonton Park from railway=preserved to =miniature. This is a historic park, so I doubt it is truly miniature (narrow gauge). I expect it would be the gauge used historically.

Could you please confirm? Thank you.

83087447 over 5 years ago

PS, CanVec is a bit verbose when it comes to mountain range names, probably due to them being on both sides of their map sheet boundaries, something we no longer care about.

I would keep an eye out for duplicates, quadruplicates, etc, and thin out a bit.

83087447 over 5 years ago

Oh lordy, still CanVec...

Are you familiar with natural=mountain_range? This should be used instead of natural=peak when it's not really a peak.

node/7368067959
natural=mountain_range

My favourite renderer does support it, and handles it well.

Thank you.

83805941 over 5 years ago

Uh, while on the subject... How does wee Beaumont qualify as a "city" by OSM standards? Remember, we map to OSM criteria, not political ones.

place=city

"Largest settlement" is Edmonton, not Beaumont nor the other burbs.

83172953 over 5 years ago

May I suggest a little more experience with OSM before getting into reverting changesets, AND even when you do, explaining the reason for reverting something. Thank you.

83174074 over 5 years ago

I'm too impatient to let a blunder this prominent sit for long. I've restored the relation to an earlier state. Removed natural=water (there's your problem!), removed golf=water_hazard (what?).

As usual, zoom=12 or lower will take a while to render correctly. It looks like an island again at zoom=13+.