Polygons beyond the edge of the screen cause confusing radial menu #542
Comments
|
Yeah, this is definitely a problem. I think maybe we shouldn't even render fill for areas that cover the viewport. |
|
Related #426. |
|
I'd propose the following: Render polygon fillings only if the object is (a) completely loaded and (b) at least some percentage of its outline is visible and (c) at least a certain percentage of its area is visible. The actual limits would have to be determined empirically. Maybe something in the order of 50% to 75% could work. |
|
Experimenting with non-fully-filled areas on the @samanpwbb @ajashton, thoughts? |
|
Separate thread on https://lists.openstreetmap.org/pipermail/talk-gb/2013-September/015155.html , might help characterise the problem further. |
|
Residential areas (landuse: residential) accidentaly changed with id editor after user tryied to draw or modify a buulding inside the poligon. The error already is annoing. Please , until you resolve this problem change the default editor back to potlatch 2. |
|
On 12.10.2013 00:04, Martin Raifer wrote:
http://www.openstreetmap.org/browse/way/84792537 Here , one day ago a coleague revert the same change made accidentaly to |
ghost
assigned
|
On 13.10.2013 18:18, Razvan wrote:
Hello Again the same problem. You can see in this changeset that this user |
|
http://www.openstreetmap.org/browse/changeset/18435905 |
|
It's still happening: http://www.openstreetmap.org/browse/changeset/19099731 The most common issue seems to be "landuse" to "building" transitions. I can understand the unwillingness to implement "are you sure" dialogs all over the place, but in the case of large landuse to building changes, surely something should be flagged up? What's the largest building in the world - if someone creates a "building" in iD bigger than that perhaps something should be flagged up. For info, I've just done it myself on the dev server with iD 1.3.3 - the fact that "landuse" pops up at the left isn't really a cue that you're changing an unexpected object since when adding things with iD your most recent searches turn up in the list at the left. |
|
I suggest not allowing turning something into a circle and similar operations that has zero nodes in the viewport. |
|
Still happening: http://www.openstreetmap.org/changeset/19306253 (this time turning a residential area of a quite large town into a bicycle shop) I'm not convinced that the suggestions on #1702 would have helped in this case - a new mapper just wants to add a bike shop, and if there's nothing in the UI to tell them to click "point" at the top and nothing that stops them from changing details of an unfeasibly large area, some new mappers will do exactly that. |
|
Still happens - just reverted http://www.osm.org/changeset/19918651. |
|
Hello, |
|
For info, still happening in the UK too (at least 3 examples in the last couple of days). |
|
|
|
I implemented a fix for this by replacing the fill for things like |
residential, retail, commercial and industrial landuse tags typically cover large, dense areas with many overlapping features. The large click targets of filled areas have proven to be very good for usability in the general case, but are a common source of accidental mistagging in this case. We may add additional tags to this list, but these are the obvious first step — especially landuse=residential. Fixes #542.
|
Re #542 (comment) above - we're seeing fewer "circularisations" than before, but still quite a lot of "residential area moves" (and just as many "make X into a building" of course). "Large landuse moves" affect the individual nodes rather than the way itself and can be quite difficult to spot if they haven't also made it into a building. In the same manner as #2170 would it be possible to disable way move operations if the way is not > 80% in the viewport? |
|
@SomeoneElseOSM, I agree, I think it makes sense to also disable the Move and Rotate operations if the object is not at least 80% contained in the viewport.. |
…wport see #542. Also included: 1. DRY up code for "% contained in" extent testing. 2. If action.disabled() returns a better reason, show that instead of the too_large one.
|
@jfirebaugh would it be better to attack this problem in iD.behavior.Select.click(), rather than in the area rendering code? We could just not select too-big polygons, right? |
|
That would make large polygons completely uneditable in iD, right? You couldn't edit the tags, and since vertices appear only on selected ways, you couldn't change the geometry either. That doesn't sound desirable. |
|
My thinking is to intersection test the polygon edge with the viewport (context.map().trimmedExtent()), and only select the polygon if the user has a reasonable chance of seeing the selection halo. In other words - allow select if an edge goes right through the middle of the viewport (or the polygon is completely enclosed), prevent select if the polygon is so big that the user sees no edges. (We'd of course need to test the actual polygon edge, not just compare extents like I have been doing for these other workarounds). |
|
That could work. Though I'd rather have a solution where there's a UI indication of which clicks will register and which won't, so I'm tempted to wait for FF33 which fixes the stroke hit testing which 378ac45 relies on. |
|
iD 1.5.2: This residential area got mistakenly selected and was changed into natural=spring: https://www.openstreetmap.org/changeset/24318834 The thread about the selection bug in iD in the german subforum has now over 13 pages: http://forum.openstreetmap.org/viewtopic.php?id=21611&p=13 I alone had to fix about five cases this week where residential-areas were changed into buildings by different iD-users. My proposed solution would be a double-click (like in JOSM) to select huge areas instead of the misleading one-click. |
|
Dear developers, Me and how I think about this issueI am one of the German forum members who care for quality assurance in Germany. I regularly (4–7 times a week) have a look at a couple of areas in Germany using WhoDidIt, rural areas (East Germany, Heilbronn area) and urban areas (parts of Karlsruhe). As a summary of the last weeks, I can say that the problem of rectified or cicular polygons has decreased. But the other problem still exists. An iD user wants to add or modify a node-shaped POI. To do so, he tries to select the node but, instead of the node, the landuse area behind is being selected. That's the way villages and towns become banks, atms, fast food POIs etc. See the following link list of recent problems.
Not only newbies make POIs out of villages against their will. The same happens if a advanced JOSM user just wants to try "the quick and dirt editor" [1]. This has not been fixed for about 1 1/2 years. It makes me to have a detailed look at almost all edits using iD in the areas I observe using WhoDidIt's RSS feeds. I have been using WhoDidIt for quality assurance since the time iD was pre-alpha and not available at osm.org. I know the time before iD. Potlatch 2 has also a not very good reputation in German forum, but the one iD has is times worse than Potlatch's reputation! The round-and-restaurant-iD-problem is the cause, why I always suggest every newbie, who receives a welcome message from me (containing information about the right use of name tags), to use JOSM. This messaging might refuse a lot of newbies editing any more but I do not want to repair a village or revert a changeset a day. Solving this issue is easy, isn't it?But I do not want to complain without a suggestion to solve this issue. I know that you refuse to add warnings. Why don't you disable selecting areas by clicking inside them? JOSM does not have this issue because you can select areas only via clicking on the outline of the area. [2] What do you, dear developers of iD, think about this suggestion? I am hating iD at the momentAs you might have read between the lines, I currently hate iD. I can change from hate to acceptance if issues like this are being resolved. I do not like to write how-to-JOSM in every newbie message. Keeping quiet about iDA few German mappers (not the ones from forum) and me will present OSM at the professional geodesy and geoinformation trade faire "Intergeo" in Berlin on 6th–9th October as the years before. Last year I kept quiet about the existence of an online editor when I was asked about how to edit OSM. (Most visitors have experience in using more or less ugly GIS GUIs) If iD becomes better, I will talk about iD, too. Best regards Michael [1] quote from an message I received as an answer on my message "you have made a bank out of a village, I corrected it" EDIT: JohnDoe23 at German Forum |
|
Stroke hit testing seems to be better in Firefox 31, so I've deployed a change mentioned earlier in which
Since almost all the reports of mistaken edits have been for |
|
I am curious if we will notice a decline of mistaken edits. I myself would expand this stroke-rendering on all landuse and natural polygons. This would be easier than maintaining a tag list. If landuse polygons can only be selected at this small strip along the outline, I am satisfied. Thank you for your quick response/commit. |
|
Hi, On 29.07.2014 21:07, Michael Reichert wrote:
|
|
Michael Reichert schrieb
How will this work when there are two landuses sharing the same nodes? |
|
2014-07-29 20:12 malenki wrote:
The selecting strip is inside the area. If two landuses are neighbours, |
|
Part of a forest (http://www.openstreetmap.org/relation/1630678) was made a school (the issue was reported in the German OSM forum). |
|
@PeterPablo - that change was back on July 10th. Whilst the iD developers are I'm sure very ingenious, time travel I suspect still eludes them. |
|
@SomeoneElseOSM @jfirebaugh As far as I understand commit b4fa085 would not take care of this kind of issue due to different tag content of "landuse" (e.g. "meadow). @razor74 suggested to extend the behavior to all landuse and natural (multi-)polygons. |
|
It's been a while since I've seen any newbie iD created "huge buildings" - the fix definitely seems to be working! Thanks again. |
When I'm editing with iD I tend to click "off" (i.e. attempt to remove focus from the selected object) an object so the tag editor goes away and I get more editing space. In an area with big polygons (near my apartment has a landuse=residential behind a bunch of buildings in live mode) this attempt to deselect causes a radial menu to show up for the polygon. Since there's no indication that an object is selected (other than a green tint on the Bing imagery), I was really confused about what was going on.
This isn't really a bug as everything's acting as it should, but it certainly is confusing.
The text was updated successfully, but these errors were encountered: