[Meta] Adjusting rendering at different latitudes #3859
Comments
|
Yes, optimization of styling for a specific latitude range, usually quite high, has been a frequent strategy, not only but also in this style. If you want to determine the optimal latitude to optimize for there are essentially two possible more or less neutral optimization criteria:
In the latter case the resulting latitude is somewhat higher than in the former case obviously due to the shape of the scale factor curve. However the sensible way to deal with this is not to optimize for a different latitude range and to substitute one discrimination with another. Our current documented goals are quite clear on that. I specifically wrote this with the scale factor problem in mind: Both physical and cultural geography differs a lot globally and the aim is to represent this variety with equal determination - well mapped areas are not supposed to have more weight here than less mapped parts of the world. This also means the target map user is the potential global map user and no special consideration is given to the current geographic distribution of actual map use. How to accomplish that is a different matter. We have in general made some progress over the past ~5 years in testing changes at a larger variety of geographic settings but we also rejected the possibility of dynamic latitude based adjustment of line styling in #1290. We have not made a similar decision on latitude dependent selection of features - but that is only possible if you have a continuous importance rating for the feature in question. For settlements for example you cannot start rendering villages one zoom level earlier starting at latitude X - because this would look extremely ugly and confusing on the map. If you had a continuous rating from hamlet over village to town for settlements you could simply smoothly adjust the threshold for showing them depending on latitude. The best strategy to deal with the latitude dependent map scale is in my experience to style things in a way that minimizes scale dependency to properly work. Rendering polygons mostly without an outline for example - which this style has done from the beginning - is an important factor in that regard. It minimizes the amount of noise resulting from showing things early when features are still very small. We did the same for buildings, originally for z13 and z14, now only for z14. More generally speaking: Not just dropping things from the map at the lower end of their zoom level range because this leads to a cleaner map in a specific setting (like it has been done with highway=footway and waterway=stream recently) but thinking of a way how to show these things so the map looks decent in areas where the local map scale would warrant not rendering them while also keeping them visible in light of those areas where they need to be shown is another possibility. |
|
I would be most happy if we just change WebMercator for something else instead of workarounds, in the long run. We were discussing it in a limited way from here #2688 (comment). |
|
I opened this issue because recently in #3856 it was suggested to consider how the rendering would be affected for a feature located at 66.7 degrees north. But considering both 66.7 degrees and 0 degrees equally means that we would be making the best rendering for 51 degrees north. To find the ratio of the map scale from the equator to the target latitude, use In fact, the difference in scale from the equator to 17 degrees (4.5%) is the same as the difference in scale for the 2 degrees between 51.5 and 53.5, for example, from southern to northern Netherlands. The difference between the southern coast of England and the northern border with Scotland, 50.5 to 55.5 degrees, is the same 11% difference seen from the equator to 27 degrees! This means that optimizing for the equator gets you the whole tropics and subtropics - over half the world, but optimizing for London doesn't even get you to Edinburg. For these reasons, and due to the increasing population in the tropics due to growth in Africa, Asia and the Americas, I believe our current focus on northern Europe (45 to 55 degrees) is a mistake. I also think it's an error to consider 60 degrees equal in importance to 0 degrees: recall that almost half the world lives near 0, while 1% lives near 60. I agree that we should do our best to get a good rendering from 0 degrees to 60 degrees, if possible, and I would recommend that we continue test changes in 2 or 3 different areas. For example, in the 50's (northern Europe), in the tropics (0 to 20 degrees is close enough to the scale at the equator). If possible also check in the mid-latitudes, around 30 to 40 degrees (eg. Japan, Southern USA, China, Australia, South Africa). But if it's not possible to get a reasonable rendering both at 0 and 60 degrees (where the scale is half that at the equator, or 1 zoom level off), we should prefer optimizing for the equator rather than for 55-60 degrees, and I don't think it's possible to worry too much about the arctic circle (66.6 degrees and up) This would mean reconsidering a number of decisions about initial and final zoom levels and widths of linear features, to better consider lower latitudes. |
I agree this would be great, especially at low zoom levels, but technically it would be complicated. I'm not sure if it's possible to get a good world map rendering at z3 using Mapnik and Carto-CSS only? I would also be interested in reconsidering the decision in #1290 to not adjust features dynamically based on latitude. |
|
I think the ultimate solution is to use proper engine which shows the globe as a ball, as it is in reality. The highest zoom level, the smaller the problem is, so where OSM is the strongest, it is not even visible that we use this, it looks like a 2D, only on lower zoom levels we show a 3D ball. There is a proof of concept here and this is even a ready to use tool (CesiumJS is an open-source JavaScript library for world-class 3D globes and maps. - you can even use OSM Carto skin): |
|
The choice of projection falls under 'there is no good answer'. I don't know how important it is to have the main server show good proportionality at small scale (that is, at low zoom levels). It's far more important to preserve continuity - as you go in to larger scale (higher zoom levels), the eye can follow the shapes, and to have conformality - at large scale, it's important for objects to have the same shape on the map that they do in the field! There are actually rather few conformal projections that will work for the whole Earth without either needing discontinuous tilings (the symptom of which is that you will scroll, and eventually scroll off the edge of the map and have to recalibrate yourself). Mercator is one of them, which is why it got chosen to begin with. UTM (Universal Transverse Mercator) is great at large scales, and I use it almost exclusively for large-scale paper maps. It suffers from the drawback that it is not continuous when you cross the meridian that separates zones. I've encountered this issue when producing some maps of parts of Georgia for a friend, and dealt with it in the usual fashion (for a paper map) of artificially choosing one zone (17S in the case at hand) and extending its coverage so that all the sheets were in the same projection. An endlessly-scrolling tiled map doesn't have this option. Life is full of tradeoffs, and fitting a round earth into a set of rectagular tiles is a particularly awkward one. Hearing the original complaints, the issue seems less to be one of proportionality - the fact that Greenland looks bigger than Africa at z3 is not the issue - and more one of rendering. The tiles in the Equatorial regions are more condensed than at high latitudes, and objects begin appearing at inappropriate zoom levels because of this, leading to a crowded and difficult-to-read appearance. I would wonder if the latter issue could be addressed by making the choice of 'what level to change rendering' based on the scale at the center of the tile (not too bad to determine - just multiply the nominal scale denominator by the secant of the latitude) rather than the nominal scale of the map (which is based on the fraction of the length of the Equator subtended by a tile). If the features that appear at z13 in England did not appear until z14 in Ecuador, that would effectively compensate for the fact that a tile at a given zoom level in England covers only 61% of the linear distance (or 38% of the area) of a tile at the same zoom level in Ecuador. |
I tried to explain above that you can't make display decisions from a discrete classification (like in my example: populated places of class 'village') based on spatially variable criteria without creating a discontinuous map. Specifically you'd have the display of villages stop at the edge of a certain tile at some zoom level which is just not feasible for a map that intends to be useful. You either need a continuous importance measure for features (which is hard to generate in a suitable form - the abuse of way_area and the negative side effects on mapper feedback this has is testimony to that) or you need ideas how to continuously change styling (which in one specific form has been discussed in #1290). On a more general note: Discussions of other map projections, their benefits and issues as well as alternative display systems for cartography other than tiled interactive maps are off-topic in this issue and mostly also off-topic on this issue tracker. Yes, these are interesting matters and there is way too little interest in and knowledge of these things in the OSM community. But this is not a simple subject by any measure. @kennykb just hinted on a few of the technical and map viewing ergonomics related matters that come with the subject and that does not even cover what parts of the map rendering framework we use are hard-tied to Mercator. And none of these things is a subject for this issue tracker. |
|
On Sun, Sep 1, 2019 at 4:22 PM Christoph Hormann ***@***.***> wrote:
I tried to explain above that you can't make display decisions from a discrete classification (like in my example: populated places of class 'village') based on spatially variable criteria without creating a discontinuous map.
What if the decision were to be made based on the latitude of the
centroid of the feature, rather than the tile? The only problem there
would appear to be features that span a vast expanse of latitude, and
I'd expect those would show up at any zoom level whatsoever.
…--
73 de ke9tv/2, Kevin
|
|
This would still mean that features like villages would suddenly stop
at a certain latitude at z12; it would look odd when viewing the map
near that latitude.
If most villages had populations we could use this to gradually show
villages with lower populations at higher latitudes, but most
place=village nodes do not have a population.
Linear features like rivers and roads could have their rendered width
gradually adjusted, but you could not have them suddenly disappear at
a certain latitude.
|
|
I have a concrete suggestion for anyone who is reviewing PRs: in addition to testing in your home area, also check at low lattitudes, when relevant. If you currently usually load up a database extract that contains your home city or home country, an easy addition would be to download singapore.osm.pbf from openstreetmap.fr (link to 20MB .pbf download) - it's not too large, and provides a good variety of urban features at high density, right near the equator. Unfortunately I don't have a great suggestion for a rural area in the tropics which is really well mapped. Perhaps there is somewhere in Taiwan, or West Africa, or Central America? Anyone have a suggestion? Hawaii has some rural areas and is only 12 mb: ((12 mb .pbf file) For those who already live at low or mid latitudes (e.g. Southern USA, Australia, or lower), there are several smaller extracts which you can try from high-latitude areas:
In the mid-latitudes, there are a number of good options:
|
|
Although it does not hurt to test changes in addition in a fixed set of places that is not really what testing in a larger variety of geographic settings is about. That requires getting a sense of the variety in world wide geography and a sense for what kind of settings are important to evaluate for the change you are working on. The high latitude urban areas mapped in most detail are likely:
Some examples of different non-urban settings that can be helpful for testing can be found on http://www.imagico.de/map/ac_samples_en.php. Also as a reminder - we do not specifically want to optimize the map for areas mapped in a lot of detail, we want to support mapper in improving the map at any level of detail and quality it might have. If we move the starting zoom level of all features so high that even in the densest area with the most detailed mapping they don't appear too crowded that would mean mappers working in much less dense areas or just starting to map things in their area will not get much supportive feedback for their work. |
|
Closed, since this discussion is finished for now and there are not specific, actionable items. |
Currently this style, like most web maps, is rendered in the web Mercator projection. This would be difficult to change, but it results in difficulties adjusting rendering for both the equator and high latitudes, in addition to distorting shapes and areas at high latitudes (see #2688 for some discussion of this).
Assuming that we are not going to start adjusting features based on the scale of each tile, how should we optimize the rendering? What latitudes should be considered?
Currently, it appears that most decisions about initial zoom levels, line width and similar decisions have been made based on looking at areas near 52 degrees. This is due to the historical development of OSM, beginning in England and northern Europe: London is at 51.5, Amsterdam, Berlin and Warsaw are just over 52 degrees.
However, only about 1 in 10 people live above 52 degrees, almost exclusively in northern Europe, while 50% of the global population lives below 24 degrees (source, also see pdf, including the majority of the populations of Latin America, Africa, Asia and the Pacific.
40% of global surface area is found in the tropics, between 23.4 degrees north and south (a fact that is obscured by rendering with Mercator).
The text was updated successfully, but these errors were encountered: