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 .

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.

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.

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.

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 https://github.com/gravitystorm/openstreetmap-carto/pull/2654

Some examples of low-zoom landcover:

• MapSurfer: http://korona.geog.uni-heidelberg.de/?zoom=2&lat=51.79403&lon=10.78095&layers=B00000FFFF
• OSM Fr: http://tile.openstreetmap.fr/?zoom=3&lat=46.4&lon=2.3508&layers=B000000FFFFFF
• Omniscale: https://maps.omniscale.com/en/demo#map=4/52.9/8.78/3857/B
• Sputnik: http://maps.sputnik.ru/?lat=27.916766641249065&lng=4.042968750000001&zoom=3

Another thing is that I don't like violet borders on default style (on every zoom), but here's actually separate ticket for this: https://github.com/gravitystorm/openstreetmap-carto/issues/622#issuecomment-316376131

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

After (borders)

After (borders+water)

z4
Before

After (borders)

After (borders+water)

z5
Before

After (borders)

After (borders+water)

z6
Before

After (borders)

After (borders+water)

z7
Before

After (borders)

After (borders+water)

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

z2

z3

z4

z5

z6

z7

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

z5

z6

z7

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?

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:

Poland, z6

I have started discussion about tagging it for a start.

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.

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.

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

It might be because of that:

• "in Poland river is a waterway with basin area >100 km²" (https://pl.wikipedia.org/wiki/Rzeka) - and this one has 183,5 km².
• "the commonly accepted rule for OpenStreetMap is that a stream can be jumped across by an active, able-bodied person" (https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dstream) - and 2-3 m could be too much for this :-)

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

India, z6

Ireland, z7

Iceland, z6

Egypt, z6

Bolivia, z6

Africa, z5

Australia, z5

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

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

Don't forget there is the type=waterway relation as well. This would potentially allow you to get red of side streams by checking for members with role=side_stream:

http://wiki.openstreetmap.org/wiki/Relation:waterway

Looks like distance=* is more appropriate here than length=*.

@kocio-pl mboeringa gave good idea. Perhaps instead displaying water=river at low zooms You could try to show only waterway relations role=main_stream with distance>500 or something similar to that?

Sure, I can test it, but first we need at least some basic tagging. :smile:

We could start rendering glaciers earlier. Currently we're using z6+, but they could be visible even on z0. I would not render them before any other landuse to not make the map dominated by them "just because we have it", so it's a secondary problem which depends on other features, but it's worth to remember.

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

I really think we should complete step 1 before we can discuss specific rendering rules.

It doesn't do any harm to test some use cases, but I think it's equally important to know what is possible at all and I'm currently investigating it, looking for some easy targets.

Low zoom creates many problems related to large amounts of data and lack of tools to easily filter them out. Importing and rendering anything on that scale takes a lot of time, lowzoom tool requires at least basic programming skills to define what tags we want to try, even Overpass shows some limits when searching objects above country level...

However it becomes clear to me that OSM data are mostly not suitable for this kind of generalizations. For example rivers currently lack categorization and most landuses are too small to be visible here (with some notable exceptions like forests and sand deserts). That's why we use some ready data sets like land, water or ice. If we don't like to use external data, making pre-computed low zoom data is necessary.

Yet we lack some data like geographic regions, which would be very useful here. Even when we have such general data, there are some problems with using them (see the ocean labels comment from Andy or Christoph remark about preprocessed water polygons). But there are also others which are probably outside our reach currently, like topographic data.

You are probably aware of these problems much better than me, I just wanted to say why use cases are not what I'm evaluating right now and trying different things for low zoom level design.

@math1985 If you could point me to the place where discussion on step 1 is taking place I will be happy to take part in it.

As for rivers themselves I see no harm in displaying only those that meet specific criteria something along those lines:

z2 distance>3000 stream order=1
z3 distance>1500 stream order=1
z4 distance>1000
z5 distance>750
z6 distance>500 stream order=1
z7 distance>500

@pnorman Some people reject the idea of tagging rivers order, because this can be done "easily" with a software. I believe there will be a lot of corner cases where the human decision would be needed, but I may be wrong too. Do you think we could use our lua transforms to compute the rivers order when importing data?

Some people reject the idea of tagging rivers order, because this can be done "easily" with a software. I believe there will be a lot of corner cases where the human decision would be needed, but I may be wrong too.

+1

Looking at my own home country, the Netherlands, automated assigning of stream order will be highly problematic, as many human dug canals and ditches criss-cross the country and are quite often, maybe falsely, tagged with stream or river.

In addition, even for many "semi-natural" streams or rivers in mountainous terrain, there are often dams and reservoirs intersecting the network, and river or stream lines may not be connected across the reservoir in OSM.

There's a tool for checking waterway relations. It's meant for the QA, but maybe this could help us check if software solution would be enough for waterways classification (and rendering)?

If we are running into this problem (with quite a lot of manpower), every style/data consumer is going to run into the same problem. We should not try to (over)engineer a complicated solution here, leaving all others with the problem to solve too.

Instead, a solution on the data side is needed that allows data consumers to use the data without too much effort. I wouldn't be against implementing a rule in openstreetmap-carto that gives initially undesirable results (too little/many rivers) in some parts of the world - if it forces a change on the data side to make the data more useable.

sent from a phone

On 14. Aug 2017, at 22:08, mboeringa notifications@github.com wrote:

In addition, even for many "semi-natural" streams or rivers in mountainous terrain, there are often dams and reservoirs intersecting the network, and river or stream lines may not be connected across the reservoir in OSM.

also, rivers are usually entering a lake and going out of a lake, but in between there isn't a river, so automatic processing must take care of these cases. If the river changes name in the lake (e.g. different language), it will be almost impossible to get it automatically right.

Besides length and width, the amount of water is an important criterion for "bigness". And as with any other feature, it's relative and depending on the situation/other nearby waterways, which numbers are significant and which aren't.

Some ideas on data extraction:

• Filtering OSM data based on tags for experimental purposes can easily be done with the tags-filter command of the osmium command line tool. This can filter any objects with the specified tags including depending nodes and rel members and will run in a few minutes through the planet file.
• Christoph and I have written special tools for extracting and munging OSM data including OSMCoastline and am offering downloads of that data on openstreetmapdata.com. I am willing to write more tools like that to extract OSM data and put it in some form for quick and easy rendering in osm-carto. If you can tell me what you need, I'd be happy to think about how to get the data efficiently into some usable format.

I played around a bit with an idea regarding waterways for low zoom. From all ways tagged waterway=river I filtered out all that are inside a water or waterway=riverbank area. This reduces the number of ways from about 1 million to a third of that. The idea is that rivers mapped as an area are probably bigger and thus more interesting for low-zoom maps. This is, of course, not perfect, but it looks not unreasonable as a starting point. I think we could probably come up with something here that works well enough that it can be used where better data is not available. We probably still want some kind of improved tagging, but we could use some heuristic like this to start out and then tell the mappers: If you want better maps, use these extra tags to improve upon the heuristic.

Blue ways are inside river areas, grey ways aren't.

Thanks, I will try to get familiar with osmium then! Looks like an easy way to select custom tags for low zoom features.

I'm not sure which extra tools would be needed, but I guess making some computation-expensive generalizations offline (like coastline data) is a way to go. There should be probably some tools to look for possible vandalism as an extra safety check - such big objects should not change too much probably, so we could get some alert and review them before letting people use it.

Regarding rivers - here's a fresh alternative categorization proposal from Zverik:
https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classification

Your analysis looks like a high-frequency noise filter, but you're right that we still need something more general. I have also spotted that if a river have sections not covered with water area, they are filtered out, which makes the gaps in river rendering. We could go along @math1985 rule (tolerate such problems on the map to make people fix them). The same probably with rivers going through lakes, but I'm still not sure how to deal with it.

There's also additional question: is it possible to turn your algorithm into lua transform, so it would be directly usable for this style?

