-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve low zoom levels #2688
Comments
Oh, I've just found that issue with such name has been already created and closed because some improvements has been made then (#1125). Should we reopen it then? |
Depending on just how wide you want to throw open this issue: z0-3 receive relatively little attention because they are "world map" scale, and the projection we are using is singularly unsuitable for a world map. I know there's a lot of political discussion about "correct" world maps (Gall-Peters et al., cf. https://xkcd.com/977/) but that's not even what I'm talking about; just look at Greenland on z2 and you don't need to be a GIS expert to see that it is absolutely ridiculous, and any sweat invested in dressing up the map with nicer styling cannot hide the fact that it is a bad map (on that scale). A student a local university is currently writing her Bachelor's Thesis on how one could potentially use different projections on different zoom levels in web maps. I'll happily provide a summary once that is published; until now the only things that came out of it were a small web demo with pre-rendered tiles https://www.imm.hs-karlsruhe.de/custom/BT_Pfeffer_Webkartendienst and a survey she sent out to the German mailing list/forum to gauge interest. I recognize that this may be considered a fringe issue for many who would like to concentrate on the map styling, but if you take a more holistic approach then I think it is fair to say that the projection plays a big part in the overall map design, and it might be worthwhile to investigate this further. |
I am fine with a new issue, 2 years later. We can clearly learn a lot from http://tile.openstreetmap.fr . |
Well - that is not really a statement you can argue but
The really advisable conclusion to draw from the shortcomings of Mercator at small scales is to offer different projections for different parts of the world (and of course a convenient way to switch between them). This would be great to add here but i have my doubts this will happen any time soon. After all this would be truly radical - AFAIK there is currently no map service that does this based on the common map styling tool chains. In my opinion the most important and most immediate need for improvements we have in the whole lower zoom level range regarding mapper feedback and map usability is z5-z8. If there is a solid concept for these the rest will likely fall into place without much problems. But this would require looking at the big picture - what are our strategic plans and goals for these zoom levels? What are the technical constraints and the technical needs to make them work well. And if the general feeling is to include other map projections in these considerations i am all for it. |
It'd be nice to have non-Mercator when at the worldwide zooms, but I don't see that's something we can fix within the context of OpenStreetMap Carto. |
As wide as we want, but focusing on things we really can do in the near future (without changing the engine - from Mapnik to something else - or language). This repo is not about the ultimate map, rather about using given tools to achieve the best results. |
Lowest zooms gives us just 2 informations now: shapes of continents and countries borders, so adding landcover there would bo good improvement. It should be pale and match #2654 Some examples of low-zoom landcover:
Another thing is that I don't like violet borders on default style (on every zoom), but here's actually separate ticket for this: #622 (comment) |
Low zoom levels rendering with simple global changes - gray borders + proposed new water color (from midzoom): Europe extract from 12.2016 converted with great lowzoom tool (click to see unscaled images): z3 z4 z5 |
This looks great! Quite likely due not adding any new features, but only making color changes should also be compatible with carto 3.x |
I wait for extended lowzoom tool to make low zoom tests with (at least) tree areas and midzoom rendered landuses if possible. |
Looking at http://fred.dev.openstreetmap.org/lowzoom/ I've found that India looks quite promising as a testbed for low zoom landuses - no need to filter tags (my computer can handle 0,5 GB extract) and big forests are covering it more or less even. From z8 it's midzoom and I have just extended the same color to lowzoom. Full India extract (click to see unscaled images): |
Another interesting testbed - I've noticed on http://tile.openstreetmap.fr/ that Romania is nearly completely covered with trees and farmlands. It's smaller than India, but the export file is also smaller, so I can handle it. This is also midzoom extended to lower zoom levels. Full Romania export (click to see unscaled images): |
Thanks for that suggestion @kocio-pl , that will help a lot. Landuse rendering looks nice to me on these zoomlevels. To structure the discussion, I would propose the following steps:
Some use cases I can think of:
Please add other suggestions! Now I work on the list, I think perhaps we should do the first two steps for all zoom levels, and store it in a text file somewhere? Would that help @imagico? |
In my eyes these two steps would be a good starting point though i would probably sort this less by zoom level and more by scale and to some extent by geographic region. This is significant because at around z5-z8 most use cases globally span a much larger range of zoom levels than at larger scales. And asking what to show in the map formally in terms of OSM features is much less helpful than asking what the user needs to be able to read from the map for it to be useful. If such insights then lead to a better map of course depends primarily on if the right realizations and conclusions are drawn from them. It is all too easy to become trapped inside a mental box of limited ideas apparently without alternatives and then just use the results of such analysis to superficially optimize within that mental box. But ultimately the hardest thing - and this is not limited to but IMO of particular importance at the low to mid zoom levels - is probably to find the courage to actually get rid of things (and i mean this in a broader sense than simply dropping individual OSM features) that cannot be decently shown. Kind of the other side of do something right or don't do it at all. |
Another important feature to improve in low and midzoom levels would be rendering (important) rivers, but currently we lack classification tagging system, so rendering them now would be premature: I have started discussion about tagging it for a start. |
The key “CEMT” seems to be europe-centric. But the key “width” seems to be used world-wide and is quite easy to verify. |
I think it would be hard to tag the width on the whole rivers, stream order classification is much simpler and general, which fits better into lower zoom levels. But of course feel free to test the width for rendering rivers. |
Looking at that map of Poland, I mainly think your fellow country men just haven't gotten round to make a good distinction between rivers and streams ;-)... In countries where people have made a more concerted effort, most of the smaller (side) tributaries end up being classified as streams, not rivers. E.g., just looking up one of the rivers I saw in your small example map in an area west of Kalisz, the "Radęca" that ends in the "Zbiornik Jutrosin" reservoir is classified as river, while zooming in on Bing in iD shows it to be barely 2-3 meters wide. Certainly not anywhere near a navigable river (except canoe or so). I suspect many more would rather classify as "stream"... |
It might be because of that:
Anyway, waterways classification can help review water system in Poland and in different countries, which is a good thing. |
Have you looked at all at how other countries are with rivers? I only have BC data handy, and it's heavily import-influenced tagging. |
It's not a tagging error, so I don't expect any reasonably mapped country to be ready, except for some parts of Africa or Australia probably. With no rivers classification (stream/river difference is visible only on high zoom level) we are not able to show the difference. Maybe adding length tag for rivers would be the easiest thing right now to get only the biggest ones. Or maybe it's possible to measure them like we do with way_area? Examples of rivers in different countries (click to see unscaled images): |
I'd say we have to wait for OSM tagging to become useful for low-zoom rivers before we can consider doing anything with them, so let's put that aside. |
@pnorman Just which tagging You consider important from those mentioned in the thread? Width, length, area, CEMT? I would say that having clear decision here would help improving database toward accomplishing that rendering sooner than later. |
I think I have to test it myself first. I hope that length tag will become more widespread with rivers (currently we have almost 500 such uses) and combined with classic stream order (which is simple to observe - order:classic=1 for all the rivers that run to the sea) it may be enough for rendering. So the first thing would be tagging biggest rivers in the world: |
An overpass query returning a nice small fragment of test data for lowzoom: |
@gravitystorm I really like the admin boundaries you used for your new Neighbourhood map. How did you accomplish this, my guess is it uses shapefiles? Is it based on Mapnik? |
@matthijsmelissen They're just Natural Earth boundaries - 10m admin 0 countries |
I like the general idea you show on this test. Using less reddish colors is nice, however I'm interested how do you plan to deal with problems mentioned in #2695. |
@matthijsmelissen Country labels are too solid for me, but I very like the idea of grey borders! |
I'm not sure, but it's possible that #2688 (comment) (problem with relations tags not being available) can be fixed by osm2pgsql-dev/osm2pgsql#230. |
One of the most hated feature of web maps on low zoom, Web Mercator as a sole view of the world ("OpenStreetMap, like most Web maps, uses the Web Mercator projection"...), can be made less of an issue if using CesiumJS, where you can choose the sphere with an osm-carto skin (containing a bit of sugar): |
sent from a phone
On 28. Apr 2018, at 01:35, kocio-pl ***@***.***> wrote:
"OpenStreetMap, like most Web maps, uses the Web Mercator projection"
is this from our wiki? Because OSM doesn’t use a projection to store its data, it uses coordinates in WGS84. Some OSM based maps use the web mercator projection.
|
No, it's from the image caption on English Wikipedia. Like it or not, probably most of the people have the idea that OSM = osm-carto map tiles + some other services on OSM.org (like routing, address searching etc.). |
sent from a phone
On 29. Apr 2018, at 00:21, kocio-pl ***@***.***> wrote:
English Wikipedia
at least it’s a wiki ;-)
|
Interesting demo of rivers rendering at http://riverbasinmap.com . Their length limits choice for rendering does not guarantee river continuity up to the water bodies on low zoom levels - notable examples: z2 - Missouri (lacking Missisipi) z3 - Brahmaputra (lacking Ganges) z4 - Araguaia (lacking Tocantins) |
One interesting new development is the recent publication of the Equal Earth projection, as jointly developed by cartographer Tom Patterson from the US National Park Service, Bernhard Jenny from Monash University and Bojan Šavrič from ESRI. This projection tries to overcome the shortcomings of Gall-Peters and Web Mercator at global scale, with a relatively pleasant and rather conformal look, contrary to the inherent large shape distortions of Gall-Peters and Web Mercator. Best of all is that, just like Gall-Peters, it is equal-area as well, so giving a "correct" look as well in terms of relative sizes of continents and countries. In addition, due to this aspect, you could potentially use it as the basis for generalization as well using the PostGIS 'ST_SimplifyVW' function. Since Equal Earth is equal area, and 'ST_SimplifyVW' uses effective area as its measure for removing node/vertices from shapes, generalization results should be relatively uniform across the globe if I am right. This would not be the case with e.g. Web Mercator and 'ST_SimplifyPreserveTopology', which bases its removal on a length measure. Anyway, it is probably not directly relevant for a rendering toolchain for webmaps, but I thought it might be interesting for those who hadn't yet seen it. |
"New in version 5.2.0." [ https://proj4.org/operations/projections/eqearth.html ] It could be interesting how would it work with OSM.org website. I guess it would look strange around antimeridian - the map would be discontinued there, except one node on the equator. |
Maybe, in this particular context of alternative projections, it could be interesting to contact Frederik Ramm as well. I just noticed on their Geofabrik website, that they seem to have had a student intern in 2017 working on a prototype "optimized world view for webservices", also related to the Web-Mercator distortions. Don't know what came out of it, but it sounds a bit similar to the Equal Earth project: "August 2017 | Bacheolorarbeit Tanja Pfeffer |
Just came across this other alternative projection, from the same group of people as I mentioned in this post http://cartographicperspectives.org/index.php/journal/article/view/cp78-patterson-et-al/1362 This is less of a deviation of the Web Mercator projection, as also being a cylindrical projection, than the Equal Area projection mentioned before, but with less distortion than Web Mercator and better adjusted to modern wide screen monitors in terms of width/height ratio of the projected plane. |
Sorry, I missed your previous post, but both sound interesting. Since I have very little time for OSM lately and this might be about coordinating efforts, could you contact them and ask about Patterson cylindrical projection and Geofabrik plans? |
This projection is also currently available in Proj4: |
Should correct myself here, this should probably be "less distortion in terms of relative surface area". There is of course also significant distortion in high latitudes with this projection. Just that things like the relative size in terms of surface area of Greenland versus Africa is somewhat better compared to Web Mercator. ... and of course the advantage of Web Mercator remains that, due to the particular properties of the projection, square buildings remain more or less square at whatever latitude you zoom in on the map. That won't be the case with a projection like the Patterson one. So it is a bit a choice between more naturalistic low or high zoom display of the map. |
Closing this issue since the discussion is old and the issue is quite general. We should open new issues to discuss specific problems with the low-zoom rendering. As mentioned above, here are some specific issues related to the general subject, several of which need discussion: #1448 #1770 #1935 #2293 #2925 - closed issues #2172 - Explain or replace usage of Natural Earth boundary data Also see these PRs for what was done or attempted (some were not merged): #2345, #2722, #3074, #3458, #3496, #3701, #3670, #3750, #3930, #3952, etc. And the "low zoom improvements" project list: https://github.com/gravitystorm/openstreetmap-carto/projects/4#card-4723874 |
Most of our work goes to high zoom levels, but it's time to look how we could improve also lower levels. Mid zoom work seems to be pretty advanced now, with PR mostly ready to be merged (#2654). Faded out landuse colors could be used also for low zoom IMO (and new water color can have some impact), but that's just a general idea and there can be other things which need to be taken into account (like performance problems or issues related to using external and pre-rendered data).
What we have now in low zoom levels is better rendering of cities/capitals (z4+) and new road colors (z5+), but for example z0-z3 is still underused. Discussion on improving low zoom levels has been already started here.
Some related resources:
Some issues that are close to the subject:
The text was updated successfully, but these errors were encountered: