-
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
borders at zoom 4-6 #907
Comments
In general, I'm not sure what we want to show at these low zoom levels. Wouldn't cities, or even rivers, at this zoomlevel be more interesting than region borders? |
We are, but aren't handling overlapping borders correctly, and since pretty much every border overlaps with one border from one side and one border from the other side... |
I agree, though the current look makes me think of a "Europe of regions" which is nice :) You don't really see the country boundaries at all. I believe Frederik had a map where he used a scaled version of higher zoom tiles for the low zooms. Can't find it at the moment... It was quite nice, and useful: it showed what's in OSM, and where the density of data is high. |
Do you mean #809 (comment) ? |
@Klumbumbus Yes, thank you! http://fred.dev.openstreetmap.org/lowzoom/ |
I propose to completely remove borders with admin_level=4 and higher from these zoom levels. Map of Europe is currently ridiculous. I expect that it would not be improvement in USA - but is it possible to render admin_level=4 only in some countries? I think that in this situation country-specific rules may be reasonable. |
Is it really an issue if we fix the overlapping borders? I'd like to do that first |
Yes, this is now slightly better, but still problematic. I copy what I mentioned in #1125: I think one reason of the weak rendering of sub-national borders is the Coastline paradox: the dashes are computed on the length of the border on high zoom, not on the length of the border as you could measure in pixels on low zoom. That means that dashes become invisible on curly borders. Compare the England-Wales border, which nearly looks undashed, with the straight Sahara borders, which look fine. Would using the ST_simplify function be a solution to this problem? |
No, if you simplify the individual boundary ways the end points will stay fixed and the results will be quite arbitrary depending on how exactly the boundary is split into individual ways. If you simplify the assembled polygons the resulting boundaries of touching entities will no more match after simplification, likewise if you linemerge the individual ways. The only proper way to simplify boundaries is by recognizing and maintaining the topology and this is more heavy processing than what is likely feasible on-the-fly. This is not meant to say using ST_simplify it is not possible to improve the results in a limited way compared to the current state, i have not tried. But it will not be good. |
I'm still experimenting, but here is a preview how z4 could look clearer (note that the data is missing city names): This uses edit: added preview for Americas |
Wow, this looks so much better! |
@nebulon42 What about USA? It is quite different. And results are really impressive. |
@matkoniecz I added a screenshot above. |
It is certainly better than now but ultimately i don't think this is the way to go. It works because the rendering is somewhat fuzzy (broad, semitransparent lines) and with a different, clearer styling it probably won't work any more. You can also see the Douglas–Peucker in form of the artefacts it produces. This is especially obvious with maritime boundaries where a smooth radius is often turned into an ugly and irritating polygon. Douglas–Peucker is simply a technique that has no place in cartography when being applied beyond the sub-pixel level (and even there you have to be careful). Essentially this is what i would call hiding the symptoms but not solving the underlying issue. Apart from the technical aspects i think showing subnational borders and labels at z4 does not work for most parts of Earth - yes, it looks all right for Canada, Greenland and Australia and maybe also the US, UK and China but for the rest it mostly just produces noise and line simplification even exacerbates that because it frequently creates the illusion of a well defined geometry which does not match reality though. |
I agree with most what you wrote, but I'm a bit more pragmatic to say it might be good enough until we have something better. I also experimented with topology-aware generalization (e.g. GRASS v.generalize), because I thought it might be worthwhile to replace the Natural Earth dataset with OSM data. For this we would need polygons, but there are a lot of admin boundaries, they get edited often and they often are broken. In the planet extract I obtained a lot of countries didn't make it into the polygon table. So we would need something similar to the coastline processing here. Too complicated for me (yet). Re maritime boundaries: they are really ugly and too prominent. I was not able to get rid of them, because they are part of the polygon after the processing. So something at the rendering database level would have to be done differently. Correct me, if I'm wrong.
I totally agree, but you have to consider the alternatives. I don't want to drop US, Brazilian, Canadian,... states, but would like to get rid of Swiss cantons, Austrian states... Creating a precedent for individual rendering (I have currently no idea how to feasibly do this.) would be dangerous. If done on one occasion then all the requests for different rendering (down to city-specific metro logos) would start flooding in. That's why I decided to keep them. But let's have some more previews: |
My recollection is we are using polygons, because a lot of boundaries have missing
We need to move to ocean shapefiles instead of land shapefiles. |
First: either admin_level 2 only or 2, 3 and 4 - only 2 and 3 is not a good idea since this will likely lead to people retagging things for the renderer.
This is not the only requirement, you also have to simplify topology for good results, i.e. remove exclaves that are too small etc.
Yes, that is the big problem here - typically you already need several tries to get a complete valid admin_level 2 polygon set but for level 4 there is nearly always something broken somewhere. What you essentially need is a process capable of local updates, i.e. where you can update the valid polygon geometries but keep those where the new version is broken.
What you could try to do is render level 3/4 boundaries only within level 2 polygons with a certain minimum size. This is probably not very efficient to do in Postgis but it likely does not matter that much at these zooms.
The french style uses https://github.com/cquest/osmfr-cartocss/blob/master/project.mml#L2074 but only when coastline and boundary are the same way. |
Can you give an example where this happens in the examples? At the parameters used, I don't really notice it here. |
The UK boundary for example. Likely not everyone will recognize this as a problem but keep in mind that the very idea of geometry simplification is to remove high frequency components but by introducing corners to an originally smooth boundary the algorithm actually introduces high frequency noise. |
#1795 is related: admin_level=4 blocks city labels. |
@imagico Thank you for the explanation. I understand the theoretical problem, but it seems to work quite well in practice, at least. The UK boundary in the examples does not look bad to me. But it's certainly an aspect we should keep in mind. |
Well - it certainly depends on how you view the map but in case of maritime boundaries the shape of the boundary reflects the underlying baseline - a single small island can for example not produce a polygon shaped boundary. Or in other words: showing a sharp corner where there is no such thing in reality is contradictory and possibly misleading. |
I think for rendering we are using (multi-)lines derived from (multi-)polygons. I'm not very familiar with the data structures, but I think these always end up in the roads table even when the ring is not closed. In the polygon table only those with closed rings show up. For generalization we would have to start with polygons which afterwards can be converted to lines again. @imagico interesting suggestions, I'll have a look. |
This could cause that some sub-national borders are rendered, but within the same country other sub-national borders are not rendered, right? That would mean, that adjacent small sub-national units are merged together, while the bigger ones are not. I think this would be really confusing for the feedback loop. I would clearly or render all z=3/4 borders or drop them completly (with a strong preference for dropping them completly – much cleaner look, much less “noise”). |
The scenario you describe should not happen, because this would be extremely confusing as you write. The approach proposed by @imagico assures that either all sub-divisions within a country are rendered or none. I have now successfully implemented it: The performance is quite bad and I don't know if it will be feasible. Benchmarking and optimising SQL queries are a bit beyond my abilities. I will therefore now start to prepare a PR so that the discussion can continue at the code level. Regarding testing and review: Is there a need for me to provide a osm.pbf file with global coverage of admin levels 2,3,4 and city/town labels or are you all set up? |
+1 |
That would be great if you could do that. |
I'm sure I can improve the performance, and these low zoom levels are not frequently re-rendered.
I have the full planet, and that's what's needed for looking at performance, but if you already have that extracted, it would be useful to provide that. My concern with this is the feedback loop. On the other hand, most maps are applying something special here, generally special-casing a few countries. |
Yes, I see now. I did not read well the text. Sorry! The example that you have posted looks really well! (Nevertheless I still have small doubts if this is usefull for the feedback loop and if it wouldn’t better to simply drop admin_level=3, 4 at this zoom level – but anyway, your screenshots are a big improvement!) |
Please render borders with admin_level=2 more prominent than borders with admin_level=4 at zoom 4-6 (or admin_level=4 less prominent). Currently it is very confusing, espacially in europe. http://www.openstreetmap.org/#map=4/53.54/22.59
The text was updated successfully, but these errors were encountered: