That’s an interesting point about those other disputed territories. I think it would be good to come up with clear guidelines about what constitutes de-facto control. I suspect that (as per OSM policy) those other disputed territories should be autonomus regions.

I’m mostly familiar with “designated” in the context of bike trails. Often these designations aren’t official because there’s no official body responsible for them. The wiki page does say “typically by a government” but I think this is a case where ground truth is more important.

Personally, I think lgbtq=designated is the best. Designated (at least in the access tags) doesn’t necessarily mean that it was designated by some official body, just that that is how the space is used in practice by people on the ground.

My main concern would be that LGBTQ is too broad of a designation (what if there are gay-specific bars, or trans-specific bar) but I don’t know much about the community to know if that’s realistically an issue.

for a small percentage of the population Google can just mean the Internet

“the internet” is a pretty vague source. Ideally, sources should be a lot more specific than that.

I find it suprising that sexual orientation and gender identity issues would be a thing. I mean, how would anyone know if you were a homosexual or a transgendered person. I guess I’m probably being a little naive, but it should be pretty easy to hide behind the pseudo anonymous nature of OSM.

I mean, this should be true to a degree about racist and sexist issues too, though I could see those things being accidentally/intentionally made public a lot easier.

Ultimately, spliting up a large body of water into smaller ploys is a violation of “One feature, one OSM element”. Historically, this principal has often be waved because the editors just were really quite bad at dealling with large ploys and multipolgons (hence “tagging for the editor”). However, the situation has improved a little bit, and as it improves, I expect the principal will be more closely adheared to.

Honestly I think falls into the same sort of category as tagging for the renderer. It’s a little different becaues large polys are actually a PITA to edit sometimes, so maybe it’s more accurate to call it “tagging for the editor” sometimes.

At any rate, whether a map wants to show small features at low zoom levels is entirely a question of map design. I don’t see why all those lakes should necessarily be mapped into a large multipolygon. With rivers, it makes sense to have one large multipolygo for the whole thing. But for a collection of small lakes, I don’t get it.

It seems really weird that anyone would find this difficult. You

1. create a poylgon
2. choose it’s class (tags) on the left
3. press “s”

The only time it doesn’t work is if you are trying to square something where the angles are too far off. I think the reason you have to do 2 before 3 is that typing “s” at phase 2 will filter the tag groups. Also, 2 is significantly more important than 3 (what good is a tagless rectangle?) so I think the ordering is fine.

I think the rule of thumb is that anything that is public (and relatively static) can be mapped. Secret things should not be mapped and private things should only be mapped if people with access to them choose to do so. The reason for this is quite practical, private and secret things aren’t verifiable and things on the map need to be.

That said, I think the existence of the military landuse in question is public knowledge and so it totally can and should be mapped.

For what it’s worth, the large number of gps points that strava has is great, but the consequence is that it does result in sharp details of a route getting smoothed out. It’s much better than a low quality gps trace, but I’m not sure how much better it is than a good gps trace + some local knowledge.

Some of these are deeply confused parts of OSM itself. The tag landuse=forest has completely failed at reaching any standardized meaning, and it’s as far as I know, its presence is mostly a consequence of a few imports and confusion by new editors.

Footpath and path are confusing, and that has history behind it as well, since footpath is an older tag, but path does a better job of describing a wider ranger of possibilities (path + foot=designated is the same as a footpath).

Nature preserves and parks are also a little confusing, and I think until recently the schema was in flux, not sure if it still is.

Interesting. My brother and I had toyed with the idea of something vaguely similar (but more complicated, basically an app to track where parking tickets were/weren’t being enforced).

Does it actually use the OSM data to find parking spots, or does it just look for where other people have parked in the passed and suggest those locations.

How do you (or do you) deal with GPS inaccuracies that are common in underground parking & areas with lots of skyscrappers?

I’m well-aware of caltopo, and it’s pretty useful in the US where its default basemap shows forests, and where you have access to the impressive USGS topographical maps. In British Columbia, OSM is just so much better than the alternative maps (with some exceptions every now and then) that I usually don’t bother.

The slope angle feature is nifty, though as far as I know it doesn’t show run-out zones.

Service roads in OSM and Forest Service Roads in North America are entirely different beasts, in my understanding. The confusing naming is unfortunate, and you can probably blame the Brits for it :P

iD has validation checks, they’re just relatively simple (like unmarked ways, and points without any tags). I think its validation features should be enhanced, but probably not too much (we really don’t want people to start faking data just to pass a validator).

In theory, it would be nice if everyone could JOSM, but it really sucks with high-DPI screens, and it’s only user-friendly if you already have a fairly solid understanding of how OSM works, which is a total no-go for most people who are not armchair mappers.

Has this been deployed to the servers yet? I’m still running into problems with intermittent stream rendering.

Regarding addresses, if a building has only one address (and the address is only for one building), I typically put the address on the building. However, if you choose not to, there’s nothing particularly wrong.

I was a little annoyed previously at all of keepright’s false positives, but actually, if I’m willing to sort through a few of them, there are a lot of really useful errors being caught.

@ff5722: theoretically a great idea, but how would you keep the spammers from just making a garbage changeset first.

This really depends on what you’re up to, but on things like back-country trails I often find it very helpful to know things like trail_visibility & sac_scale.

There are certainly a lot of ways that have superfluous tags as a consequence of import scripts though.