Id: Add fix to tag real unsquare buildings as unsquare

[quincylvania]

We want buildings to have nice square corners in OSM—unless they're not square in the real world. iD should offer a fix like "Tag as accurate" that will add a tag like unsquare=yes to indicate a building is known to be truly irregular. This will prevent iD and other tools from continuing to falsely flag the issue in the future.

Other false validation issues are already tagged similarly in OSM, such as with noexit=yes and noname=yes.

[Nakaner]

Although noname=yes is common, it is not that common that it can serve as an argument in favour of introducing unsquare=yes. In difference to noexit=yes, unsquare=yes and noname=yes only serve as a workaround for quality assurance tools. noexit=yes also conveys information for map users: There road ends here.

Some people prefer to tag as complete as possible and add oneway=no, cycleway=no, lit=no etc. to any way. However, such a practice is not base on a broad consensus and if you dig deep enough in the history of user blocks in OSM, you might find blocks set due to an excessive use of negative binary tags.

I think that iD does not need this tag and should only validate buildings if they have been added or modified in the current session. If doing so, they will be reported once which does not bother that much.

Adding such a tag is not a simple change as it might seem to be and I ask you to discuss it with the broader community on the Tagging mailing list.

[quincylvania]

@Nakaner Thanks for your feedback. A few notes:

• All of iD's validations work on existing data as well as data changed in the current session. This helps mappers quickly clean up existing data, like the countless unsquare buildings already in OSM.
• I don't think tags like noname=yes or unsquare=yes are categorically different from a tag like noexit=yes. They're not workarounds, they all positively describe on-the-ground conditions.
• Adding such a tag is quite simple. It's purely additive and serves a function not met by existing tags. All existing OSM mappers and data consumers can easily ignore it if desired.

That said, I would understand an argument more like "iD should just flag fewer false positives." However, objects in the real world are so varied that I don't think we could ever reach 100% correctness. Some buildings actually do have 89° corners!

[pnorman]

I agree that this needs to be proposed to the broader community and discussed before encouraging people to add such a tag.

[quincylvania]

I did this! I ended up using nosquare for the tag to align it with noname and noexit. Mappers can now fully resolve all unsquare way issues. If you manually square the feature later, then the tag is automatically removed.

@pnorman said:

I agree that this needs to be proposed to the broader community and discussed before encouraging people to add such a tag.

iD development isn't driven by the tagging mailing list nor tagging proposals. Our goal is to help hundreds of thousands of mappers around the world easily create accurate, unambiguous data. Sometimes (very rarely) this may entail making up new tags, but all tags are made up anyway so I don't see an issue here.

[Nakaner]

@quincylvania Your behaviour is not commendable.

[lonvia]

May I kindly suggest that you consider what this feature does to an average town older than 300 years. Right angles are seriously overrated.

[quincylvania]

@lonvia Good point! We think we've struck an okay balance to reduce false positives. iD won't flag buildings connected to other buildings nor buildings with lots of points. Buildings with additional tags cannot be fixed without review. In fact, I loaded that area with preview iD and only saw about a dozen unsquare building warnings.

[BjornRasmussen]

The key nosquare makes no sense. Noexit, noname, and others are logical English, but nosquare implies that the building doesn't have a square somewhere to the many mappers unfamiliar with the tag. Could you use notsquare instead?

[quincylvania]

@BjornRasmussen I changed it to nonsquare, which is an actual English word and should be more friendly. Thanks!

[Nakaner]

For reference, this topic is now discussed on the Talk mailing list. https://lists.openstreetmap.org/pipermail/talk/2019-May/082506.html

[mmd-osm]

Interesting proposals out there: https://lists.openstreetmap.org/pipermail/talk/2019-May/082522.html

_it can participate with other solutions like better training to assure that Newbies understand what Building tracing really mean and give then some feedback, like for example saying before save "You have 10 over 12 buildings that are unsquarred. If you dont know how to make rectangular buildings, you should ask for help before you continue. Do you want to send data anyway ?"_

[quincylvania]

I encourage everyone interested in the unsquare buildings validation to try it out for themselves on our live preview site before jumping to conclusions about how it works.

As with all our validation rules, we put a lot of thought into making unsquare issues contextually relevant and easy to resolve with accuracy.

By default, you only see issues with your own edits. This means new mappers aren't prompted to square random buildings, just their own additions. If you want to be a power-validator—awesome!—you can switch to validating all loaded data in the Issues pane.

If you don't want to use nonsquare=yes, or you're not sure if a building is actually square or not, you can select the new "Ignore this issue" option instead. This silences the particular warning for your current session, but it won't convey any information to other mappers.

And if you don't find unsquare warnings helpful at all, then you can simply turn them off.

[mmd-osm]

"Warning" as a category for non-squared buildings along with a yellow exclamation mark seems a bit strong for the average user. Moving this check to "Information", along with some blue Information icon would probably be more appropriate.

you can select the new "Ignore this issue" option instead. This silences the particular warning for your current session, but it won't convey any information to other mappers.

I see one major drawback of this approach: as you don't have a dedicated backend service to store "false positive" user decisions (unlike "real" QA tools, like osmose), the warning will resurface the next time you map in that area. Ignoring is really only feasible for a one off mapping event, otherwise this tends to be quite annoying.

I tried this in some rural area in France where imported official cadastre data prevails. Yet, most of the buildings were "to be squared" candidates, making the "power-validator" mode kind of pointless. Adding an extra tag to all those buildings to silence iD seems kind of weird.

[kymckay]

Moving this check to "Information", along with some blue Information icon would probably be more appropriate

Having another level of validation is something I've been thinking of suggesting also.

It could be used for things that aren't guaranteed to always be wrong (such as these nonsquare buildings or the email/website format validation I've had a play around with) - as such never being included in the "fix all" operation.

[woodpeck]

I realize this is not a vote but I'd like to register my profound disagreement with editor writers unilaterally inventing new tags they feel are a good idea. Nobody in OSM is so brilliant that they should have that kind of power. Not without discussing it first, like we expect of any import or mechanical edit for precisely the reason that what seems like a good idea to the inventor could turn out not so good after a few more people have looked at it from different angles.