Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fix to tag real unsquare buildings as unsquare #6332

Closed
quincylvania opened this issue May 7, 2019 · 15 comments

Comments

Projects
None yet
8 participants
@quincylvania
Copy link
Collaborator

commented May 7, 2019

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.

Screen Shot 2019-05-07 at 3 19 46 PM

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

@Nakaner

This comment has been minimized.

Copy link

commented May 8, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented May 8, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

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

@quincylvania quincylvania self-assigned this May 9, 2019

@quincylvania quincylvania added this to the 2.15.0 milestone May 9, 2019

@quincylvania

This comment has been minimized.

Copy link
Collaborator Author

commented May 9, 2019

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.

unsquare demo

@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

This comment has been minimized.

Copy link

commented May 9, 2019

@quincylvania Your behaviour is not commendable.

@lonvia

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented May 9, 2019

@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.

Nakaner added a commit to Nakaner/iD that referenced this issue May 9, 2019

Revert "Add quick fix to unsquare way validation to tag a way as havi…
…ng unsquare corners (close openstreetmap#6332)"

This reverts commit 0e7a63f.

This feature is highly controversive and requires an in-depth discussion
and evaluation before it can be commited to the master branch.
@BjornRasmussen

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

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 added a commit that referenced this issue May 9, 2019

@quincylvania

This comment has been minimized.

Copy link
Collaborator Author

commented May 9, 2019

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

@Nakaner

This comment has been minimized.

Copy link

commented May 10, 2019

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

@mmd-osm

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

commented May 10, 2019

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.

Screen Shot 2019-05-10 at 4 29 48 PM

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.

Screen Shot 2019-05-10 at 4 51 28 PM

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

Screen Shot 2019-05-10 at 4 27 13 PM

@mmd-osm

This comment has been minimized.

Copy link
Contributor

commented May 11, 2019

"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.

@SilentSpike

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2019

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

This comment has been minimized.

Copy link

commented May 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.