Polygons beyond the edge of the screen cause confusing radial menu
iandees opened this issue · 57 comments
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.
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 area-rendering branch:
@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:
@razor74 https://github.com/razor74: This changeset
http://www.openstreetmap.org/browse/changeset/17988304 was made with
an older version of iD (1.1.6). In the meantime these problems have
been addressed in a variety of issues, for example by solving a
selection problem (#1693 #1693)
and improvements on the orthogonalize tool (#1831
#1831).—
Reply to this email directly or view it on GitHub
#542 (comment).The problem still persist.
http://www.openstreetmap.org/browse/way/84792537
Here , one day ago a coleague revert the same change made accidentaly to
Brasov landuse residential.
On 13.10.2013 18:18, Razvan wrote:
On 12.10.2013 00:04, Martin Raifer wrote:
@razor74 https://github.com/razor74: This changeset
http://www.openstreetmap.org/browse/changeset/17988304 was made
with an older version of iD (1.1.6). In the meantime these problems
have been addressed in a variety of issues, for example by solving a
selection problem (#1693
#1693) and improvements on the
orthogonalize tool (#1831 #1831).—
Reply to this email directly or view it on GitHub
#542 (comment).The problem still persist.
http://www.openstreetmap.org/browse/way/84792537
Here , one day ago a coleague revert the same change made accidentaly
to Brasov landuse residential.
Hello
Again the same problem. You can see in this changeset that this user
after aded a school, ID editor vers. 1.21 changed landuse = residential
of Bucuresti city in building = yes.
http://www.openstreetmap.org/browse/changeset/18435905
With editor ID vers. 1.21
landuse = residential of Bucuresti city changed in building=yes
It's still happening:
http://www.openstreetmap.org/browse/changeset/19099731
http://www.openstreetmap.org/browse/changeset/18960057
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.
A thread in the German part of the OSM forum named "iD deforming landuses" collecting this kind of issues is 9 months old and 11 pages long: http://forum.openstreetmap.org/viewtopic.php?id=21611
There was already alot of damages done with it. I think you must put back the Potlatch 2 as a default editor, at least until you will resolve this bug with ID.
Here is another one - Romania , near Miercurea Ciuc. I already revert it.
@razor74: What would be the advantage of setting an editor as default which us outdated, out of development (afaik) and based on a proprietary technology?
Admittedly, I don't like iD – but I like Potlatch still less.
Why not set JOSM as default?!?!!11
What outdated? What you can do with id (out of destroing big poligons)
and cannot do with Potlatch? It seem you didn't know that the most of
map coverage ( in terms of street coverage and POI) was done woth
Potlatch from some years until now.
But you see, i din't have a problem with which editor to be default
between potlatch and JOSM. I like JOSM too. But the problem here is -
the beginers. You cannot put and advanced editor like JOSM in a hand of
a begginer. He canot do anything with it...
And in conclusion - if osm staff want ID to "be the king" , then they
must hurry to correct this bug. We cannot stay with eyes on any begginer
that want to draw a building inside a towns residential area or inside
any other big poligon.
On 12.01.2014 01:14, malenki wrote:
@razor74 https://github.com/razor74: What would be the advantage of
setting an editor as default which us outdated, out of development
(afaik) and based on a proprietary technology?
Admittedly, I don't like iD – but I like Potlatch still less.
Why not set JOSM as default?!?!!11—
Reply to this email directly or view it on GitHub
#542 (comment).
razor74 wrote:
What outdated?
As I said: proprietary flash and out of development. Newly found bugs
don't get fixed.
It seem you didn't know that the most of map coverage ( in terms of
street coverage and POI) was done woth Potlatch from some years until
now.
Yeah, I also don't know that JOSM by numbers of changesets and edits
outruns iD/Potlatch.
Do you want to start another "best editor war"? Go that way on your own.
But the problem here is - the beginers. You cannot put and advanced
editor like JOSM in a hand of a begginer. He canot do anything with
it...
If you think so...
As I started with OSM there was only the choice of Potlatch and JOSM.
Inexperienced as I was I signed in, clicked "Edit" and seemed unable to
do anything after clicking one time the mouse pointer dragged a way
around and I couldn't do anything else. At least I was lucky to be able
to close the tab.
Since RTFM is for sissies I looked if there would be a better editor,
found JOSM and never looked back.
It seems I am a singularity.
And in conclusion - if osm staff want ID to "be the king", then they
must hurry to correct this bug.
It doesn't matter if someone wants any editor to be crowned or drowned:
Bug have to be fixed.
On 12.01.2014 11:49, malenki wrote:
Do you want to start another "best editor war"? Go that way on your own.
I don't want to start a war. I want things to work like you want, or any of us want.
And again. One or two times per week. Great. Keep that way ppl! You do great Job...
@razor74: please keep it polite, and constructive. I think all the developers are aware that it's a continuing problem, and what is needed now is not more commentary.
Hi. If helped you, i think (after run some tests and see when it happens) - it happen only when someone add a building or other building category inside and NEAR the margins of the poligon. If the building is added in the centre (far from margins) of the poligon, nothing wrong is happened...
A simple solution seems to not allow the make circular, square corners etc, operations on polygons that are bigger than some set size per zoom level. It could just be a map like {zoom level 10: 100km, zoom level 11, 60km} (super pseudo code obviously!). With a little bit of experimenting one should be able to get some good defaults that should prevent 99% of accidental screwups.
Anders Hovmöller wrote:
A simple solution seems to not allow the make circular, square
corners etc, operations on polygons that are bigger than some set
size per zoom level.
Why not restrict "make circular" for polygones completely visible in
the editor window? I cannot imagine sensible use cases to make areas
circular of which only a fraction shows up (if at all) in the editor
window.
See #1702 for this.
@jfirebaugh's main concern was:
Implementing [this] would make many large polygons un-editable in iD -- by the time 50% to 75% of their area is visible, you're at z15 or less. Many areas have too much data to render at that low of a zoom level, which is why the limit is z16.
@malenki Well I was suggesting the simpler solution above because people in this thread seem to think the suggested solutions are all too hard to implement or in other ways not feasable. "Completely visible" for example might be a bit rough to calculate.
Technically speaking, visibility calculations are no big deal (iD already does it for a variety of other things internally).
fwiw
Circle created by iD yesterday and repaired today:
http://forum.openstreetmap.org/viewtopic.php?pid=404680#p404680
I'd be cool with hiding large areas, I use iD mostly for local edits...
Alternatively it should be made more clear that we are editing a large polygon (there's still the M command to enable moving areas? Something like this?)
On 17.03.2014 08:52, sabas wrote:
I'd be cool with hiding large areas, I use iD mostly for local edits...
Alternatively it should be made more clear that we are editing a large
polygon (there's still the M command to enable moving areas? Something
like this?)—
Reply to this email directly or view it on GitHub
#542 (comment).
Well, finally - something must be done regarding to this problem. It is
is clear that new mappers couldn't know what to do. They will try only
to edit a map for the first time. Most of them never used a map editor
before. And the problem could apear continuosly. And we couldn't stay
with an eye on them and send attention mails... Some of them scared
about what just "broke" on the map, and because didn't know what to do,
they preferred to delete the entire poligon.
Next circle made from a landuse=residential:
https://www.openstreetmap.org/changeset/21271183
I'm going to keep this open; #2170 will help with the unintentional circularization/orthogonalization, but there's also unintentional tag changes that sometimes happen.
Hello,
Again the same and unresolved problem...
https://www.openstreetmap.org/way/84830291
A landuse residential poligon transformed in building = yes
For info, still happening in the UK too (at least 3 examples in the last couple of days).
Today the entire Romania capital - Bucharest was changed in building.
https://www.openstreetmap.org/relation/3474715
I implemented a fix for this by replacing the fill for things like landuse=residential with a wide stroke clipped to the area, but it is affected by a showstopper Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=676001 😦
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..
@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
iD 1.4.0: here a whole country got selected and was changed into an building: https://www.openstreetmap.org/changeset/24006429
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 issue
I 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.
- a village became a bank
- a village became a reataurant
- User JohnDoe23 reports that he has corrected five residential areas last week!
- There might be a couple of other recently uploaded bad changesets like these which have been fixed without notice at forum.
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 moment
As 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 iD
A 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
(Nakaner)
[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"
[2] In JOSM you can make a double-click to select an area.
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 landuse=* areas are no longer fully filled.
Since almost all the reports of mistaken edits have been for landuse=residential, I believe this will address the issue without sacrificing usability. If necessary we can expand this rendering to other tags.
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,
I sustain your idea with expanding stroke- rendering on all landuse and
natural polygons.
On 29.07.2014 21:07, Michael Reichert wrote:
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.
—
Reply to this email directly or view it on GitHub
#542 (comment).
Michael Reichert schrieb
am Tue, 29 Jul 2014 11:07:24 -0700:
If landuse polygons can only be selected at this small strip along the
outline, I am satisfied.
How will this work when there are two landuses sharing the same nodes?
2014-07-29 20:12 malenki wrote:
Michael Reichert wrote
Tue, 29 Jul 2014 11:07:24 -0700:If landuse polygons can only be selected at this small strip along the
outline, I am satisfied.How will this work when there are two landuses sharing the same nodes?
The selecting strip is inside the area. If two landuses are neighbours,
still click into the area. If the two (landuse) area cover the same
area, something might be mapped the wrong way. :)
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.