@kocio-pl This was only a few minutes of experimentation in SQL. I don't believe this is something we can do in lua transform, neither is it something we want to do online in SQL, but it is easy to do with an SQL script that runs, say, once every night aggregating all the data. I think it is important that we don't restrict ourselves with what can be done in lua/SQL queries in Mapnik, because this will always be too limited. We have the precedence of the coastlines, similar approaches would open up huge possibilities.

There should be probably some tools to look for possible vandalism as an extra safety check - such big objects should not change too much probably, so we could get some alert and review them before letting people use it.

We are currently doing that with coastline data. If there are larger changes the pipeline stops and new coastline files aren't available. On the one hand this has worked well protecting the map from bad data, on the other hand it has stopped coastline updates for a long time because there are basically only two people who can get this unstuck who don't always have the time to look into it...

I'm not sure how complicated is this, but I could help patrolling these changes. Maybe also a message on a Talk list could help to find volunteers?

If we're about to use these data, they don't have to be very current (for example z0-z12 tiles on OSM servers are re-rendered every new release only, IIRC), but the workflow shouldn't get stuck because of lack of people.

@kocio-pl Currently this is not possible, because you'd need an account on my server and know how a lot of scripts work etc. This really needs some careful thought and some kind of web interface or so. Unfortunately this isn't very high on my todo list... And it really doesn't belong into this issue.

My warning applies to all such services if we think about starting to rely on them. Ideally they should be well enough documented and it should be possible to "fork" and deploy them elsewhere if needed.

@pnorman Some people reject the idea of tagging rivers order, because this can be done "easily" with a software.

Yes, but they're wrong.

I believe there will be a lot of corner cases where the human decision would be needed, but I may be wrong too. Do you think we could use our lua transforms to compute the rivers order when importing data?

No - lua transforms operate on the objects tags, which don't tell us what we want.

It's quite fast and easy to use tool:

time ./osmium tags-filter -o europe-rivers.osm.pbf europe-latest.osm.pbf wr/waterway=river

took about 40 minutes.

I have a problem however - when I added tags->'order:classic' as order to project.mml and try to use [order = "1"] filter I only get the rivers of order 1 drawn as ways, but no these with such relation. It also looks like [order < 2] doesn't work and I'd like to use construction like [distance > 100].

The code comparison is here.

Looks like the numbers should be treated like this:

https://github.com/gravitystorm/openstreetmap-carto/blob/89ef164b36f89d35b45aa238eea70f0d3650986d/project.mml#L1487

but there's still problem with values in relation which are not selected.

While it would be good to have some general vision of low zoom, I feel that there's a general rule we should follow: no object should appear in part when zooming in.

Example - my primary screen has 12.5" and Grand Erg Oriental appears at z8, when I can see only half of it; most of it would be visible on z7 and the whole area would fit on z6. Parc culturel du Tassili N'Ajjer appears first on z7 and I can see the whole object at least (but the name is visible from z8).

If so it would be more correct to have screen resolution not the screen size as the rule of thumb. For example one can have laptop of the same resolution with screen of 1366x768 or 1920x1080.

Thanks, you're right! I use both internal (1366x768) and external (1920x1080) screen. For external Erg would fit on the screen on z7, so still z8 is too late. Of course Parc is visible fully as it is now (from z7).

The important thing is that it's a device-related problem. We are not able to follow this rule for every kind of screen, but we may use standard resolution that we think should work this way.

sent from a phone

On 19. Sep 2017, at 17:41, kocio-pl notifications@github.com wrote:

Thanks, you're right! I use both internal (1366x768) and external (1920x1080) screen. For external Erg would fit on the screen on z7, so still z8 is too late

other than resolution, there can also apply scaling, especially with high resolution displays and small screens there's scaling involved. A 1080p image on a pc screen is a different image than the same pixels on a phone, because the phone typically renders the image as it would appear on a smaller screen but with higher resolution

I think we can render names of the biggest objects on Earth (like continents, oceans, seas, mountain ranges or deserts) using set of 6 official UN languages (name:ar / name:en / name:es / name:fr / name:ru / name:zh) as the closest equivalent of int_name.

@pnorman What's the reason for your disagreement?

@math1985 Do you have some use cases for a start? I go the other route (checking what's possible and what is still not ready) and it would be interesting to meet in the middle.

@kocio-pl I will come back to that.

6 languages is simply too much too render.

@pnorman What's the reason for your disagreement?

I think it would be terrible cartography, and way too much text.

There's interesting fresh article about low zoom rendering (but it also includes mid-zoom up to z13) by @imagico:

http://blog.imagico.de/on-basic-small-scale-landcover-rendering/

It's even more interesting because it contains landcover color generalization scheme (this kind of explanation was missing during discussion about mid-zoom changes):

http://blog.imagico.de/wp-content/uploads/2017/09/landcover-colors.png

...and a link to a demo map with some layers to switch on and off:

http://maps.imagico.de/#map=2/48.458/23.555&lang=en&r=osmlz&ui=2

What do you think about it? I have to reread it at least one more time probably, but that's a good starting point for further analysis.

Regarding z9 landcover "ugliness":

http://tools.geofabrik.de/mc/#9/53.5208/10.0597&num=4&mt0=geofabrik&mt1=mapnik&mt2=google-map&mt3=mapnik-humanitarian

Well, for me Geofabrik is a bit better than Humanitarian, but both are ugly. Current osm-carto is much more readable and Google is nice too, but it's just very limited.

I know the blog entry might be as emotional and subjective as it gets, but in this case the "proper contrast of the background" would be much better term.

http://maps.imagico.de/#map=2/48.458/23.555&lang=en&r=osmlz&ui=2

I very like effect of a combination of these layers:

• landcover fallback (no empty gaps on the map)
• OSM-carto style landcover (it shows fields)
• OSM-carto style water areas
• alternative-colors style lines and labels (#622)

Grey country borders could be a little bit darker, but generally it works and looks fine.

Something else I have been thinking about: when looking up something on the map, you're always looking up something with respect to something else. For example, you want to know where a city is located with respect to the country borders, or where a supermarket is located with respect to the city's street pattern, or which roads you can use with respect to cities (that you already know).

Let's call what you want to look up the map subject, and with respect you want to know it the map context. A famous example of this is the Thames in the London tube map: the metro lines are the map subject, and the Thames is the map context.

I think best design is when the map subject attracts more attention than the map context. For example, when you're making a map for people to find roads between cities they already know, the roads should attract more attention than these cities. On the other hand, if you're making a map for people that already know the highway layout, but that want to know which cities are located along the highways, the cities should attract more attention than the roads.

Makes sense? Is anybody familiar with related literature on this?

CC @imagico @pnorman

See also #2925.

An overpass query returning a nice small fragment of test data for lowzoom:

https://overpass-api.de/api/interpreter?data=%5Btimeout%3A250%5D%3B%0D%0A%28%0D%0A%20%20relation%5B%22boundary%22%3D%22administrative%22%5D%5B%22admin_level%22%3D%222%22%5D%2850%2C3%2C53%2C6%29%3B%0D%0A%20%20relation%5B%22boundary%22%3D%22administrative%22%5D%5B%22admin_level%22%3D%224%22%5D%2850%2C3%2C53%2C6%29%3B%0D%0A%20%20way%5B%22highway%22%3D%22motorway%22%5D%2850%2C3%2C53%2C6%29%3B%0D%0A%20%20way%5B%22highway%22%3D%22trunk%22%5D%2850%2C3%2C53%2C6%29%3B%0D%0A%20%20way%5B%22place%22%3D%22city%22%5D%2850%2C3%2C53%2C6%29%3B%0D%0A%29%3B%0D%0A%28._%3B%3E%29%3B%0D%0Aout%20meta%3B

@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

Sneak preview of my work on the low zoom levels:

Before/after:

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!

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:

Gray admin boundaries:

Dark green admin boundaries:

I'm not sure, but it's possible that https://github.com/gravitystorm/openstreetmap-carto/issues/2688#issuecomment-325833298 (problem with relations tags not being available) can be fixed by https://github.com/openstreetmap/osm2pgsql/issues/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 notifications@github.com 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 notifications@github.com 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)

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.

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

@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)"

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.

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:

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

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.

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