bushmank / osm-tagging-issues Goto Github PK

bicycle=yes and foot=yes are used in wrong meaning. These are legal access tags, while people are using them to indicate, that certain path is passable by foot or bicycle. Wiki contains warnings and explanations, however, people ignoring it.

According to http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast and http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower both values have unclear and, therefore, overlapping (due to relying on personal judgement) definitions.

There are sections, giving an engineering definition of both mast and tower, however this definition was added relatively recently, and there are many objects tagged before that, where contributors had to rely on personal judgement when making decision if it's a mast or a tower.

Also, lack of clarity of definitions of these values provokes using it in wrong way since these terms are quite often used for much wider spectrum of objects than masts and towers in meaning, practiced by structural engineering.

Since there are other values, such as communication_tower, clarifying this pair of values will not fix the whole problem.

There are completely artificial, man-made objects such as cooling basins, sewage treatment reservoirs which are currently supposed to be tagged by natural=water, however, these objects have nothing to do neither with natural objects nor with water. These objects also have their primary entity independently of substance they contain, therefore, they should be tagged by man_made= key, being completely artificial and not being a building.
This issue is directly connected to #10

Malls are just a case of commercial property, mainly used for retail stores, however, residents can actually include cinema theaters, spa salons, gaming clubs, sales offices and other amenities, which should be tagged individually to make any particular sense. Using shop=mall should be restricted to temporary cases, when there is nothing known about particular place by some reason.

Places like that should be tagged like building=commercial (+landuse=commercial) with individual POIs for amenities.

According to http://wiki.openstreetmap.org/wiki/Key:sport , when tagging leisure=pitch, we have to use sport=* to indicate, which kinds of sport this pitch is intended for.

Quite often, pitches on school campus or community leisure ground are more or less universal. In this case, it is recommended to use sport=multi, which doesn't actually describe this pitch, since multi covers everything. However, pretty often these pitches are intended for particular set of sport games, for example, basketball, tennis, volleyball and soccer on small field and they have certain features for it, such as poles, marking etc. In this case it would make perfect sense to list these kinds of sport, but only way to do that is using multiple values delimited by semicolon, for example, sport=basketball;volleyball;tennis. This approach is considered acceptable, but it's rarely used and OSM contributors seem to dislike it.

It could make certain sense to introduce a scheme with namespace, such as
sport:[sport_name]=yes/no which is capable to reflect any set of sport games you like without making a contradiction.

Undocumented crossing=zebra is widely used instead of approved crossing_ref=zebra. It seems to be often caused by iD preset, which uses this undocumented tag.

wood=deciduous, wood=coniferous have overlapping and compound meaning:

There are deciduous plants which are conifers, and there are evergreen plants which are not conifers. Proper classification should involve leaf shape classes (needles, broad leaves ...) and seasonal behavior (deciduous, evergreen...).

This issue is a test

There are completely artificial, man-made objects such as cooling basins, sewage treatment reservoirs which are currently supposed to be tagged by water=reservoir, however, these objects have nothing to do with water. These objects also have their primary entity independently of substance they contain, therefore, they should be tagged by man_made= key, being completely artificial and not being a building.
This issue is directly connected with #9

According to http://wiki.openstreetmap.org/wiki/Key:memorial there is memorial=war_memorial and on the other hand there are values such as memorial=statue, memorial=stele etc.

Majority of values are reflecting the form of memorial object. While war_memorial reflects the event particular memorial is commemorating.

It creates an issue of non-exclusive value (there can be a statue, which is a war memorial) due to classification inconsistency.

There are parking=rooftop and parking=underground values, which are unusable together on the same contour, however, there are underground parkings with separate parking on its roof (on the ground level or just a bit above it).

It could be solved by using relations, but it seems more like workaround.

According to http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower , this value doesn't have clear definition (it relies on huge size as a distinctive feature, compared to man_made=tower), which causes potential overlap of meaning with man_made=tower (automatically considered smaller structure).

This value also has a compound meaning, because it's not only represents a tower as a man-made structure, but also requires it to be used for communication. In ideal case, this value should be deprecated in favor of using man_made=tower (neutral towards its usage) and certain independent tag(s), indicating how this structure is utilized: for communication, broadcasting, etc.

Majority of tags, intended for indicating retail stores or shops are name-based instead of reflecting and actual assortment of goods sold there. It creates massive problem for any user looking for particular product or class of products. For example, it is impossible to find out, if you can or can not purchase refreshment drinks in bakery shop. Indeed, certain keys are able to indicate main class of products, such as bakery, diary and so on. But in case of shop=convenience, shop=supermarket and others it doesn't give any real usable information, which turns data usage into guessing.