Comments (11)
Did a little digging in, this is a projection issue...
- The map is displaying 3857 (all these are EPSG code references...)
- GM3.10 stored measure distances as 3857 then reprojected to UTM for Measurement.
- GM3.11 stores distances as 4326. UTM is used for length but now 4326 instead of 3857 is being used for the bearing calculation. Arguably, that is the "true" bearing, but this is a difference in behavior between versions.
from gm3.
I think bearing in UTM (or some other local grid) is appropriate. Same as distance. The "usual suspects" like 4326 and 3857 can all cause problems (unless the underlying library is already doing tricks to account for this- see also PostGIS geography, https://postgis.net/docs/manual-3.3/using_postgis_dbmanagement.html#PostGIS_Geography).
Selection of UTM zone (or some other local grid) being appropriate is mostly true for "local" work which I think most GeoMoose sites are aimed at. If making a site for worldwide great circle distances and bearings, then a different approach is probably needed (see again PostGIS geography data type and functions, https://postgis.net/docs/manual-3.3/using_postgis_dbmanagement.html#PostGIS_GeographyVSGeometry)
4326 "bearings" are mostly a function of latitude. See this correct example in Quito (on behalf of the 0 degrees latitude):
A 100 by 100 meter right triangle with 45 degree angles (within the limits of my hand drawing) matches what we expect from geometry.
Likewise a high latitude example being very incorrect:
Does OpenLayers do some underlying tricks for 3857 bearings? If so that could be considered, otherwise, UTM (or some other local grid) is appropriate for bearings on the "local" scale (city, county, state; breaks down by continent). For convenience, I'm ignoring the convergence angle since I think that starts to get to a level of complexity beyond most GeoMoose site configurations and uses).
from gm3.
It must not actually be doing the math in 4326 proper (spherical), but doing the math using 4326 coordinates but as a rectilinear coordinate system. Then the aspect ratio gets more squished the further from the equator.
But, either way, in the demo area, Grid North (UTM15), True North, and Magnetic North are all effectively the same (just luck of where the magnetic pole is and that the demo area is about central in the UTM zone).
https://mdd.sharedgeo.org/mdd-gen?date=2019.0&lat=44.55&lon=-93.15&zone=15&of=png&width=150&height=180&submit=Generate+MDD
So, I think there are two issues here:
- Defining what we mean by North. My guess is True North is what we should be using. Using UTM grid north can be noticeably off from True North (2-3° at zone edges in CONUS), is somewhat arbitrary, (and doesn't even make sense over the poles eg. EPSG:3413). Magnetic north moves around all the time and requires updated model data so probably isn't something we want to deal with.
- Applying rectilinear math on a spherical coordinate system
from gm3.
Magnetic north- this is worse than spherical triangles, I agree, magnetic north isn't something we want to deal with.
Using UTM (or any other local grid) adopts grid north which typically matches true north near the central meridian (see also other types of projections). This means it matches in that area and then is off a systematic amount in other areas towards the edges (like @klassenjs says a convergence angle of 2-3 degrees plus and minus at each edge of the grid is to be expected). I think that this is fine and applying the convergence angle is up to the user if they want to (or they default to grid bearings). I think that we should adopt grid north as our north, complete with the limitations that come with this choice. This also appears to be our previous behavior.
Yes, it is true that the existing math is not showing geodetic bearings (that perhaps would have worked correctly) but rather some (inappropriate) rectilinear math with spherical coordinates. I don't think that we want to go full geodetic or wander into spherical triangles. Going full geodetic could be an option in the future (and increasingly so as proj advances). I think that this should be a separate future development (if we want to pursue it).
from gm3.
If we go with grid north, and we are dynamically picking a grid other than the displayed map projection, I think we need to at least state which grid we are using. (Although, this is really just another symptom of "everything is 3857" not being good enough.)
from gm3.
Stating the grid could be useful. That level of detail may be more appropriate in the documentation rather than the UI. Hopefully configurable to include or not and subtle. You won't hear me cheering for 3857.
from gm3.
Another approach of leaving the convergence angle to the user would be to have a user input field on the measure line tool like
Rotation: -2.4
and then we apply that to all the bearings results. That lets the user either use default local grid north or determine the convergence angle and apply it. This would add complexity to the tool (at least on the user side, it would leave a do nothing, accept zero -or some other configured default, and use the results path). If going this route, configuring a default rotation would be really helpful since in many cases the admin can "determine the convergence angle" and the user might not be able to readily do that.
from gm3.
If the user or admin is specifying the convergence angle, they will need to know from which grid the angle is measured. This implies that either the admin sets the grid, or if GeoMoose guesses, it tells the user/admin.
(And this is all ignoring areas near the poles where 3857 and UTM completely fall apart, but that isn't a new problem.)
from gm3.
Good point. It would otherwise take a little bit to figure it out.
(that 3857 pole headache will be hanging around for another few decades.)
from gm3.
Updated code piggy backs on the UTM code used for length calculation. We could bring in geographiclib but this latest change will fix the difference between 3.10/3.11 and also ensure the line math is all in a consistent projection.
from gm3.
Fixed by #837
from gm3.
Related Issues (20)
- 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
- 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
- Map-Source AGS w/ WMS legend retrieval and display HOT 1
- Custom query does not work
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.