I’d agree with Cyrtin that using highway areas in this fashion is inappropriate. The very fact that additional tags have to be retroengineered to avoid disrupting routing is proof that this is improper

In the opposite direction, I think it wholly inappropriate to crisscross highway=footway on top of something already tagged as a footway area. It manages to simultaneouly bevisually horrendous and geographically inaccurate.

Sadly, there is no system, not even a de facto one, for mapping extremely broad steps such as those at the southern end of Трг партизана. My personal solution has usually been to use a barrier=steps on either a line or an area. The former can be used like barrier=kerb and works especially well when one or two steps clearly bisect a footway area, the latter is messier as there is no easy way to indicate directionality for areas…

Personally I’m not a huge fan of mapping paved areas between buildings and the road, but this is kind of a rock-and-a-hard-place issue rather than an accuracy one. You see, when those areas are mapped, it becomes increasingly difficult to quickly select the desired feature in iD because all edges are joined and overlapping at all points (thankfully this is no longer an issue with borders, but I’d rather we not start doing relations for everything as a solution!). However, I reserve fear greater amounts of loathing for the practice of mapping sidewalks as footway lines… which is also done here at the same time!

Of course, what really on is that a) no sane tagging scheme can encompass all possibly status designations and level (the USNPS alone has units of over 20 different designations!) and b) these systems were originally drawn for European countries where only the national government can make protection designations whereas, as you point out, federal systems (and even non federal: I believe Brazil has state-level natural parks) can have state-level parks with the same degree of protection as national designations (Germany, Switzerland and the UK do not have, as far as I can tell, any system for designation of conservation/natural areas of any sort at the subnational level.)

Unless I were doing specifically 3-d building mapping, I wouldn’t concern myself with the roof, as here it seems to me like just a somewhat more elaborate eave. If I were, I’d just use either building=roof or (more likely in this particular case) building:part=roof with the appropriate 3d mapping and layer tags.

One thing is that Multilingual requires the locations to have actual different names in different languages, and the number of prominent places where this would come into play are so small that there is very little arguing (and since they are prominent, people are well aware of the language differences, the few I’ve checked were all appropriately tagged). Small places rarely have different names in use, so the result is that most places have the same name in both languages. Indeed, if the name tag didn’t have to bother with the feature type, (“mount”, “river” etc.), the issue would be almost nonexistent (formally, though not for OSM, Churchill RIver is considered the same in French because “Churchill” doesn’t change whether you’re talking it in French or in English).

What feature to tag with the name (e.g. with the St. Lawrence River) seems more likely to be problematic.

@SomeoneElse

Actually, it’s located here.

My pet theory is that a lot of those are in fact historical placenames. The data used to be, (dunno if it’s been cleaned up…) polluted with thousands of historical, now invalid PoI for old schools or places of worship…

Sounds like it. With a description= tag noting how this is (as I understand from your post) an actual hazard.

The problem is that relation-based boundaries cannot be rendered in a way that guarantees all the ways of the same admin_level will actually look the same. Bot to mention that you end up with a whole bunch of ways in the database with no tags actually indicating what they are.

The result is that a significant portion of the world’s boundaries render poorly because of bad tagging.

Boundary relationships are a good thing to have, but using them for rendering turns out to have been a less-then-ideal decision.

There’s something weird going on with California, though. Why is LA county bordered at the maritime state boundary, but (AFAICT) not Orange county?

“there is very little markings within OSM specifically for laying out trails meant primarily for offroad vehicles - Quads, trikes, etc.”

OSM assumes most “highway” are useable by motor vehicles, on foot and bicycle. Access tags should not be overlooked when dealing in this area! highway=track+access=no+ATV=yes

The only reason the ATV tag has not gained much attention is that all-terrain vehicles are little used overseas, but that doesn’t mean that the basic rule of “when in doubts, use whatever new tag you think fits” has lost validity! (worst case, if another use become dominant, your original tagging will be changed to that other tag later on)

Moi j’en ai (peut-être) une: La loi de Benford est connue pour s’appliquer aux adresses. Puisque les numéros commençant par 1 sont au final 7 fois plus nombreux que ceux commençant par 9, j’imagine qu’un plus grand nombre de 10 que de 9 n’est pas si surprenante, quoique moi aussi la raison en cause sur le terrain m’échappe.

Je suis bien d’accord concernant les bureaux de votes: de toutes façons, ce ne sont pas plus des éléments ni permanents ou même semi-permanents (du moins en Amérique du nord). En soi, cela même est suffisant pour les disqualifier entièrement!

Je croyais que la limite c’est “ce qui existe sur le terrain (sous entendu au dessus du sol) de manière visible”? Avec certaines incursions dans les trucs comme les frontières (car elles ont un impact et une certaine présence sur le terrains, même si ce ne sont pas nécessairement quelque chose de directement visible). En ce sens, les “zones de risque” et autre “zones de couvertures” ne sont pas valides car pas représentatives de trucs présents sur le terrains (contrairement à disons, un emplacement de caméra ou de hotspot wifi).

Two keys have been introduced (though their acceptance is unclear), which can (presumably) use the :language extension forwhat you want todo: taxon and habitat.

I'm regfering to diary entries, not the map XD

I completely agree about the usefulness of indicating postcodes, but I am dubious about the necessity of giving them separate relations when they are identical to an existing one. Just changing the boundary type would fix the problem, though. boundary=postal would likely be sufficient. After all these will almost certainly never be displayed on the default OSM map, so whatever value is chosen really doesn't matter much.

The US postcode is free, but IIRC, the USPS does not sell an actual complete version of it (private companies do, or try to, however).

"The ability to add extra nodes on a way is very useful, somethig Potlatch cannot do."

What the hell are you talking about? Maj+Click is easy as pie :p

Scratch it to my idiocy: I searched and searched and couldn't find the damn thing. I'll investigate further another time.

As a side not, the "US-78 US-29 GA-8" information would be put in the ref= tag.