Jump-to-Scale about gm3

[CaitW]

Before I proceed, there's an extra layer of complexity - though said complexity depends on our desire to be (potentially excessively) precise.

GeoMoose 2's function for retrieving the current map scale was dependent on an OpenLayers 2 function, map.getScale(), which relied on a utility function called getScaleFromResolution.

Openlayers 3 doesn't contain either of these functions. OL3 produces a resolution ([projection unit] per pixel), but doesn't provide scale.

OL2 relied on a constant, DOTS_PER_INCH, of 72, which would allow conversion of a resolution to a scale:

var scale = resolution * OpenLayers.INCHES_PER_UNIT[units] * OpenLayers.DOTS_PER_INCH;

We could simply rewrite the function from OL2. However, with more and more mobile devices and high resolution screens, setting an arbitrary DPI of 72 will suit a decreasing number of devices. For example, the DPI of my laptop's screen is 227, and my external monitor is 157. An iPad is listed at 324.

Furthermore, automatically detecting a screen's DPI is problematic.

It is somewhat more difficult to determine how many pixels are rendered per inch of display area (pixels / inch of display area) since the monitor display size and resolution must be known - usually referred to as ppi (pixels per inch). Unfortunately, client-side scripting (i.e. JavaScript, VBScript) cannot retrieve a client's viewable display area in a measured unit, therefore we must prompt the user to provide this information.
via Esri

stack overflow #1, #2 , #3 etc...

Therefore, before I spend any more time on this - how much, if at all, do we care?

[klassenjs]

We care a lot on the PDF outputs. For the screens, scale seems a bit meaningless especially since the transition to fake pixels as a kuldge to make hidpi devices work. A lot of windows machines also don't report dpi correctly (mac has been extremely good at that in my experience. Display a ruler in preview at 100% and it matches an actual ruler). Though isn't there a trick of setting a CSS width to 1in and then reading it back as px (yep, notices your linked docs)? You could then get the map width in px and convert that to inches. I suspect the px vs ppx wouldn't really matter in this case as px as long as things are consistent (units OL is using to units pulled from CSS).

[theduckylittle]

Maybe it is just appropriate to abandon this due to the constraints of device dependence issues. I know we could throw some tricks on this but I'd be a lot happier offering an initial component set that is both accurate and functional.

[klassenjs]

My vote would be for make a best effort that scale is meaningful in the interactive map. But make sure the printed scale is correct. (Which is effectively the same strategy as in GM 2.x)

[theduckylittle]

I don't think we need this component. I'm not a huge fan of forward/up-porting all of the previous components "just because we had them." Particularly those that really have fallen out of favor or need by the general user base. "No one else does this" isn't a true answer but realistically this component is problematic or unneeded:

1. The fixed resolutions of the map means that arbitrary scales entered or configured by the administrator will not produce an accurate result. The users actions will not actually present them with the expected result. That alone is hugely problematic to me. An action should have a predictable reaction.
2. I think it's screen clutter. This is just personal taste but I don't think we need another "random" looking drop-down anywhere. I am concerned that it might be component splatter.
3. A real reason for this control would be to do on-screen measurement.
   a. This won't be accurate on any number of screens.
   b. We have scalebar tools available for presenting the user with a more accurate scale based on the requested image size and what mapserver believes the px/units to be.
4. A historical reason for this tool was that it was too slow and too difficult to find certain areas of the map and zoom in and zoom out. That speed problem has largely resolved itself -- the transfer of images is no longer the largest transfer and rendering cost.

The mapping at scale problem is a separate problem from this one. Printing is done in a fixed set of units and we have more control over the presentation to make scales more accurate.

[klassenjs]

1. Not a fan of fixed zoom levels myself, although from your comment I gather they are a fact of life with OL3. (And tiled layers royally suck for local mapping. I get why it is important for the likes of OSM, but it is nothing but rendering artifacts and extra overhead (storage/seeding/invalidating tiles) for most sites).
2. Don't care. Something is useful or it shouldn't be there, screen, code, whatever.
3. It has never been accurate w.r.t. actual on screen scale, but it has been a reasonable link (more or less WYSIWYG) to what is on screen and what is printed.
4. Disagree. It sucks as a zoom tool -- too coarse. The historical motivation was setting a standard print scale (e.g: 1:24000, 1"= 50') and as a debug tool for testing mapfiles (it's value matched the maxscaledenom/minscaledenom values so was a good way to figure out why something wasn't showing up or a way to figure out where to set a limit based on how the map looked or render speed).

That said: listing a scale on the on-screen interactive map has bugged me and bugs me in other apps when it is clearly wrong (because of bad DPI assumptions). If we can provide an accurate (or usually accurate) on screen scale, I think we should. Reading through the CSS stuff Caitlin posted, I don't see why this is so difficult, except for not wanting to do it.

I also don't think we should or shouldn't do anything based on what everyone else is doing. Everyone else is making a world wide slippy map with 3 or 4 layers, limited integration potential, and where it is nearly impossible to make good measurements or see shapes with minimal distortion. We have our own goals.

Print to a user specified scale is a must have (with standard presets and the ability for the user to select a non-standard scale.). I am open to it being done differently.

So... Given the apparent resistance to implementing this, I suggest looking at it again at a later time (assuming a solution is in place to satisfy printing).

[theduckylittle]

Your current "pro" list is:

1. Easier to debug mapfiles. Sure?
2. We used to have it and it used to be broken too. I don't feel like "it's always been broken, soldier on" is a super persuasive argument...

If you look at the links provided by @CaitW then you'd see that, for the most part, they all "agree" that you can't get an accurate DPI on the display.

I'm saying we punt on this until someone is really motivated to request it into the future or at least we're willing to invest some better research into integrating scale into the application at large.

[klassenjs]

Did you read all of my comments? Summary: We both say punt.

[theduckylittle]

:) You kept going which made your position unclear.

[klassenjs]

For the record some testing: CSS div {width: 1in; border-width: 2px; border-color: black}
Desktop Linux, FF, Linux: 1"
Cheap W10 tablet: 0.65"
Phone Starts at 0.2", zooms to whatever.
Phone width=device-width, initial-scale=1: 0.6"

So yeah, all the cheap c**p lies. It's all over the board.

[CaitW]

I'll leave this here if we ever want to implement it in the future

[tchaddad]

Looking through old tickets, I can see this one is basically dead, but wanted to add a comment:

• what if you changed this concept to a "Jump to Zoom Level" element that simply displayed / used the current zoom level of the map (e.g. Zoom level 12, 13, 14, etc)?

People could use this to navigate multiple levels at a time, but also could get a sense of tile scale if they were familiar enough with the Zoom levels at their latitude.

https://wiki.openstreetmap.org/wiki/Zoom_levels

[klassenjs]

You can do this from the dev tools console:

app.setView({zoom: 15});

I know this isn't suitable for end users, but I use it to get around when testing.