openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.35k stars 1.2k forks source link

Consider less mysterious error message on too large bounding box #10286

Open matkoniecz opened 3 months ago

matkoniecz commented 3 months ago

Description

Current message show to user who made overly large bbox seems quite mysterious to a new user.

Is it technically possible to replace

Changeset bounding box size limit exceeded.

with

Server returned status code 413

appearing on clicking message

by something such as

Your edit covers too large area, it is better to split edit in parts where editing places far away from each other.

?

(result of https://github.com/openstreetmap/openstreetmap-website/issues/4805#issuecomment-2182603310 testing)

Screenshots

screen02

1ec5 commented 3 months ago

As far as I know, iD doesn’t customize any error message returned by the API. For example, it doesn’t attempt to localize the error message into the user’s preferred language. But presenting the error message is really a last resort anyways. By the time the user sees this error, there’s little they can do about it. If they’re lucky, the offending change is somewhere near the top of the undo stack, so they can undo their changes one at a time until the changeset saves. Or they can download the osmChange file locally and break it up using JOSM. This is unrealistic for the sort of user who doesn’t understand the error message.

If the goal is to make the user experience friendlier, then iD would need to prevent the user from expanding the changeset bbox before they make the change. This is one of the ideas proposed in #8590. Since the actual limit depends on the user account’s age and the thresholds are dynamically configurable on the server side, iD would need an upfront signal from the API about these limits, such as in the /capabilities response, which iD requests at launch.

However, my understanding is that these limits were implemented as a defense against vandalism, not to enforce good etiquette, as proposed in #8590. If we’re confident that these limits actually target vandals and that mappers in good faith are unlikely to hit this error, then I don’t see a stronger need to improve the user experience for this error than for any of the other errors the API can return.

ZeLonewolf commented 3 months ago

In fact, I would consider a non-specific error message as a good catch-all case for anything user-facing error that's the result of a vandalism block being hit. Let's not guide potential bad actors here.