Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[patch] osmarender mapstyle administrative borders admin_level #1332

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 14 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: stephankn
[Submitted to the original trac issue database at 6.20pm, Thursday, 13th November 2008]

Country borders are not rendered, only those containing wrong tag border_type state. The enclosed patch replaces this by a rendering of administrative borders according to their admin_level.

admin_levels is explained in the wiki and widely used:
http://wiki.openstreetmap.org/index.php/Key:boundary

The picture shows the rendering style of the levels 1 to 10.

@openstreetmap-trac
Copy link
Author

Author: spaetz
[Added to the original trac issue at 7.50am, Friday, 14th November 2008]

  • I agree that admin_level should be rendered if it isn't already. However saying that border_type is a "wrong" tag is not correct either. Currently Map Features says on its front page: "boundary administrative area... Use therefore border_type=*" Saying that it is wrong when it's on the front page is a bit misleading.

  • Looking at the popularity of tags, according to Non-US tagwatch we have:

border_type: city (26967), county (1974), nation (1147), country (539), suburb (461), municipality (442), state (341), district (315), province (284), region (270)

admin_level: 8 (69335), 6 (6046), 2 (3332), 4 (3121), 10 (1389), 9 (383), 7 (207), 5 (129), 3 (25), 1 (7)

So admin_level 1+2 are used 3,300 times while border_type nation+country are used about 1,700 times. Less often but frequent enough that I wouldn't stop caring about it.

As a consequence, I wouldn't support replacing border_type with admin_level but rather render both. I'd support a patch that implements that.

Also, map-features z6-11 is currently not used at all. To get this on the lowzoom map you would need to add the borders to the low zoom caption layer which is used as an overlay to the stitched z12 captionless tiles. Actually, caption-z6.xml contains so at z6 we create nation borders based on admin_level and not border_type already.

@openstreetmap-trac
Copy link
Author

Author: amm
[Added to the original trac issue at 8.34pm, Tuesday, 25th November 2008]

At the moment, the lowzoom also looks rather cluttered, as it renderes all boundary=administrative in the captionless tiles, i.e. also the county and city boundaries. (e.g. http://informationfreeway.org/?lat=45.21680273782514&lon=9.083762031818578&zoom=10&layers=B0000F000F)

I have attached a patch, that removes the else filter on the boundary in captionless and replaces it with a rule for admin_level=2 (country) and admin_level=4 (state).

@openstreetmap-trac
Copy link
Author

Author: chriscf
[Added to the original trac issue at 4.24pm, Tuesday, 2nd December 2008]

Could someone generate a clean patch against current source please?

@openstreetmap-trac
Copy link
Author

Author: amm
[Added to the original trac issue at 4.18pm, Thursday, 1st January 2009]

Thanks for the patch. It definitely looks much better than the current stylesheets! So I wouldn't mind this version being deployed. However I think admin-level 2 and 4 could still be improved a bit. I think admin-level=4 should probably be rendered on low-zoom tiles and thus in captionless. These reflect borders such as the german Bundesland or the american states, which can be of the size of small countries and shouldn't overload low-zoom. Also I think admin-level 2 could be a little bit more prominent, again especially in low-zoom. So perhaps you could use the styles of admin-level=1 for admin-level=2 and that of admin-level=2 for admin-level=4. Admin-level=1 logically doesn't really fit into the hierarchy anyway, so not having admin-level=1 being more prominent than admin-level=2 probably shouldn't matter. The rest looks fine and will hopefully help reduce the flood of red on the current t@h renderings, coming from all the wonderful town and city borders that osm has by now.

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 5.43pm, Thursday, 1st January 2009]

Patch is committed as r12779. z12 and lowlevel might need some improvements but I currently lack the time and motivation for fine tuning. Patches are welcome though.

@openstreetmap-trac
Copy link
Author

Author: ben.laenen[at]gmail.com
[Added to the original trac issue at 5.09pm, Thursday, 8th January 2009]

Please revisit this patch and for now revert in T@H until it's improved. z12 should at least show all boundaries up to admin_level 8. z13 and higher should go to 10.

Now you get for example z14 which is just showing province boundaries (admin_level=6) while the municipalities (admin_level=8) are already filling more than your average computer screen.

