[Patch] diversify zoom-level when zooming onto a small object

[skyper]

Hi again,

please, use a higher zoom-level when zooming to (zoom to selected) a single node. Right now, it is often hard to catch with your eyes the selected node if there are some nodes around it.

Thanks a lot

[skyper]

Zoom-level when zooming on small elemets should be adjusted.

Right now I think it depends on the elements around.
For example: I can find "nodes without a connection, nor a tag" easily in the outside area, but I can not find them in a heavily loaded area of a 4 way connection with lots of extra lanes and footways.

Zoom-level on nodes should be adjusted to the number of elements around it. more elements -> higher zoom-level.

For ways: I can have a way of 2 nodes of a lenght of 0.5 meters or less up to kilometers.
Right now zoom-level is only adjusted if the way is big but not for tiny ones.

Zoom-level should be adjusted to the length of way.

Thanks

[skyper]

I rewrite this bug an turn it into an enhancement since JOSM works right but it is often hard to find small objects.

Write now it is often hard to find selected node(s) or short way(s) if there are many other objects around the selected ones.

A fast fix would be: set the min-zoom-level higher.

A real fix would be: investigate the area around the objects and adjust the zoom-level:

• for nodes: use a higher zoom-level if there are many other nodes around the selected one/ones.
  
• for way: the length is important (fixed through higher min-zoom-level) and also it is important if there are many other objects close to it.

Thanks a lot

[skyper]

Please, use this file

attachment:true_overlapps.osm:ticket:4582​

• select an object
• use "zoom to data" (1) and "zoom to selection" (3)

imagine an even bigger and more dense data layer !

[skyper]

This is still a pain.

Please guys. It is much easier to zoom out once the object is spotted than to zoom in and search.

[xeen]

The attached patch uses the 'fast fix' as described above: It enlarges the bounding box of the selected items by 100%, i.e. they will fit at least twice on the screen in each direction (it depends on the object and the available view space which direction allows less space). In other words, there’ll always be a "half object" space around the object. Special case for single nodes: they don’t have an extent, so enlarging them by 100% still yields 0. Instead, the bounding box will be made at least 0.0007 degrees wide. On reasonable sized monitors this is about the size of a larger intersection.

I made an attempt at the 'real fix', but ran into performance problems (essentially zooming in and enlarging/shrinking the bounding box until the "crowdedness" was too high or size constraints were met). From my limited testing I believe the fast fix is good enough, at least as an intermediate until someone comes up with a better idea.

Compared to the current method, this zooms in more for small objects and less for large objects. The current method simply added 0.002 degrees to the bounding box (the in-code comment suggested the original value was 0.001 degrees, but it appears the default was changed. The value can be configured by an advanced pref).

This patch affects zoom to selection and zoom to conflict.

Please apply and test this patch, I will continue using it to see if I missed an issue. The values can obviously be modified.

I am aware this patch removes the ability to control the min zoom in level. However, as far as I understand the author of the original ticket (#3527), the configurability is not required with this patch anymore.

[xeen]

v1

[simon04]

This patch seems to be working nicely for small objects (such as houses or objects from attachment:true_overlapps.osm:ticket:4582​​). When zooming to a large landuse polygon (e.g. way 28617014) however, I find the old behaviour more adequate.

What about using your implementation for small bboxes and keeping the old one for larger ones. A suitable decision criterion would have to be found. In a small test, I found your implementation comfortable for objects smaller than 500m and the old one for larger ones.

[xeen]

Can you give me a concrete example where zoom to selection with large objects (like landuse) comes in handy? I couldn’t think of one, so it’s very hard for me to judge how well the patch performs. I tested with way 28617014 and I’m indifferent to either solution.

Another option would be to scale logarithmically, i.e. add less context as the selected objects become larger. Small objects, like houses would then have 100% context added and large objects in the order of 1-10%.

[simon04]

When zooming to a long rural road (like way 143476805 or 25706383), I find it more helpful to have it as large as possible. As you said, it's easier to zoom out than to zoom in. This may be dependant on the screen resolution and is only a personal feeling.

The logarithmic zooming sounds interesting!

[xeen]

Updated patch with logarithmic scaling. This patch is not final, as I haven’t updated the description or integrated it nicely. Zooming for large objects should be about the same as the old method, while retaining the higer zoom ins for smaller objects. Can you please see how that works for you?

[simon04]

I like it, the zooming seems really intuitive to me now. :-)

[Don-vip]

I love it too !

[xeen]

In 6608/josm:

improve zoom to selection/conflict when the objects in question are small (fixes #4413)

[xeen]

happy new year skyper :)

[stoecker]

Wow. More than 5 years to fix a workaround solution where I never found time to think about a proper way. :-) Logarithmic sounds really fine. Some solutions need their time...

[Don-vip]

Ticket #5222 has been marked as a duplicate of this ticket.