Comments (13)
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?
from gm3.
from gm3.
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.
from gm3.
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)
from gm3.
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:
- 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.
- 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.
- 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. - 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.
from gm3.
- 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).
- Don't care. Something is useful or it shouldn't be there, screen, code, whatever.
- 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.
- 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).
from gm3.
Your current "pro" list is:
- Easier to debug mapfiles. Sure?
- 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.
from gm3.
Did you read all of my comments? Summary: We both say punt.
from gm3.
:) You kept going which made your position unclear.
from gm3.
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.
from gm3.
I'll leave this here if we ever want to implement it in the future
from gm3.
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
from gm3.
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.
from gm3.
Related Issues (20)
- Clicking the select tool highlights identify results HOT 4
- Print Legend Adds Blank Spaces HOT 5
- URL Tracker - Bbox format doesn't exactly track the location anymore HOT 2
- Syncronize mapbooks and app.js across examples
- +/- Zoom Buttons zoom to whole world HOT 2
- Start Service from URL - Add catch error for incorrect field name
- Bookmark - Only pull layers + extent when including service parameters in URL
- Measure - Bearing Accuracy HOT 11
- Buffer All - Inconsistent logic when filtering
- Demo use of Min/Max filter is non-functional
- Add catch error for undefined layers in mapbook HOT 1
- ESRI WMS service ignores INFO_FORMAT=application/vnd.ogc.gml HOT 3
- Configure arbitrary static Legend images HOT 4
- Virtual Grid - Horizontal and Vertical Scrollbar don't work together HOT 1
- Add option to Close Measure Tool HOT 1
- Issue on Add highlight in WFS layer HOT 11
- Sort Grid Filter Results
- If Favorites are not Implemented, hide Stars in Catalog
- Select - KeepAlive - Enter to execute select
- Re-do Service button/Retain service history
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gm3.