@az09,

Повторюсь - в Википедии это вполне себе живо. И это вполне могло бы уберечь в свое время некоторые страницы от полной хрени, которая появилась там в результате очередного брошенного кем-то клича “нам надо перевести Вики”, подхваченного теми, кто считал, что переводить с google translate и мнением своей левой пятки - это “лучше, чем ничего”.

@SimonPoole,

Neither I nor other commenters except @Glassman have proposed mass mailings. So, I don’t see, how your comment could apply to @all.

Robinson projection https://wiki.openstreetmap.org/wiki/Tag:+proj=robin https://wiki.openstreetmap.org/wiki/Tag:+lon_0=11 https://wiki.openstreetmap.org/wiki/Tag:+x_0=0 https://wiki.openstreetmap.org/wiki/Tag:+y_0=0 https://wiki.openstreetmap.org/wiki/Tag:+ellps=WGS84 https://wiki.openstreetmap.org/wiki/Tag:+datum=WGS84 https://wiki.openstreetmap.org/wiki/Tag:+units=m +no_defs https://wiki.openstreetmap.org/wiki/Tag:+towgs84=0,0,0 Set longitude of origin to 11th meridian because in this case edges of the map are aligned with Bering strait.

@Glassman,

Honestly, I don’t know, what would the best (and even just “working”) way of keeping in touch with people. And by this diary entry I’m trying to point on a situation, where even acknowledging that we don’t really know much about distinctive aspects of behavior of newcomers en masse is a step forward from mythological thinking.

But in the same time, I wouldn’t focus on newbies that much, at least, because definitely not all of them are troublemakers. And not all troublemakers are newcomers, while sometimes you can hear people blaming them for everything.

@SomeoneElse,

First, you haven’t defined an “investigation”.

If it’s a study, similar to marketing research I’ve mentioned, then yes, I have an evidence - there is no studies on this topic, commercial or scientific, published online. There are statistical studies, similar to this one - it is relatively easy to conduct working with contribution statistics. But study of behavior and motivation is completely different thing, which is way harder to conduct - you can’t just look at changeset comment and find out, what was the motivation for it. Probably, it is possible to make one within a limited group (students, for example), but that wouldn’t give any kind of universal result by design. If someone were conducting a good complex scientifically correct study, he would most likely publish it.

If it’s less elaborate “investigation”, like, talking to several people you stumbled upon trying to fix some mistakes they made - it doesn’t qualify you to talk about all newbies being special, because it’s statistically insignificant. Knowledge, obtained in this way, is called “anecdotal”, and it could only serve as an example. You can’t build a hypothesis about people’s behavior on that amount of information, especially keeping in mind, that there are differently motivated newbies, as I explained before.

Difference between my claim about those who saying that they know something special about newbies and those who saying that is simple: I call for skepticism (which means no default trust) while they want everybody to believe them without showing any evidence.

Skepticism is not a fact, it’s an approach, which doesn’t need an evidence to be used. While knowledge about something is a fact, that has to be proven. In other words, I don’t want anyone to trust me personally, I want people to critically evaluate any claims.

@az09,

Это было бы очень неплохо, тем более, что в Википедии это более-менее работает (другой вопрос, что на некоторые полезные правки опытным участникам бывает похрену и страница так и остается кривой весьма долго).

@az09,

Мне совершенно все равно, как это называется. Критерий “русскости” лишен смысла. Словотворчество на ходу - вообще какая-то шизофрения.

@az09,

Это еще как конструктивно. Я самым непосредственным образом помогаю исключить варианты, которые противоречат даже вашим собственным критериям (чего вы по какой-то, вероятно, очень конструктивной причине, сами не заметили).

Откройте для себя российскую ветку форума OSM - тут крайне неудобно вести диалоги и никто практически этого не делает.

Пардон, читать: “эта страница содержала невнятное блеяние”, частица “не” - лишняя. Комментарии нередактируемы, да…

@Сергей Голубев,

Я не зря сослался на секцию “First question: Is it a mast or a tower?” - там даны три примера в виде картинок, которые ничерта не объясняют (автор, видимо, считал иначе).

Пока я не добавил туда секцию Engineering definition эта страница не содержала невнятное блеяние про “небольшая”, “могут иметь оттяжки” и так далее. Оригинальное “определение” я не трогал - в англоязычной Wiki это иногда чревато воплями и обидами, но ищущий что-то понятное, логично, обратит внимание на “Инженерное определение”.

Забавно - вообще всё, что я пишу здесь в дневниках, независимо от темы, всегда ведет к дискуссиям о способе обозначения того или иного объекта. Не значит ли это, случайно, что с этим что-то в корне не так?

Это Οικουμένη - “по-русски”? “Стрелка” - это да… проникновение ублюдочной криминальной лексики в язык велико и не удивительно.

@Nakaner,

First, I’m not talking about a new way to discuss anything, I’m talking about a way to document and track tagging system issues, which makes your first point a kind of irrelevant.

Second, it’s a good manner to explain your point in reasonable manner. I mean, if you said “… it will …” there should be at least one “… because …”. You’ve made a whole bunch of assumptions, but didn’t give any explanation, why it should happen. It doesn’t add any credibility to your statements.

And, by the way, using CAPS is a bad manner of online conversation, which is equal to shouting. Do you think that I’m not aware of “any tags you like” principle? If yes, then go read my other diary posts.

Speaking of “any tags you like”. This principle doesn’t say anything about “any tags you like will be supported”. Think about it.

Your example of OpenSeaMap is irrelevant, because their tagging system is, probably, the least ambiguous and the most structured portion of OSM tags.

And again, I’m not talking about what to do with “bad” tags. At least, because there is already a good experience of getting rid of tags such as wood= and replacing it with leaf_type= and leaf_cycle=, for example. You can go check taginfo.

I am, for sure, aware of “anarchism” in OSM. Calling yourself “an anarchist” here is quite pretentious and hypocrite blanket statement, which could cover some sort of teenage rebellion, ignorance, lack of abstract thinking skills or asocial features (yep, in collaborative project). At least, these “anarchists” do follow certain rules and ignore only those rules they personally dislike, which makes it a hypocrisy. I already mentioned one of these guys - Etric Celine, an author of “documentation” of https://wiki.openstreetmap.org/wiki/Tag:shop=kiosk - exemplary meaningless tag, copied from natural language without any attempt to describe more or less clear, what exactly does it stand for.

@escada,

GitHub doesn’t have threaded structure for discussions, but it does have @mentioning syntax and quotes. So, if someone wants to use it, it is possible to do.

Not ideal, but acceptable. I don’t think it’s a requirement, and anyway, even if certain forum has threaded structure, people ignoring it pretty often. It’s a question of personal online conversation culture, not technology.

@Sanderd17,

I am aware of difference between software development and OSM tags you’ve mentioned. However, there are certain mechanisms in OSM, which depend on “community approval” (even if it’s not about formal proposal procedure). To get into editor presets, translations, Wiki, converters and so on, tag should be supported by developers of editors and converters, by translators, by Wiki editors. This is an element of self-regulation and self-government of OSM, that’s why we don’t have certain stupid tags spreading automatically, while nobody can actually prohibit any of them.

There are good examples of issues with tags, which were a concern for different people independently. For example - https://wiki.openstreetmap.org/wiki/Tag:wood=coniferous and https://wiki.openstreetmap.org/wiki/Tag:wood=deciduous. I’ve been thinking about what’s wrong with these tags in the same time as @Rudolf. If there were a common place for tracking these things, we’d be able to work together on it. Common place to share existing information on certain issue obviously boosts development of solution, because people can share their knowledge in structured manner. Same case also demonstrates, that replacing ambiguous tags with better scheme is not something impossible.

We also know, that using JOSM validator rules for that purpose (encouraging people to change obsolete tags to recommended scheme) works. So, I don’t think that “anarchy” is strong enough to prevent further improvement of tagging.

Also, having issues documented in categorized manner saves a lot of time, when someone complains about it again somewhere - you can just give a link as an answer, and this person could probably add (or not) a grain of new information.

Your idea of documenting local/national defaults (as well as at least partial tree of tags, required for it) is valuable and important since there is no common place to find information about that except rare Wiki pages, but it’s a bit different story and I am not currently focused on this topic. So, you can probably pull this idea from your comment and publish it as separate diary entry or something else.

@escada,

I feel like I made it clear, why I’m saying that forums and mail lists are making a dead end in case of complains about tags. But I will repeat that.

• Complains about tags do exist. People (both newbies and experienced contributors) doing that. So, there is no question like “is there anyone who wants to report issues”.
• Issues need to be documented to be able to eventually fix them in possible way. It is well-known fact, that usually it is impossible to fix them immediately if it requires something more than just changing a couple of words in Wiki description.
• Documenting something means being able to categorize it, to review it and to edit.
• Forums allow editing and making “sticky topics”, but it’s pretty uncomfortable method
• Mail lists allow only searching through it and nothing more.

That’s why these two technologies making a dead end - information about any issue gets buried there if it can’t be solved immediately.

At least half of real tagging issues (I’m not speaking about people, who can’t understand tags, I’m speaking about flaws of tagging system) can’t be solved in local communities. Also, nothing will prevent certain members of local communities from copying new complains from forum or mail list, if they willing to do that. Irrelevant complains in bug tracker are easy to get rid of - it takes only a couple of clicks.

So, I don’t see any real issues with my idea of using bug tracker to document tagging scheme flaws.

@yvecai,

Currently, I’m talking about plain issue tracker. At least, until we don’t have anything like “tree of tags” to use repository system to edit it. Which might be nice, but quite unrealistic.

@escada,

I’m insisting, that both forums and mailing lists used for that purpose are making a dead end. Everybody don’t have to be familiar with an issue tracker concept to submit bugs - it’s just like sending a message, while actual bug tracker is different from, say, forum in aspect of being able to categorize bugs, merge them and have different statuses for them. You can’t do that on forum and especially - on mailing list (at least, because messages there are not editable at all).

It also doesn’t matter, that GitHub is for development. If that fact scares someone off, it’s hard to imagine that such person is capable to express his problem in certain understandable manner.

Personally, I can probably start doing that, but I’d like to know, if there are other people supporting this idea.

@escada,

We probably don’t need more structure for the sake of structure itself. But it would definitely be good to have less chaos.

• It is better for contributors because it makes tagging more straightforward and requires less guessing.
• It is better for OSM developers, because it’s easier to make and support presets for editors, map styles, QA tools and so on.
• It’s better for data consumers because each entity doesn’t require a huge research to find out the whole bunch of different tags it is represented in OSM database. Therefore, it’s easier to make derivative products, support converters etc.

It is a bad manner to make people digging through ambiguous stuff to make something working, that’s why it makes sense to get rid of ambiguity, uncertainty, semantic overlaps and semantic divergence (these are main types of imperfections in tagging schemes I found for myself). Making data consumer searching through taginfo to find all coexisting ways to tag something or making him solving a puzzle when he finds “hut” or “cabin” is an act of ignorance. There are hundreds of categories, and better (cascading) schemes we have, easier it is to work with data. And to contribute, in the same time.

If someone is a rebel, then he can express himself in Wikimapia. OSM is a collaborative project and collaboration means respect. Reasonable respect, not the blind one, therefore, we don’t have to respect anyone’s unreasonable desire (like, to see restaurants in “shop” category). It is currently impossible to afford letting people to use real-world terms without any more or less strict, but definite classification, otherwise data will become completely unusable.

@Warin61,

I am aware of semicolon as separator for multiple values (and I have mentioned it), but it’s technologically ugly scheme, rarely used and rarely supported by anything.

There is a solution: - more responsible voting for proposals - better communication (mailing lists are awful ancient technology) to improve abilities to discuss tagging - better notification (most of people here are not even aware of new proposals) - better guidelines (I feel like I can improve current guide, but it’s a private page, not general Wiki page, and I’m not completely sure my edits will not be reverted by formal reason of couple of grammar mistakes instead of being fixed), - tagging refactoring program (probably, with some sort of issue tracker), where everyone can complain about uncertain, contradictory, redundant tags and so on.