Very small administrative boundary borders should start at a later zoom level #3678
Comments
|
I also considered trying to change the tagging standards in Indonesia by introducing admin_level 11 and 12. However, this would still be a problem in some other countries, such as Japan, because admin_level 10 is almost always the highest level, and it can very greatly in size so it should still be rendered at z14 at least - admin_level=10 is a village-sized area in Northern Ireland, for example. Also, there may be a plan to render admin level 11 and 12 in the future, which would reintroduce this issue even if these were not rendered until z15 (which might be too late for some regions). |
|
The admin_level=10 boundaries in Japan are also quite small in the center of towns: https://www.openstreetmap.org/#map=13/34.2266/133.7812 |
|
It seems like z13 and z14 are really bad in Jakarta and I like to get it fixed (Japan does not seem that bad for me, however this could be made better too). However since this problem is pretty limited, what about simply moving l10 down to z15+? Currently we render admin levels from the zoom levels like this:
So the levels are rather hand crafted and it would not break a system. With level 10 rendered on z15+ instead of z13+ we make a small change and it still gives us a room for rendering level 11 and 12 (for example on z16+). |
|
I considered that option, but I do not know if it will work in all
countries where admin_level=10 is used. There may be places where this
level is actually quite large on zoom 13 and 14.
In Japan, while some on the admin_level=2 areas are only the size of a
block, in town or city centers, those in rural areas can take up much of
the screen at z14.
Is there a source where the size diatribution of admin boundaries has been
calculated? I’m not really able to download the global admin_level 10 data
for testing
…On Tue, Feb 12, 2019 at 10:20 AM kocio-pl ***@***.***> wrote:
It seems like z13 and z14 are really bad in Jakarta and I like to get it
fixed (Japan does not seem that bad for me, however this could be made
better too). However since this problem is pretty limited, what about
simply moving l10 down to z15+?
Currently we render admin levels from the zoom levels like this:
admin level initial zoom level
1 -
2 4
3 4
4 4
5 11
6 11
7 12
8 12
9 13
10 13
11 -
12 -
So the levels are rather hand crafted and it would not break a system.
With level 10 rendered on z15+ instead of z13+ we make a small change and
it still gives us a room for rendering level 11 and 12 (for example on
z16+).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshBkc1a0s2RV8f9MqXdKi-DyoKlghks5vMhbggaJpZM4ayJN4>
.
|
|
I made a file recently including all the admin levels inside using this: time osmium tags-filter -o planet-admin.osm.pbf planet-latest.osm.pbf admin_level --overwriteThis file is ~710 MB big, are you interested in getting it? There is also very handy service for analyzing and downloading different admin boundaries: |
|
Filtering only level 10 gives me 166 MB file, which I can also try to share if you want. |
|
Thanks! But I’ll have to wait a week till I’m in a place with free
broadband.
160mb is still bigger than anything I’ve been able to import with docker or
open with JOSM
Is there a way to use Osmium or Osmosis to only extract admin_level=10
borders larger than a certain area? Or can we export a spreadsheet showing
the size or length of each polygon?
That would be even better.
(We should also do this for admin_level 11 and 12 before considering
rendering these.)
…On Tue, Feb 12, 2019 at 10:16 PM kocio-pl ***@***.***> wrote:
I made a file recently including all the admin levels inside using this:
time osmium tags-filter -o planet-admin.osm.pbf planet-latest.osm.pbf admin_level --overwrite
This file is ~710 MB big, are you interested in getting it?
There is also very handy service for analyzing and downloading different
admin boundaries:
https://wambachers-osm.website/boundaries/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshJp6mr3Mlm95zH9FRNEgqMlVUrdTks5vMr7JgaJpZM4ayJN4>
.
|
|
I have opened the question here: https://help.openstreetmap.org/questions/67990/admin_level-data-analysis |
|
Hi, Daniel (kocio-pl) contacted me and asked for help. yes, i can deliver the data/stats you are looking for. it's just a simple SQL query. very easy for me. a snapshot of 10 boundaries: Full list is currently 498k Creating a csv or json, sorting or other things as you like. e.g list of used AL with count per country. please tell me details. walter aka wambacher/germany |
|
Nothing for you? can't believe that. |
|
Could you just export simple CSV file for now as in the example? If @jeisenbe would like something more specific, it can be done later. |
|
BTW: could you post an SQL query too, so it can be used for similar purposes by other people? |
@wambacher - could you post this file as a zip archive on this comment thread? If not, can you send it to me directly? I would very much appreciate this data. I'm sorry that I didn't respond sooner; I was busy traveling. |
Just to confirm - this is a correct tagging, right? |
|
Just to confirm - this is a correct tagging, right?
Yes, based on the current wiki these administrative areas should be
admin_level=10 in Indonesia and Japan at least.
(It would be helpful to change these to 11 or 12 in Indonesia, but it would
be difficult to get community consensus, and in Japan it looks like
admin_level=10 is the most reasonable choice for these areas.)
…On Sat, Feb 23, 2019 at 8:48 PM Mateusz Konieczny ***@***.***> wrote:
In some Asia cities, the admin_level=10 borders enclose single blocks
Just to confirm - this is a correct tagging, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3678 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshFjIxBO5rfrhKEO2iOtP4sz9jscfks5vQUbCgaJpZM4ayJN4>
.
|
|
OK, now it would be useful to check distribution of sizes of admin level 10 areas. Are almost all of them so small? Are there also larger ones? Filtering by area will result with very bad results for places where some areas are just below edge and some just above the edge - with some borders mysteriously missing. |
Zip is easy, but which contents format? csv? json? pg_dump? ... walter |
|
download csv: https://wambachers-osm.website/images/osm/data/boundaries.csv have fun walter |
Thank you very much! Is it including all admin boundaries areas or just ones mapped as relations? |
|
Here is result of my hacky (comments how my code may be improved are welcomed) R processing:
Basic result: we have a power distribution, there are many very small areas but also some larger ones. Either we keep places with small areas unhappy or we will start displaying some large admin 10+ areas too late. Filtering by area will result with very bad results for places where some areas are just below edge and some just above the edge - with some borders mysteriously missing. |
|
And as a sanity check: largest areas with admin level 10 generated with what from spot checks like https://www.openstreetmap.org/relation/3578333#map=6/-30.798/27.927 or https://www.openstreetmap.org/relation/6386457#map=5/-28.246/142.822 looks more or less correct |
|
One thing that worries me generated by has some weird values not matched by OSM data. Either it is result of @wambacher data generated from old version or my processing breaks something. EDIT: @wambacher - do you have any idea what is source of entry with id 3722319 ? Is it just OSM data that was fixed after you imported your database? |
relation only. there are about 10000 Areas (closed linestrings) missing. ~ 2% of total. should not influence the result very much. funny: https://www.openstreetmap.org/way/287224821 and ~ 1000 more in this area. |
my imports are usually starting midnight german time - every day. the timestamp of the current csv is 2019-02-23 00:59:02+01 (friday to saturday night) please check https://www.openstreetmap.org/relation/3722319 IT IS SUCH SMALL, really https://www.openstreetmap.org/relation/142409 is "funny" too. |
..... walter btw: all processing is done with PostGIS using qm= ST_Area(geography(geom)); definitely exact. |
|
I thought about useful statistics and my current plan is to find median area for each admin level and use this data for potential adjusting of initial zoom levels for display of admin boundaries. |
|
find median area for each admin level and use this data for potential
adjusting of initial zoom levels for display of admin boundaries
+1
This is a good way to start. I also think we should also try to look at the
middle 95% of features. The largest 1% or 2% can be too large, but the vast
majority of admin areas should look ok. Similarly, if only 2% of the
smallest areas are unintelligible that is acceptable, but if it is 5% we
need to do something.
|
|
median area of each admin level cleaned output of |
I worry that it may be impossible, but it is worth trying to do that. |
|
And again, area size - this time with unneeded detail removed 1 NA Lets assume that administrative areas of each level on first appearance should have roughly similar area sizes. So if median admin level 2 area would have area of 100 units and median admin level 3 area would have area of 50 units I would expect admin level 3 area to appear one zoom level (after magnification by two times). So looking at this data my expectation are as follows
Currently we render admin levels from the zoom levels like this (data collected by kocio-pl, I fixed appearance of zoom level 2):
Given assumptions made collected data suggests that we could change it to
I am really dubious about just following it and it likely means that assumptions are bad. Though impact of admin level 3 should be minor, according to the table at https://wiki.openstreetmap.org/wiki/Tag%3aboundary=administrative most regions are not using it anyway. Admin level 5 would be a massive change though again most countries are simply not using it. Displaying admin level 6 from z7: my reaction is NO NO NO, this is a terrible idea. Displaying admin level 7 from z10: what about no? Displaying admin level 8 from z13: this is interesting, it is the first one suggesting that we should start rendering earlier, not later. Displaying admin level 9 from z16: this is a pretty big difference, but I happily ignored even stronger hint for admin level 6. Admin level 10 from z17: again strong hint, but I just disregarded as strong one. So what are conclusions? That it turned out that we are not following at all "median sized admin level area of each admin level should have a similar area when it is initially displayed" so this analysis is not as useful as I hoped. But there are hints that admin level 9 and admin level 10 should be rendered later. |
|
OK, results are not as useless as I thought: we have confirmation that median sized admin level 9 or admin level 10 area is much, much smaller than admin level 8 area. It means that it is desirable to change rendering and examples presented at start are not just unusual outliers and that admin level 9 is also affected in the same way. Obviously, it is biased to currently mapped areas and completely ignores changing scale but seems to be good enough to raise minimum zoom level for rendering admin level 9 and admin level 10. |
|
@jeisenbe Are you maybe interested in making PR? If that would be useful for anyone making PR I can find some representative locations (with different area sizes for admin levels z9 and z10) - to avoid testing just on places with extremely small or extremely large areas. |
|
Thanks! What are the units of the areas? Square kilometers?
Joseph
…On Mon, Feb 25, 2019 at 4:23 PM Mateusz Konieczny ***@***.***> wrote:
OK, results are not as useless as I thought: we have confirmation that
median sized admin level 9 or admin level 10 area is much, much smaller
than admin level 8 areas
|
Whoops, I copied in histogram code again. I updated and fixed #3678 (comment) And yes, results should be in square kilometers - so median-sized country mapped in OSM has area of 122 000 square kilometers etc. horrible R code again copied below: |
still lovin SQL data not filtered. |
|
Averages are usually worse statistical tool, but lets see: a2: 0
Given assumptions made collected data suggests that we could change it to
The most helpful information for purposes of this issue is that admin level 10 really should be render later. Admin level 9 apparently here ranks higher and changing it is not so obvious - I guess that there are some very large admin level 9 areas. But I would consider median as the more useful indicator. |
|
Please always make clear if you are dealing with mercator square meters/kilometers here or with real ground units. |
From quick look larger difference seems to be that admin level 10 has far more really small areas, though admin level 10 has also larger tail of quite sizeable ones.
Note that histogram below has one bar cutoff and going out of scale.
Here version without vertical cutoff
|
I admit that I am not sure. I just took @wambacher data. I mostly skipped that (except small disclaimer "it is biased to currently mapped areas and completely ignores changing scale") because quality of this analysis is so low that this difference can be mostly ignored. I mostly wanted to check whatever area present in report is an outlier or not (there was one futile attempt to gather more useful data but it went nowhere). |
|
I've updated the title, since this could be mostly resolved by rendering admin_level=9 at z14 and admin_level=10 at z15 or z16. |
jeisenbe
changed the title
|
Re: log2 used above: "So looking at this data my expectation are as follows: admin level 3 to appear two zoom levels after z2 (as areas are approximately four times larger)..." A tile at z2 is 4 times as much area as z3, not twice as much, so I think the math is wrong The median admin_level=10 boundary is 1 square kilometer square according to the comment above. When drawn as a square, this renders on zoom level 15 at the equator as ~200x200 standard pixels (admin10, z15, 0 deg = ~40k way_pixels). By comparison, the median admin_level=2 (country) is listed at 122,000 square kilometers. At z4 this renders as under 40x40 standard pixels, (admin2, z4, 0deg = ~1600 way_pixels). To get close to 200*200 pixels you have to zoom in to z6, where the average 122k sqkm admin_2 = 150x150 pixels (22k way_pixels), and z7 is 300x300. So the difference in zoom level from admin_level=2 to admin_level=10 is 15 - 6.5 = 8.5 zoom levels, not 17 zoom levels. Actually, all the numbers are off by 2. Average (mean) Median |
|
So we can't compare admin_level=2 or admin_level=4 directly to lower admin levels. The difference in size does not explain the differenc in initial zoom level. This makes sense when we consider that border countries are much more significiant: most are marked and guarded. Also admin_level=4 features are often signed and significant for daily life in many countries. In contrast, the lower levels become less and less important as you go from 5 to 10. So let's compare admin_level=5 to admin_level=8 - these are both mid-level local admin boundaries, so they are more reasonable to compare. (Usually they are types of county, municipality or district depending on the country). We will look at an "mean" (average, which skews large) size area at 60 degrees, versus a "median" (50th percentile size) size area at the equator. As mentioned, it's not possible to pick an initial zoom level which will work for all regions, but I think it's reasonable to at consider both the average and mean area size from the equator to the edge of populated regions around 60 degrees N / S. The mean (average) admin_level=5 area is listed as 11,300 km2 above, which renders as 360x360 standard pixels at 60 degrees and z8, or almost 130,000 way_pixels. We render the central text label of states up to 196,000 way_pixels only, so this suggests that admin_level=5 would need to be rendered at z8 or even z7 if we want to consider showing a central text label with the name, as requested in #4004. If only rendered from z9, an mean-sized area would already be >500,000 way_pixels at 60 degrees, almost the whole screen. Certainly z10 or z11 is too late. The median admin_level=5 area is only 3600 km2, so this renders as 100x100 standard pixels at the equator, or 10,000 way_pixels, at z8. That seems big enough. If rendered at z7 the median area would be only 2500 way_pixels, which seems a little small to be worth showing - too small to show the central text label at any rate. In comparison, the median admin_level=8 area is 16 km2, which renders as just over 100x100 way_pixels at z12 - so the median admin_level=8 area is 4.0 zoom levels smaller than the median admin_level=5 area, as shown in the table above. An average (mean) size admin_level=8 area is 200 km2, which renders as 750x750 pixels, or 562,500 way_pixels, at z12. This is quite large - we certainly should not render admin_level=8 any later than z12. There is a huge difference between the median and the mean: a whole zoom level. Compared to the mean admin_level=5 area, this is 3.0 zoom levels later. OK, now let's compare to admin_level=10: The median admin_level=10 is much smaller: 1 km2, which renders at zoom level 14 at the equator as a square of just over 100x100 standard pixels (10k way_pixels). So based on size alone, admin_level=10 could be rendered first at z14: the median will not be too small at the equator, and the mean will not be too large at 60 degrees, though outliers on either side could be too large or small. This does not consider the relative importance of admin_level=10 features, which might suggest rendering them later. In fact we render admin_level=2 borders very early, because they are one of the only things that is worth showing at z1 to z3, not because they are sufficiently large to be a reasonable size on screen on average. In contrast, admin_level=5 to 8 features are moderately important, and admin_level=9 to 11 are less significant in most countries. |
|
Based on the average and median sizes above, we could make 2 different schemes from admin_level=5 to 10: Average (mean) Median Starting at z9, based on averages: Starting at z8, based on medians: So with a little adjusting, we can set z5 at either z8/z9 or z9/z10, and then admin_level=7 should be rendered at z11, one zoom level sooner than currently, admin_level=8 is fine at z12, admin_level=9 is fine at z13, but admin_level=10 should be moved to z14, based on size alone. I think the relatively low importance of admin_level=9 and =10 also could justify moving them one admin_level later than the others, to z14 and z15. This will certainly help in Indonesia and other tropical countries with small areas. Similarly, the higher importance of z5 justifies rendering it at z8 and admin_level=6 at z10 (2 zoom levels later), even though the size is only 4 times bigger, because in countries which have this admin_level it is rather important, while admin_level=6 varies widely in importance: it’s useful in the UK and most States in the USA, but it’s been said these areas are not significant in Poland and some other European countries. This leads to a suggested pattern: I've already made a branch to test this, along with other cartographic changes for the borders. |
|
This problem was partially addressed by #4100. It may not be possible to solve it entirely, though in my country it could be improved by using z14 for admin_level=9 and z15 for admin_level=10 - after the next release we should see how it looks globally. |
Expected behavior:
Boundary=administrative border lines, like the outlines for protected areas, nature reserves, zoos and theme parks, should not be shown when the area is too small to see clearly.
Actual behavior:
In some Asia cities, the admin_level=10 borders enclose single blocks. This leads to non-intuitive rendering at z13 to z14 in Japan, and as late as z16 in Jakarta - near the equator.
Links and screenshots illustrating the problem:
Jakarta z13
https://www.openstreetmap.org/#map=13/-6.1245/106.9193
z14
z15
z16
z16 Inspector view (from my PR, showing polygons and way_pixels from admin-text layer):
Suggested solution:
The text was updated successfully, but these errors were encountered: