Giter Club home page Giter Club logo

osm-tagging-issues's People

Contributors

bushmank avatar

Watchers

 avatar  avatar

osm-tagging-issues's Issues

multiple values for sport= key on pitches and other objects

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.

bicycle=yes and foot=yes are widely misused

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.

shop=mall is too broad

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.

some parking= values are unusable together

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.

Store/shop tagging scheme is name-based instead of being assortment-based

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.

wood=* scheme has overlapping classes

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

Tagging certain objects with natural=water tag is inconsistent

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

man_made=communications_tower unclarity, compound meaning

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.

Tagging certain objects with water=reservoir tag is inconsistent

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

man_made=mast and man_made=tower unclarity and definition overlap

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.

memorial= values are non-exclusive due to inconsistent classification

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.