@GinaroZ,

Right, there are several factors affecting the situation in addition to the unclear definition in Wiki, including common “natural language factor” (or “tag as you call it”) and mapping for the renderer (specifically, OSM Standard style).

I definitely can do some analysis of this problem, however, it is impossible to tell, how many objects are tagged according to the engineering definition, because there is no reliable reference data source I can use for comparison (or I’m just not aware of one). So, it is only possible to compare OSM objects with a street view photos or something like that. An educated guess is impossible because we don’t have reliable information about “mapping traditions” either.

For now, I can tell that there are 196363 “towers” and 35422 “masts”, and nobody can actually tell anything clear about two hundred thousand objects, are these really towers or masts.

By the way, I can easily draw SVG icons for these objects to use them in OSM Standard, I just don’t want to do any unwanted work if this idea will get negative reception.

@TomH, I’m very well aware of the abstract nature of tags. I even explained different issues linked to this concept in several diary entries.

However, this particular case is a kind of different. Usually, uncertain tags are reflecting uncertain terms of natural language, just like in the case of https://wiki.openstreetmap.org/wiki/Tag:amenity=fast_food and https://wiki.openstreetmap.org/wiki/Tag:amenity=restaurant. There is no any clear definition of a difference between these two amenities. While masts and towers do have clear and simple distinctive features while corresponding tags not only have the unclear original definition but this definition also contradicts basic OSM principles (no relative values for tags, verifiable values).

These tags currently do not have “OSM-specific meaning” as you call it, they are completely mixed into one mess - it is technically impossible to be sure if https://wiki.openstreetmap.org/wiki/Tag:man_made=mast is a mast and vice versa. So, changing anything can’t do any harm, because it can’t be messed up more than it currently is.

People are arguing about that only because almost every person has an own tradition of tagging and thinks that all others have a similar one. But it’s not true - different objects are tagged similarly by different people as well as similar objects are tagged differently by them. Belief, that there is any global consistency in tagging masts and towers is just a fallacy.

Here, I’m saying that proper rendering of malformed data might promote fixing it with proper tagging. And I have an example of a similar situation. In Russian, “kiosk” refers to a small shop in general, not to specific product range of a small shop (as it is in many European languages). Right after https://wiki.openstreetmap.org/wiki/Tag:shop=kiosk got its own newspaper icon in OSM Standard style, Russian mappers started fixing hundreds of improperly mapped amenities by setting proper values such as ice cream, tobacco and so on. I don’t see any reason why it can’t work the same way with masts and towers.

@poornibadrinath, it makes perfect sense to always start from searching for open data before dealing with any new area. Sometimes it could be not so easy due to language, but there should always be at least one member of a local community, right?

http://share.mapbbcode.org/ is another option.

Are you aware of this information? https://data.gov.sg/dataset/sla-cadastral-land-parcel License of it seems open enough for OSM: https://data.gov.sg/open-data-licence

It is not equal to building footprints or roadway centerlines, but you still can use it to check alignment and such things.

RTK (or even less demanding high-precision modes) with a typical smartphone antenna, even with a dual-frequency receiver? No way, forget about it.

Are you aware of RTKLib, by the way?

@Vanuan, > Same thing applies to OSM itself, right?

Yes, but your example is not about that - it’s about being unable to distinguish two entities only in given circumstances.

But in OSM, there are things like https://wiki.openstreetmap.org/wiki/Tag:shop=kiosk, while “kiosk” means completely different things in different countries. However, sharing the same problem doesn’t mean that we have to be more tolerant to that or to promote certain changes making it even worse.

The idea behind wikidata is that there’s no controversy.

Unfortunately, there is a gap between the idea and the real world situation. It relatively small, but it still exists.

Linked Wikipedia articles in different languages are not always talking about the same entity, and it’s not just about those unrecognized or partially recognized regions. It means, that you can’t always be sure, that by switching language in Wikipedia, you will see an article about the same thing. Usually, you will, but it is never guaranteed. Sometimes, it will lead you to an article about a class of entities original entity belongs to (especially when certain terms in two or more languages have a different meaning).

So, wikipedia=lang:* syntax, even being “popular”, is just another example of an exclusive tagging scheme, that prevents several properties from being assigned to an object, even if they actually can coexist. Which is obviously bad.

Same thing, technically, applies to wikidata: if there is any real-world controversy about an entity it links to, it creates an incompleteness or inconsistency.

For the purpose of visualization, it is usually more practical to rasterize data with double or quadruple resolution using one of the conventional projections, then - to reproject and downsample this temporary raster.

I’d add that in Europe or another place with a high density of active mappers, a negative effect of similar behavior is usually reduced by a community due to constant checking and fixing. While in Africa, harm is way more significant, because it will way less unlikely fixed if needed. So, instead of praising this kind of activity, I’d say: “oh, well, now we have the whole bunch of potentially wrong data in Africa, where it will stay forever without being carefully checked”.

Just in case: Forum discussion Changeset discussion So, that has been done with good intentions, but not really in accordance with OSM rules and guidelines. Therefore, data quality (which is the top priority in OSM, not the amount of data) could easily be compromised.

@LLlypuk82,

Будет реальная возможность - будет вопрос. Иначе, объяснять всё вот это - слишком длинно.

As it often happens in OSM, certain terms have slightly different meaning than in real life. Same applies to commercial land use. In OSM, it does not indicate ownership or form of property, it does indicate a purpose of this land. In the case of fairgrounds, majority of activities taking place there are usually commercial.

Since fairgrounds are a subset of commercial use land, it would be completely correct to tag it with https://wiki.openstreetmap.org/wiki/Tag:landuse=commercial if someone wants to stick to approved tags. This way to describe it is very broad, but fairgrounds could be used for an extremely wide range of events.

Различных каналов связи в OSM и так почти десяток, теперь к зоопарку прибавился Телеграм.

@Zkir,

Затроллить и затравить - нельзя. Забанить - завсегда. Теперь - и за цитирование Apocolocyntosis divi Claudii, например.

@Zverik,

Imp_GL, перелогиньтесь.

Тем, который написал De tranquillitate animi, De vita beata и De Constantia Sapientis, или тем, который написал Apocolocyntosis divi Claudii?

@Severak, thank you for this simple comparison you provided.

Please, keep in mind, that physical barriers and legal access restrictions are different things, while often, a legal restriction is enforced by a physical barrier. Both cases you referring to are not exactly related to the topological problem I’m talking about - these are questions of a scheme itself.

Warin61, are you familiar with a concept of trespassing in the US or Ireland? The whole private land is considered inaccessible for general public by default. So, yes, it makes perfect sense to indicate private access on a parcel boundary.