-
Notifications
You must be signed in to change notification settings - Fork 831
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
Adding natural and semi natural areas to use cases #2946
Conversation
Are there any canals that should be displayed at z5, z6? I think that either there would be invisible or would be confused with minor seas at this scale. |
see #2931 for my doubts |
http://maps.imagico.de/#map=3/49.457/-3.535&lang=en&r=osmlz&o=1aa&ui=2 is proof that low zoom landcover may make sense, but I am not sure is it desirable to go in this direction as it would rely heavily on using nonOSM data in imaginable future |
I don't know, it's a general statement. It's a problem with low zoom - you have to find examples (see #2742). For relief - I believe for low and medium zooms it's less of a problem than on high zooms: it's still external data, but the errors in placement should not be more than dozen of meters (and if it is, I would rather suspect our data, as this image is more coherent than a big collection of independent edits). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mentioning relief as desirable without making clear that it requires relief data that are open, high-quality, preprocessed to remove mismatches with OSM data or with quality better than OSM data (and yes, I am aware that this description may be shortened to "nonexistent magical relief data")
Relief disappearing on zooming in seems for me to be a very confusing thing. |
My take is that we should show only our data for landcover:
|
Unfortunately without fallback data is going to be quite noisy - see http://www.openstreetmap.org/#map=4/51.26/11.69&layers=H |
I don't think so - but it should be tested, of course, and it takes a lot of time to render big areas. That's why I didn't mention it yet, though I have some general ideas. I think that noise is a product of too many details (high frequency elements) and too big contrast (high amplitude). Contrast is now much less thanks to the midzoom changes on osm-carto and on low zoom there are only few types, which can be even more generalized (as proposed by @imagico - see #2688 (comment)). Example of deploying this idea is French style - let's look at z7 in SF area: Contrast is a bit too big, but it's better than HOT, which is designed to be high contrast for printing purposes, AFAIK (we have less intensive colors already). There are only woods, grass, farmlands and sands visible, I guess (+natural parks). There can be also ice in different places and maybe few more types, but that's it for a low zoom. We don't even have to make generalizations most of the time, so I want to make them only when really needed (I feel that Christoph tried to use them to make map beautiful). The rest is just a lot of testing for the whole planet... |
As of your concerns and changes request:
|
This is more like what we could show on z7: http://maps.imagico.de/#map=7/38.355/-121.055&lang=en&r=osmlz&o=55&ui=2 but remember that "OSM-Carto style landcover" are in fact not the colors we use on midzoom osm-carto - they are not faded, so the contrast is also too big. |
Would it be possible to be more specific? I suppose you're aiming for something like in @matkoniecz's image. This map seems largely a biome/climate map. It doesn't say anything about human landuse, for example. About the minor water areas on z5/6/7: I slowly start changing my mind about them a bit. Some examples: We previously asked ourselves if we can render these minor water areas here, and the answer to that is sure we can. But should we? I actually doubt that these lakes is the information the user is looking for, and it even distracts a bit from the main message. |
The lower zoom level, the more areas are just natural, I think there are not too many human landuses really visible on low zoom. Which ones could it be, other than semi natural (like farmlands), military areas and natural reserves? Countries (nominally areas, but visible as border lines) and biggest cities (nodes) add some human related informations on top of that, so it's balanced enough for me.
I have no strong opinion on that. I just think that it's zoom level independent problem in general - small dots can always be a problem. What filter would you like to use here? |
Any comments on this? |
I'm still trying to understand the usecase better. Can you try to give a very concrete example of something that a user could read from the map on the relevant zoom levels? For example in @imagico's example one could read something like 'the north of Africa is a dry area' or something like that. |
On the other hand, in Europe I can see a lot of different colors of green, but there is not really information I can read out of that. That's something I'd like to avoid. |
For me it's so basic that it's hard for me to give examples. "This part of the continent is full of forests" or "it is basically desert land" or "there are big mountains" or "there is the ice area" or "this is a big steppe belt" are important geographical informations for me. Forest area is very different than steppe, so even shades of green can say something valuable. Map made by @imagico on low scale tries to cover everything with non-OSM data just to show how it would look like in the future, but that's basically the same idea. |
What information would you get out of @imagico's map for Europe? |
That it's mostly covered with forests. There are also for example sand patches in North Africa which shows that it's different: http://maps.imagico.de/#map=4/49.781/16.348&lang=en&r=osmlz&o=55&ui=2 |
I believe now the problem is you are using narrow definition of use case. In reality you're talking about limited practical (travel) use, for example "where could I drive". But when you look at global scale, there's nothing too practical in this sense, since this is not a human scale. Yet there are informations which are available here. For example "Looking up country location" - so the country name would be enough, knowing borders is not needed probably, but it's good to have them too. If we were strictly about journey planning, we also don't need railway lines - only the stations. But it's good to see them too. So let's not think about just journeys. Many of our viewers may not go to any journey if they are from less developed sites, yet why not show them the world as it is? That's also diversity we should care about. Knowing where the ice is or where are the forest, sands, rivers and lakes is also a knowledge about Earth geography, even if you're not traveling half of the world in general, so you don't need them to plan a journey. The names of big geographical entities would be great also, but there are language related problems which are outside the scope of use cases. |
That’s definitely how I intend it too! |
So what do you think about this PR? I believe @matkoniecz is against both rendering low zoom (semi-)natural features and especially relief. You wanted me to be more specific and I'm not able to be more specific even if I try. I still think this PR is good enough and we don't need to implement all the use cases (this is just a designing phase, implementation is another story). I see no clear decision at this moment. |
@kocio-pl I guess we can merge this. However, could you add a section 'Use cases that we currently don't render' (the reverse of ' Some features that we currently render for which we do not (yet) have a use case')? |
On the other hand, we could also treat the list as a way to document the use cases for the features that we do render, rather than turning it into a wish list. |
I'm still not sure where can we go with usecases, so I prefer to leave it as it is now. Maybe it will be more clear in the future. |
Since it's pretty general and big subject, I prefer to make a PR instead of direct updating file.