Also, the boundaries don't seem to get rendered like the attached image above at all.

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 7.49am, Friday, 9th January 2009]

A couple of people already congratulated me to the change but the map isn't cluttered anymore... And yes the attached image above is a suggestion by somebody else, not a test rendering.

@openstreetmap-trac
Copy link
Author

Author: ben.laenen[at]gmail.com
[Added to the original trac issue at 11.42am, Friday, 9th January 2009]

Yeah, no clutter, but you've basically made the boundaries in OSM useless now since you can only see them when you're zoomed in too much. Boundaries provide structure to the map and are therefore very important things. At least consider going to at least admin level 6 at z12 if you insist not having municipalities at that zoom level, but current levels are just not right IMHO. You should be able to see the entire entity (province, municipality, district or whatever) on one screen at some zoom level, which isn't the by far the case now.

By the way, who decides whether one or the other is better?

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 12.04pm, Friday, 9th January 2009]

Could someone generate stats for the whole planet listing the area covered by objects of the different admin_levels? Average, median and standard deviantion, possibly quantiles would be really nice.

If we know admin_level 8 has a average size of 7.34 z12 tiles, with 25% smaller than 3.1415 z12 tiles we would know that admin_level 8 really has to be rendered in zoom level 12.

If on the other hande the average area is 0.005 z12 tiles for admin_level 8 we can be really sure that admin_level 8 does not belong in the z12 stylesheet.

In the time till somebody is able to provides stats like that I'll add the style description for all admin_levels to all stylesheets, as soon as I find the time. That will allow for easy changes in the selection of admin_levels to be rendered at a given zoom level in the future.

@openstreetmap-trac
Copy link
Author

Author: ben.laenen[at]gmail.com
[Added to the original trac issue at 2.50pm, Sunday, 11th January 2009]

One more note. The gaps between the red lines are way too wide. If you have a border that makes lots of curves the course of that border isn't very clear anymore, since you'll see a bunch of red lines in all directions with no real hint of how the border runs exactly. This was much better in the old style, and also in the image attached above.

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 7.04pm, Tuesday, 13th January 2009]

The stats are available now at http://wiki.openstreetmap.org/wiki/Key:boundary/statistics as soon as I find the time I'll use those to decide which admin_levels to render at which zoom levels.

@openstreetmap-trac
Copy link
Author

Author: ivom
[Added to the original trac issue at 7.47pm, Thursday, 15th January 2009]

Reformatting the borderlines has certainly aroused some people after the tile-cache is getting filled with new tiles :) The correct set of stylesheets is something which IMHO has to be settled, partly by trial and error. Thanks for at least changing and proposing something new, better, but maybe not perfect change.

I second Ben's comments that borders are a very important feature on maps and that they should render appropriatly. That, is of course, not an easy task.

I also would like to see admin_level=8 and lower rendered at z12 and higher.

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 7.46am, Friday, 16th January 2009]

Yes they are important. But have a look at the stats at http://wiki.openstreetmap.org/wiki/Key:boundary/statistics to see why it is not going to happen. To make me change the rendering decision you will need hard numbers AND good arguments. Otherwise it's just not going to happen. So stop reopening this bug until you have more than "I like my eggs easy over".

@openstreetmap-trac
Copy link
Author

Author: ben.laenen[at]gmail.com
[Added to the original trac issue at 12.08pm, Friday, 16th January 2009]

Well, I don't see anywhere on that page why it's not going to happen. It just tells the average size of enclosed boundaries, but I have no idea how squared arc degrees translates to the number of tiles.

And what would you want as proof anyway? Isn't this just for the most part personal preference as well? And I can't see why your preference should be the only valid one here.

All I know is that for Belgium and a browser window of 4 by 3 tiles, an area enclosed with admin_level 4 (region) is in its whole visible from zoom level 9 (although it barely fits), an admin_level 6 (province) from z10 and a medium sized municipality (admin_level 8) from z14. IMHO to be usable you need to see the boundaries from at least one zoom level more, so that makes:

  • admin_level 4 = z8 (now it's only visible from z13)[[BR]]
  • admin_level 6 = z9 (now z14)[[BR]]
  • admin_level 8 = z13 (now z15)

to have a usable map in Belgium. I consider this more than enough proof that the current situation is pretty bad.

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

No branches or pull requests

1 participant