OpenStreetMap
OSM project is famous for its quality assessment tools. We have tools to track changesets, to check properties of objects against certain reference databases, we have Achavi to visualize changesets, we have KeepRight to analyze geometry, check website links and to do lots of things. There is also a mechanism of notes, which works as an issue tracker for both bugs and “feature requests”. Ability to comment on changesets is nice, but it’s a kind of limited: only author of changeset gets a notification and there is no way to bind a comment to an object to turn it into another issue tracking tool. But all these tools are for data: geometry and properties (tags).
Infrastructural elements of OSM, such rendering styles, websites, editors, being an opensource sub-projects, usually have issue trackers on GitHub.
But there is absolutely nothing for tagging schemes. I mean, yes, you can write something on Discussion page of Wiki, or complain somewhere on mailing lists or forum. But nobody is checking discussion pages constantly, while posts on mail lists and forums have a tendency to be buried pretty quickly by other stuff posted there.
For me, it seems to be logical to have some place, where everyone can tell about an issue of tagging scheme:
- uncertainty,
- contradiction,
- overlapping meaning,
- linguistic issues (different meaning of word, used for key or value in different cultures),
- systematic misuse of tags,
- lack of way to tag particular entity.
Definitely, it should not be a place to ask questions about tagging - it should be a place exclusively for reporting issues and requesting features, just like the most of issue trackers.
It is well-known fact, that acknowledging a problem is the first step towards fixing it. And currently there is no common way to make this step. For example, people are showing up on forum or mail list complaining about something and getting typical reply: “It’s well-known problem, but we don’t have any solution yet.” That’s pretty much all that happens. Then, after a month or a year, someone asks about the same issue.
Good issue tracker with labels, ability to merge issues and so on, may help collecting valuable information about bugs, imperfections and incompleteness of OSM tagging scheme. And contributors, interested in improving it, could use this information to set better objectives, to have better understanding of major issues. It also may probably help to connect those who have an issue and those who can fix it, because many contributors do not have any experience in editing Wiki to clarify a documentation, while those who can edit Wiki are not necessarily aware of the same issues.
I’m not sure, if GitHub issue tracker can actually fulfill all requirements since I don’t have enough experience running it as an administrator, but if yes, it might be a good choice.
Feel free to leave your comments and suggestions.
Discussion
Comment from escada on 20 January 2016 at 06:00
Right now, some people use the tagging mailing list for this. Of course, this does not really allow tracking of the issue. OTOH, not everybody is familiar with the concept of “bug” tracking. Github is a software developer solution, I wonder whether this platform is attractive for non-developers.
Adding a issue tracking system for tagging problems seems a good idea. But, as usual, there will still be other places (local mailing lists, fora) that will be used for the same purpose. And the outcome (solution) for a tagging problem might be different in different places.
Comment from BushmanK on 20 January 2016 at 06:52
@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.
Comment from yvecai on 20 January 2016 at 07:07
You think of github, but it comes with features like pull request and issue closing that may add significant changes to the actual fuzzy tag process.
Comment from BushmanK on 20 January 2016 at 07:14
@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.
Comment from Sanderd17 on 20 January 2016 at 09:40
There’s a big difference between software bugs (and even feature requests) and OSM tags.
Software is normally managed by a select group, they choose whether they want a feature or not, and whether a solution is good enough to solve a bug or implement a feature.
OSM tags on the other hand are more of an anarchy. Everyone can introduce new tags without any approval from others. In that anarchy, some tags grow naturally, and become a standard. Tools start using them, mappers see examples from other similar features, and the tag becomes more popular.
So introducing a new tag is, more than anything else, bootstrapping that positive-feedback loop. The well known wiki proposal process is just a part in bootstrapping that loop, by making the tag known and getting rid of any controversy around it.
So I don’t believe bug reports will do anything except introducing yet another channel to discuss stuff and spread communication even more.
There are other things that could be done though, like helping tools to implement tags. Examples include: * creating a set of default tag implications. Like highway=residential inside the boundaries of Belgium implies maxspeed=50 * Making natural language translations of tags. Like admin_level=8 in Belgium can be translated to “Gemeente” in Dutch. * Adding categories to tags. Like amenity=pub belongs in the “food and drinks” category. * …
By having data like that in a uniform format, tools can parse it directly, and it would help a lot with the creation of new tags IMO. By empowering tools, people will also start using these standardised tags more. And a project like this could be managed in a more centralised way, with a bug tracker and a team that decides which additions are good and which aren’t.
Comment from yvecai on 20 January 2016 at 12:04
@Sanderd, I won’t quote your last sentence out of context, but even here I feel that such a process would be too normative compared to what we have now.
Comment from escada on 20 January 2016 at 12:34
@ BuskManK, you wrote “I’m insisting, that both forums and mailing lists used for that purpose are making a dead end”
Do you mean that you think that forums and mailing lists should not be used ? Or do you mean that you want that they are no longer used ?
When it is a good tool for the goal, people will start using it. Otherwise they will keep using their preferred communication channel. I have seen too many people logging bugs for any of the tools related to OSM on fora or mailing lists that have nothing to do with the topic or where the developers do not read about the problems.
Since tagging issues can be solved in the local community, discussions will continue to take place there.
Comment from BushmanK on 20 January 2016 at 17:24
@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.
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.
Comment from BushmanK on 20 January 2016 at 17:45
@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 -
wood=coniferousandwood=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.
Comment from escada on 20 January 2016 at 19:04
Does Github support “multiple threads” ? What I mean is it possible to make a reply appear immediately under the original comment, instead of at the bottom under all comments ? For the type of discussion you want to do, I think this is a requirement.
When I look at some of the discussion about carto-css, it find it difficult to see who is replying to who when a lot of people are commenting at the same time.
Comment from BushmanK on 20 January 2016 at 19:25
@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.
Comment from Nakaner on 22 January 2016 at 10:38
I mostly agree with @Sanderd17’s posting.
I think we do not need such a platform. It will just spread discussion and data users which are not familiar with OSM will think that their posting will make all mappers to change their tagging behaviour. But OSM is different. YOU CAN TAG WHAT YOU WANT.
BushmanK worte: > 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.
If you want to deprecate a tag, you have to make all relevant data users (mainly renderers and routing engines) to drop support of that tag (i.e. if you want to weaken a specific waterway tag, you have to make OpenSeaMap drop its support).
Proposals and all that discussion stuff may express that some people think that a tag is good/bad/should be called “deprecated”.
I hope, you already know this OSM wiki template and its users.
Comment from BushmanK on 22 January 2016 at 16:53
@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 withleaf_type=andleaf_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
shop=kiosk- exemplary meaningless tag, copied from natural language without any attempt to describe more or less clear, what exactly does it stand for.Comment from butrus_butrus on 31 January 2016 at 08:31
I think that it’s a very good idea to use issue-tracking for this purpose.
And I don’t think that it is necessarily a bad think if a discussion will be tracked in such a system AND parallel to it discussed in the mailing list - as you can post a link to a mail-list archive to an issue-tracker (“for the record”) and vice versa.
Comment from BushmanK on 31 January 2016 at 19:52
@butrus_butrus,
Thank you for your support. My idea includes some sort of separation of discussion and documentation to avoid common consequence of mixing them in the same place - inability to effectively search through the tons of comments. But, for sure, it makes sense to link issues, corresponding Wiki discussions, mail list threads, forum threads and so on. Currently, level of connection between different places, where similar topics are discussed, is extremely low, therefore, information is highly fragmented.