Skip to content
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

Closed
kocio-pl opened this issue Jul 12, 2017 · 82 comments
Closed

Improve low zoom levels #2688

kocio-pl opened this issue Jul 12, 2017 · 82 comments

Comments

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jul 12, 2017

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:

@kocio-pl
Copy link
Collaborator Author

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?

@woodpeck
Copy link
Contributor

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.

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Jul 12, 2017

I am fine with a new issue, 2 years later.

We can clearly learn a lot from http://tile.openstreetmap.fr .

@imagico
Copy link
Collaborator

imagico commented Jul 12, 2017

any sweat invested in dressing up the map with nicer styling cannot hide the fact that it is a bad map (on that scale).

Well - that is not really a statement you can argue but

  • the logical conclusion is not to offer the low zoom levels at all and remove support for them from this style. This however is functionally problematic since map usability would suffer - you would end up doing a lot of panning when you move between different parts of the world without the option to zoom out to z1-3.
  • I am also a big fan of do something right or don't do it at all - so if we don't drop support for the lowest zoom levels we should make a serious attempt at decently rendering them.
  • also practically if you look at the map at z3 for someone who wants to zoom into a certain part of Russia or the Antarctic (and the main purpose of z3 is being a starting point to zoom in) proper, readable rendering of additional details without too much clutter would be extremely helpful.

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.

@pnorman
Copy link
Collaborator

pnorman commented Jul 12, 2017

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.

@kocio-pl
Copy link
Collaborator Author

Depending on just how wide you want to throw open this issue

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.

@Tomasz-W
Copy link

Tomasz-W commented Jul 21, 2017

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)

@kocio-pl
Copy link
Collaborator Author

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
Before
p4oawfaj
After (borders)
j0fgqqdu
After (borders+water)
udujme6h

z4
Before
ubx5_svd
After (borders)
7uehxsqz
After (borders+water)
negfihhr

z5
Before
prxxi8me
After (borders)
wlfskbg1
After (borders+water)
fwblypuy

z6
Before
msvt1bah
After (borders)
h1rzwps3
After (borders+water)
fwysebco

z7
Before
o4pqa50c
After (borders)
u9kg ob
After (borders+water)
tieuwwyw pngcrush

@wmyrda
Copy link

wmyrda commented Jul 22, 2017

This looks great! Quite likely due not adding any new features, but only making color changes should also be compatible with carto 3.x

@kocio-pl
Copy link
Collaborator Author

I wait for extended lowzoom tool to make low zoom tests with (at least) tree areas and midzoom rendered landuses if possible.

@kocio-pl
Copy link
Collaborator Author

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):
z1
zztiaan5
z2
_swfw466
z3
x 4e0jv5
z4
mg6 oqvm
z5
sg7gqzd8
z6
govryoex
z7
_mwr3lie

@kocio-pl
Copy link
Collaborator Author

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):
z4
ngyvkirh
z5
2fdla85p
z6
qxwap_ 4
z7
tkki20jl

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Jul 24, 2017

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:

  1. Decide on use cases for these zoom levels (let's say z5, z6 and z7 for now)
  2. Decide what features are important to render for these use cases
  3. See what kind of rendering rules we can create to highlight these features

Some use cases I can think of:

  • Looking up places. If I want to see my home city, I usually prefer zooming in from z5 rather than using the search function.
  • Long distance trip planning. I'm a bit doubtful that people do this on z5, but on z6 trip planning by car might already make sense. Zoom level z7 should definitely be useful for trip planning by car.
  • Looking up possible destinations for day trips. Mainly from z7 or even z8 I think.
  • Looking up a province, city or perhaps other toponym to get a global idea where it is located (for example heard on the news)

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?

@imagico
Copy link
Collaborator

imagico commented Jul 24, 2017

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.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Aug 6, 2017

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:

Poland, z6
jhpdh1hc

I have started discussion about tagging it for a start.

@sommerluk
Copy link
Collaborator

rendering (important) rivers, but currently we lack classification tagging system

The key “CEMT” seems to be europe-centric.

But the key “width” seems to be used world-wide and is quite easy to verify.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Aug 6, 2017

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.

@mboeringa
Copy link

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:

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"...

afbeelding

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Aug 6, 2017

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.

@pnorman
Copy link
Collaborator

pnorman commented Aug 7, 2017

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.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Aug 7, 2017

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):

India, z6
tvop_pdz

Ireland, z7
btgpdyfy

Iceland, z6
xzaoay9z

Egypt, z6
kb8fgnul

Bolivia, z6
tmudgfo6

Africa, z5
tbrkjr79

Australia, z5
5moyba2p

@pnorman
Copy link
Collaborator

pnorman commented Aug 8, 2017

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.

@wmyrda
Copy link

wmyrda commented Aug 8, 2017

@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.
Besides I think that kocio can prepare code that renders only rivers having all those attributes if required.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Aug 8, 2017

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:

https://en.wikipedia.org/wiki/List_of_rivers_by_length

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Feb 10, 2018

@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?

@gravitystorm
Copy link
Owner

@matthijsmelissen They're just Natural Earth boundaries - 10m admin 0 countries

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Feb 10, 2018

Sneak preview of my work on the low zoom levels:

Before/after:

screen shot 2018-02-10 at 23 32 15 screen shot 2018-02-10 at 23 29 51

@kocio-pl
Copy link
Collaborator Author

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.

@Tomasz-W
Copy link

@matthijsmelissen Country labels are too solid for me, but I very like the idea of grey borders!

@matthijsmelissen
Copy link
Collaborator

After some further investigation, I'm convinced we need to get rid of purple as a color for borders, at least on low zooms. Purple really does not work together with the motorway color.

Purple admin boundaries:
screen shot 2018-02-15 at 23 53 02

Gray admin boundaries:
screen shot 2018-02-15 at 23 57 36

Dark green admin boundaries:
screen shot 2018-02-15 at 23 54 04

@kocio-pl
Copy link
Collaborator Author

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.

@kocio-pl
Copy link
Collaborator Author

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):

screenshot-2018-4-28 cesiumjs - geospatial 3d mapping and virtual globe platform

@dieterdreist
Copy link

dieterdreist commented Apr 28, 2018 via email

@kocio-pl
Copy link
Collaborator Author

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.).

@dieterdreist
Copy link

dieterdreist commented Apr 28, 2018 via email

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Apr 10, 2019

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)

Screenshot_2019-04-10 World rivers map

z3 - Brahmaputra (lacking Ganges)

Screenshot_2019-04-10 World rivers map(1)

z4 - Araguaia (lacking Tocantins)

Screenshot_2019-04-10 World rivers map(2)

@mboeringa
Copy link

mboeringa commented Apr 10, 2019

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

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.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Apr 10, 2019

"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.

@mboeringa
Copy link

mboeringa commented Apr 12, 2019

@kocio-pl

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
Erstprüfer: Prof. Dr. rer. nat. Detlef Günther-Diringer (Hochschule Karlsruhe) | Zweitprüfer: Dipl. Wi.-Ing. Frederik Ramm (Geofabrik GmbH)
Die Web-Mercator-Verzerrung – Prototyp einer optimierten Weltkartendarstellung für Webkartendienste (am Beispiel von OpenStreetMap)"

@mboeringa
Copy link

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.

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.

@kocio-pl
Copy link
Collaborator Author

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?

@kocio-pl
Copy link
Collaborator Author

This projection is also currently available in Proj4:

https://proj4.org/operations/projections/patterson.html

@mboeringa
Copy link

mboeringa commented Apr 30, 2019

but with less distortion than Web Mercator

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.

@jeisenbe
Copy link
Collaborator

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
#2278 - Show names of seas and oceans
#2507 - Low zoom waterbody rendering and move to water polygons
#3034 - Inconsistent priority of city/country names at z5/6
#3489 - Change admin boundary color
#3504 - Virtual borders on antimeridian
#3634 - Limit natural area labels to z4+
#3720 - Using external data to adjust rendering
#3862 - Too early and inconsistent zoom level for natural area patterns
#3935 - Roads are too prominent at mid and low zoom levels
#3936 - Landcover and landuse cannot be distinguished at mid and low-zoom levels
#3980 - Inconsistent initial zoom level for built-up areas and different landcover types
#3981 - Landcover not visible at z5 in finely-mapped areas
#4067 - Inconsistent way_area filters for water and landcover

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests