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

borders at zoom 4-6 #907

Closed
Klumbumbus opened this issue Aug 26, 2014 · 30 comments · Fixed by #1938
Closed

borders at zoom 4-6 #907

Klumbumbus opened this issue Aug 26, 2014 · 30 comments · Fixed by #1938

Comments

@Klumbumbus
Copy link

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

@matthijsmelissen
Copy link
Collaborator

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?

@pnorman
Copy link
Collaborator

pnorman commented Aug 26, 2014

admin_level=2 more prominent than borders with admin_level=4 at zoom 4-6

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

@daganzdaanda
Copy link

We are, but aren't handling overlapping borders correctly

That's good to know.
Borders have been coming up here a few times already, e.g. #622 and #619.
But before changing any rendering it would probably be best to fix that handling of overlapping borders.

@daganzdaanda
Copy link

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?

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.
I guess his approach would not work on the main map, but I like the idea to "show what OSM has".

@Klumbumbus
Copy link
Author

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

Do you mean #809 (comment) ?

@daganzdaanda
Copy link

@matkoniecz
Copy link
Contributor

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.

selection_010

@pnorman
Copy link
Collaborator

pnorman commented Oct 1, 2014

Is it really an issue if we fix the overlapping borders? I'd like to do that first

@matthijsmelissen
Copy link
Collaborator

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?

@imagico
Copy link
Collaborator

imagico commented Dec 18, 2014

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.

@nebulon42
Copy link
Contributor

I'm still experimenting, but here is a preview how z4 could look clearer (note that the data is missing city names):

admin_z4_europe
admin_z4_africa
admin_z4_americas

This uses ST_simplify as without it borders are too messy. A trained eye might spot topology errors, for me the result is quite good. Results got better when adding osm_id < 0 to the query. Seems there is overlap between individual ways and multipolygon ways. Borders of adjacent countries are emphasised since they are rendered twice, once for each country.

edit: added preview for Americas

@matthijsmelissen
Copy link
Collaborator

Wow, this looks so much better!

@matkoniecz
Copy link
Contributor

@nebulon42 What about USA? It is quite different.

And results are really impressive.

@nebulon42
Copy link
Contributor

@matkoniecz I added a screenshot above.

@imagico
Copy link
Collaborator

imagico commented Oct 28, 2015

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.

@nebulon42
Copy link
Contributor

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.

showing subnational borders and labels at z4 does not work for most parts of Earth

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:

without ST_simplify
europe_wo_simplify

without admin_level=4
europe_wo_4
n_america_wo_4

@pnorman
Copy link
Collaborator

pnorman commented Oct 28, 2015

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.

My recollection is we are using polygons, because a lot of boundaries have missing admin_level tagging on ways (#344 (comment)), largely in Poland.

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.

We need to move to ocean shapefiles instead of land shapefiles.

@imagico
Copy link
Collaborator

imagico commented Oct 28, 2015

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.

topology-aware generalization

This is not the only requirement, you also have to simplify topology for good results, i.e. remove exclaves that are too small etc.

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.

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.

I don't want to drop US, Brazilian, Canadian,... states, but would like to get rid of Swiss cantons, Austrian states...

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.

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.

The french style uses maritime=yes. When you do a preprocessing approach you could also clip the boundaries with a coastline buffered by <12 miles. But you also usually don't want to show the level 4 boundaries glued to the coastline - the french style filters these out as well - see

https://github.com/cquest/osmfr-cartocss/blob/master/project.mml#L2074

but only when coastline and boundary are the same way.

@matthijsmelissen
Copy link
Collaborator

This is especially obvious with maritime boundaries where a smooth radius is often turned into an ugly and irritating polygon.

Can you give an example where this happens in the examples? At the parameters used, I don't really notice it here.

@imagico
Copy link
Collaborator

imagico commented Oct 28, 2015

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.

@jojo4u
Copy link

jojo4u commented Oct 28, 2015

#1795 is related: admin_level=4 blocks city labels.

@matthijsmelissen
Copy link
Collaborator

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

@imagico
Copy link
Collaborator

imagico commented Oct 28, 2015

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.

@nebulon42
Copy link
Contributor

My recollection is we are using polygons

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.

@sommerluk
Copy link
Collaborator

What you could try to do is render level 3/4 boundaries
only within level 2 polygons with a certain minimum size.

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

@nebulon42
Copy link
Contributor

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:

states

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?

@mboeringa
Copy link

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

+1

@matthijsmelissen
Copy link
Collaborator

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?

That would be great if you could do that.

@pnorman
Copy link
Collaborator

pnorman commented Oct 30, 2015

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.

I'm sure I can improve the performance, and these low zoom levels are not frequently re-rendered.

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?

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.

@sommerluk
Copy link
Collaborator

The approach proposed by @imagico assures that either all
sub-divisions within a country are rendered or none.

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

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

Successfully merging a pull request may close this issue.

10 participants