MapRoulette Critique

thanks! Not entirely sure how it works, would be nice if MR would do it be default for all tag fix things

It is certainly more complicated than it needs to be. Currently, you can only change your own view of the challenge easily. So what I had to do is change the way it looks for me, then export it, then import that export as the default layout. (@mvexel it would be great if that would be easier and better communicated)
Also, AFAICT, this height is still static. If the amount of tag changes exceeds the height, it will still be cutoff. It would be great to at least be able to enable a dynamic height.

1 Like

I would be interested in what I, as a challenge creator, can do to stop beeing viewed as doing or encouraging bot edits.

The whole reason I got involved in this discussion is because I was told that I am (knowingly) violating OSM’s rules just by having created a tagfix-Challenge without consulting the community prior.
And I do not want to be viewed as breaking or ignoring the rules the community has set for itself.

Should I change the instructions in any way? Or what can I personally do?

1 Like

Well, that is something completely different. I can see that MR as a platform may need to do more to discourage misuse. As stated prior, I joined the discussion under the assumption that I as a person was beeing accused of doing something wrong.

That’s exactly the question I was asking myself. To save you some headache, challenges that we created are shown as examples for why maproulette has some sort of problem, but as I see it, we have not done anything wrong.

We have used the platform as intended, but even intended use can go wrong if the platform itself has a general problem with not communicating to the users clearly that they shouldn’t blindly accept every change.

It’s already happened in some way or another, considering that SC keeps track of a leaderboard. For example, a motorway had gotten a cycleway:both=no by a SC user and given that motoways are expected to have no adjacenet cycleways (be it lanes or tracks), the only justifications for this changeset are extreme naivite (given that the cycling overlay doesn’t even show the lack of cycleway tags of a motorway) or pure point farming.

Still though, such overzealus SC users— no, SC gamers can be counted on one hand (thanks to the app nagging you to be nearby as well as requiring you to download the data yourself if you want from somewhere else).

1 Like

That’s why I was only hypothesizing about a StreetComplete Armchair Edition™ for the Web. :wink: That post doesn’t make as much sense anymore in this thread as it did in the thread I originally posted it to.

I have no reason to suspect systematic editing problems. This seems to be a case of one mapper misinterpreting or ignoring the instructions I gave. I also see no reason why beginners who actually read the instructions and the Wiki shouldn’t be able to easily contribute better layer tags to OSM here.

I understand that bad instructions result in bad data (see most data that comes from HOT mapathons where the organisers refuse to perform QA afterwards), and that’s a good reason to keep an eye on the quality of MR challenges, but I think you took a wrong example. That said, if you have suggestions for improvements to challenges that I’ve made, I’m all ears.

1 Like

Hi Martijn,

My takeaway is that you don’t feel responsible. I don’t expect I will be able to change that.

You can DM me to help me with creating the MapRoulette challenge to review all ford=yes tags on car highways and sidewalks in southern Ontario as requested :slight_smile:

2 Likes

As MR is a tool and not a weapon, i prefer the tool analogy. Good tools, specially the ones that can harm people or damage objects, has one or more safety measures built in by design, may require that the user has some kind of training in using them, requires the user wears some kind of protection, etc.

As the complaints from the community are from collaborators that have seen the damage done by ill-using the tool, it seems that this kind of approach (safety by design) was not enough in MR, and is impacting his usability. Some kind of improvements are needed, at every level, the MR platform (tool maker), the challenge creators (accessory makers), and final users, to ensure that the use of the tool has the least possible damage.

5 Likes

So MR is just a hammer that happens to present all its challenges as nails?

Not so simple. :slight_smile: I was thinking in it more like a power tool, a grinder with not enough safety measures, and the challenges are like the discs, for several uses, and some of the discs have not enough QA, and some contractors not following the guidelines or not using protective glasses or clothes.

Easy to complain, harder to have solutions.

4 Likes

Do you have a suggestion?

To take a specific example, this task has the text “This challenge focuses on layer=* tags that aren’t a simple number between -7 and 7. These values are often wrong and need to be reviewed.”. The instructions are “The layer=* tag describes vertical relationships between crossing or overlapping features. Objects that are above others should be tagged with higher numbers. layer=0 is the default and is generally redundant.”.

These instructions are totally inadequate. We know this because communication did not occur between you and the author of this changeset. You may say “well my instructions were OK; it is the author of the changeset that is at fault”. Unfortunately, you classified this challenge as “easy”. That implies that you’re going to help people new to OSM to understand what changes they need to make. You did not do that.

Finally, it’s worth turning to the Maproulette site design itself. I’ve just tried this challenge, and the first object it’s suggested that I fix is this one. Unfortunately, it is completely unclear which object it is suggesting is wrong** - I get a screen basically like this. To identify the object I had to switch “current mode to classic mode”***. That opens RapID in a little letterbox; I can fiddle around in that letterbox until I can see the “view on openstreetmap.org” link, click that, and finally it takes me to a proper-sized screen in a browser tab with the object highlighted.

The way has a “layer” tag of “0;-1”. Usually layer tags with semicolons in are a result of a “merge too far”, and undoing them requires looking at the history of the two or more objects involved (one deleted). This is never an easy thing to do and should not be included in an “easy” Maproulette task. This example is different though - this value was deliberately added in this changeset. Is the current value “correct”? I have no idea, and neither does the wiki.

Let’s imagine for a second that I do want to edit something and flip the switch from “current mode”. This is what I see:

Can you tell from that which element is being modified? I certainly can’t. I tried zooming in randomly, but that didn’t help. Part of the problem is that the initial zoom level (presumably imposed by MR itself) is way too high to be useful. It seems to be limited by the antediluvian max zoom of OSM Carto’s “standard” tiles, which is woefully inadequate here. Try and zoom in and Rapid (or something telling rapid what to do) also has a habit of jumping to a different bit of map, with the actual problem way off the screen.

Put bluntly - turn it off in its current form. As I hope what I have written above explains, as it exists now it is not fit for purpose.

That said, there’s absolutely a use for a tool that enables people to (in this case) check and correct implausible layer values. However, how you detect “a layer value that a newbie can fix” and “how you help them choose what the value should be” is actually quite hard. Other tools face these challenges too. One thing that would be very useful would be if the MapRoulette and challenge authors looked at the way that the people behind StreetComplete handle these sorts of things (rather than assuming that they knew best) - both “how do we guide the user through making the right decision” and “what on earth is the right thing to do” in various convoluted cases - you’ll see plenty of cases where they’ve asked other OSMers about that.

** subsequently it appears that “current mode” (whatever that means) is “highlighting” the offending way in blue - but you’d never know that.

*** Actually, it means “the current mode is classic mode” or “the current mode is edit mode”, but you only know that after making the change when some text changes. It’s the sort of UX that makes you weep for the users.

8 Likes

Sorry to pile on to MapRoulette some more, but:

From my experience trying to map details of subway stations, I would bet that this was meant to be level=0;-1 – that is, the way is meant to represent steps from ground level into first underground level. The key names are visually similar and OSM’s distinction of their meanings is not really obvious, so it’s a pretty understandable confusion.

I think that this confusion between layer and level is so common that it would have been a good idea to mention it in the challenge instructions for an “easy” challenge – certainly for layer values that have semicolons, and double-certainly for steps.

However, personally I still wouldn’t go in to Milan and retag it without checking somewhat extensively: Is this a one-time mistake during mapping of one station? Are other subway stations mapped with layer instead of level like this? Is there any local community agreement that this should be done, or should not be done? If all of Milan Metro is tagged with layer where we would normally use level, changing one way with MapRoulette then editing in Lisbon next is not helpful.

1 Like

[OT] This is not a one-time mistake; most of Milan’s subway steps have been mapped this way. It was done by a paid mapper working for the local transport company. I mentioned this yesterday in the Lombardy (the Italian region where Milan is located) Telegram group. As you suggested, the proposal is to correct it using the level tag. [/OT]

4 Likes

I didn’t know that. Looks like asking for trouble. I can see how it would ease some of my workflows, acting as a bulk edit with a manual check on each and every change, but not as a tool to let any mapper perform a preconfigured retagging.

If a certain tagging is agreed upon by the community, and they agree to use MR quick fix mode to control the operation, I’m fine with that.

If a real check is required, where the mapper should decide how issues could/should be solved, I would not recommend a quick fix method.

I think MR is a fine tool in many respects, and at the same time it has the same basic risk as other tools: people can make mistakes and errors, and upload them to OSM. If we prevent that, we also make it harder to contribute. That said, an extra warning, and a clear view of the tag changes that wil be made, wouldn’t be bad.

1 Like

That’s not a logical cause and effect. And it looks like the mapper doesn’t respond to comments anyway.

No, that implies the challenge should be doable by beginners who read the instructions. “Review” does not mean “delete without review”. That’s not my mistake. Plenty of other mappers, likely including beginners, have reviewed the tags successfully.

That’s a good argument. I don’t mind changing the challenge from easy to normal because of that.

I agree with your arguments about website design.

1 Like

Perhaps more fruitful might be to ask “how could we help people identify and fix problem data in OSM without making mistakes”?

Leaving aside the inadequate instructions (discussed above), the overpass query in this example is this:

(
node["layer"]["layer"!~"^-?[0-7]{1}$"];
way["layer"]["layer"!~"^-?[0-7]{1}$"];
);
out geom;

One thing that might help is to trying to divide that data into particular subsets with different causes. Let’s look at the nodes first. Manually clicking a few of those finds that a significant number are highway=elevator (already mentioned above). The wiki page for that isn’t great, but does suggest level rather than layer, so perhaps a sensible “subset” query might be just looking for highway=elevator with unlikely layer tags. The instructions might be something like:

The wiki page for highway=elevator suggests using level rather than layer to describe the endpoints of the elevator. These examples all use layer - should that be level instead? If so, change layer to level. If the layer tag does not make sense as a level, what does it look like? Look at the history of the objects and click through to the original changeset that added the unlikely layer tag and ask the person who added it what they were trying to do.

To keep it simple, the overpass query for that can exclude objects that have both level and layer.

The next stage would be to look at things that were highway=elevator but had both level and layer (comparing level with layer and making suggestions as to what to check next based on that), and after that things that weren’t highway=elevator etc.

9 Likes

I feel like this would not work well and be very very annoying for the vast majority of users that do actually know what they’re doing and do actually check their work.
This is due to the fact that MR challenges often have multiple points on the same issue somehow, and then when you fixed it and get directed to the same issue again, you want to just be able to click “I fixed it” immediately because there is nothing to fix anymore.

Another thing is that I personally often work on challenges where the tasks are close together, and then I tend to do all the tasks in a neighborhood in one changeset, and then mark all the tasks in that neighborhood as fixed afterwards, since this is quicker. But imagine then having to wait a minute every time for like 10 challenges before you can mark them as fixed for a task that you have already done.

3 Likes