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

Reduce prominence of admin_level=9 and 10 boundary=administrative borders, or remove them #4016

Closed
jeisenbe opened this issue Jan 30, 2020 · 20 comments · Fixed by #4100
Closed

Comments

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 30, 2020

Expected behavior

  • It should be possible to distinguish each of the types of administrative boundary which we render,
  • Administrative boundaries should not be easily confused with other linear features like railways, power lines, tracks, paths etc.
  • The boundaries of larger areas (admin_level=2 - national and admin_level=4 - provincial) are much more significant than the high-number boundaries used for small neighborhoods or sub-districts, so these should be clearly visible and distinct
  • Minor boundaries which are not significant on-the-ground should not be rendered

Actual behavior

Recommended improvement

I have previously (#3716) worked on improving the boundaries (as have others in #3489, #3526, #3553 and #3666), but found it too difficult to make unique patterns of dots and dashes for each level, while also solving #3971 and preventing similar confusion between borders, tracks and paths. Reducing the number of different levels shown would make this much more feasible.

(In contrast to admin_level=9 and 10, which are almost always sub-district, neighborhood or village level, admin_level=8 is often a large municipality in many countries, so it is reasonable to show admin_level=8 on a general-purpose map such as this.)

Links and screenshots illustrating the problem

admin_level=9 / 10 vs railway=disused at z17
https://www.openstreetmap.org/#map=17/52.37805/16.90282
z17-railway-disused-border-9-10-17:52 37805:16 90282

Jakarta z13
https://www.openstreetmap.org/#map=13/-6.1245/106.9193
z13-jakarta-busy-borders

z15 - many admin_level=9 and =10 shown, making it harder to focus on more important borders and other features
z15-jakarta-busy-borders

admin_level=6 vs track:
https://www.openstreetmap.org/#map=15/55.7010/-4.3341
image

@jeisenbe
Copy link
Collaborator Author

Here are the current renderings of admin_level=2 (top) to admin_level=10 (bottom) at z13 (first level where 9 and 10 are shown)

admin-borders-test

And here are admin_level 5 to 10, compared with various railways in tunnels, paths (with and without surface=unpaved and access=no) and tracks (varous tracktypes). It is quite hard to make a new design which does not get confused with one of these.

admin-boundaries-with-railway-tunnels-tracks-and-paths

Note also that the semi-transparent boundary looks different when the background color changes

@Prince-Kassad
Copy link

I disagree with this change.

We are one of the very few maps on the Internet that render administrative boundaries down to the district level at all (Google Maps renders only down to state level by default, and renders municipality borders only on user request, i. e. by entering the name in the search box). I suspect our rendering of boundaries is one of the reasons users may prefer us over other maps. The only reason we stop at al=10 because administrative boundaries are only formally defined up to 10, and everything above is basically user discretion.

The shown example from Jakarta do not seem to be administrative boundaries. The German Wikipedia article on Jakarta (cf: https://de.wikipedia.org/wiki/Jakarta ) calls them "quarters" and "neighborhoods" so they seem to be more on the order of statistic districts which we would not map as an administrative boundary in other countries, or only on al=11/12 (which is not rendered because as I said, user discretion)

We definitely need to rethink borders (I've never been a fan of the light purple color) but the solution is not dropping rendering.

@jengelh
Copy link

jengelh commented Feb 1, 2020

I think there is a certain disconnect as how what admin_levels is used across the world.

The EU has harmonized this, see https://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics , with LAU beginning at admin_level=7, the "last unit with power" is 9 (DE) or 10 (UK); in the US it also appears to be 9.

I do not have first hand knowledge how Indonesia is run, but I get the impression from OSMwiki that the LAU begins at admin_level=5 already, and the last unit of power is the keluharan, which is to be mapped with admin_level=7 (but in the city of Badung, you find incomplete keluharan polygons and relations with level 8...)

Either Indonesia needs to reorganize its admin_levels and add more spacing (move cities from 5 to 6, move keluharan from 7 to 9, move their level9 to 11, 10 to 12), or e.g. the EU needs to reduce the amount of levels they utilize (e.g. level 3,5,7 is seldomly used in Germany).

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 2, 2020

The shown example from Jakarta do not seem to be administrative boundaries.

@Prince-Kassad - the admin_level=9 and 10 boundary=administrative areas in Indonesia are actually smaller than quarters in cities. The admin_level=9 features are referred to as an "RW", short for "Rukun Warga" - this can be translated approximately "Harmonious citizens", and usually includes a neighborhood with 100 to 500 families. It is lead by a Ketua RW, commonly called "Pak RW" (RW Elder, "Mister RW") who is elected by the heads of household of the community. They do not have an official office but the RW collectively owns things like chairs, a stage and tents that can be used for community festivals and official national celebrations.

The RT (Rukun Tetangga, "harmonious neighbors") consists of a few dozen families on a couple of neighboring blocks in a town or city, and the heads of household are "required" to meet together every month to hear the Pak RT read government announcements, plan community service activities, organize neighborhood safety patrols, install residential street signs, clean up trash and so on. There are required dues for each family and public shaming if you don't pay in time. The "Pak RT" is elected but I don't think there is a salary at this level.

When I first moved to Indonesia, to a town in central Java, my new landlord was required to get a signed letter from Mister RT, which then had to be signed by the Ketua RW, then by the head of the desa/elurahan (village/town quarter, admin_level=8), then by the head of the kecamatan (admin_level=7), then we had to go to the mayor's office, before taking it all to the Immigration office, along with a letter from the town police station. So while these levels are community-directed, they have significance in the local bureaucracy. If you want to build a church or mosque you also need approval from the RT and RW before you get approval from the Lurah or Kepala Desa and then the Camat, going up the chain.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 2, 2020

However, I also agree with your point that these levels are rather minor and do not need to be shown on a general-purpose map. But this seems to also be the case for how admin_level=9 and admin_level=10 are used in most countries which I know (Mainly Latin America, North America, and Asia).

In Britain, only level=10 is used for civil parishes, and these only cover 35% of the population in England (mainly rural areas), and do not include Scotland or metropolitan areas.

In Latin America most admin_level=9 and =10 areas are subdivisions the size of quarters and neighborhoods and smaller, with limited administrative powers. For example, when I lived in Costa Rica, I knew the names of my provincia, canton and distrito (levels 4, 6 and 8) but not the name of the "barrio" (level 10)- and there are wikipedia articles for the first 3, but not the later.

Looking at the table at https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries and below, there are 44 countries which use neither admin_level=9 or =10, and another 39 only use one or the other. There are 54 countries which use both divisions, if the table is up-to-date.

I can't interpret the meaning of all the terms in the table, but the great majorityof admin_level=9 and =10 terms which I can translate are for quite small areas: villages, neighborhoods, quarters or smaller divisions (e.g. "group of 10 houses!"!, and many do not appear to be administratively significant (Statistical area, locality, electoral ward...).

In contrast, the level that is translated at "municipality" (town/city) is usually admin_level=8, or sometimes 6 or 7. These are more significant in the countries with which I am familiar.

Also, comparing admin_level=11 which is fairly consistently used for the "neighborhood" / "barrio" level, this appears to be similar to admin_level=10 in the majority of countries which use the 2 to 10 system instead of 2 to 11.

Ideally we could display admin levels 2 to 11 all in a unique way, but this would require finding 3 new distinct renderings for admin levels 7/8, 9/10 and 11. While I would welcome it if someone is able to achieve this in a legible way, I don't think it is feasible.

@Prince-Kassad
Copy link

In Germany, al=9/10 are mostly/always former municipalities that lost their independence in reforms of the 1970s. Or in other words, they are all villages and usually very well-known locally since people tend to identify with their village rather than with their municipality. The former borders are usually not well-known and can only be inferred from old PD maps, but they still play an important role because they form the basis of the national cadastre (there's one for each al=9/10 in Germany, or should be in an ideal world)

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 2, 2020

"The former borders are usually not well-known and can only be inferred from old PD maps"

They are not available in the public domain? This suggests they are less appropriate for displaying on this style, since it is not really possible for local mappers to correct any errors from the old sources, no?

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 2, 2020

I think there is a certain disconnect as how what admin_levels is used across the world. The EU has harmonized this ... with LAU beginning at admin_level=7, the "last unit with power" is 9 (DE) ...

I do not have first hand knowledge how Indonesia is run, but I get the impression from OSMwiki that the LAU begins at admin_level=5 already

I had not heard of the "NUTS" system before (nice name :-) ), but according to the linked page it is almost entirely based on the population of each unit:

"Specific guidelines are based in population:"
level | min pop | max population
NUTS 1 | 3 million | 7 million
NUTS 2 | 800,000 | 3 million
NUTS 3 | 150,000 | 800,000

Based on this, admin_level=4 (Provinsi) Indonesia (and USA States) are often larger than NUTS 1:
https://en.wikipedia.org/wiki/Provinces_of_Indonesia - 9 provinces have more than 8 million people each as of 2015. Half the population lives in these provinces, and the largest would need to be broken into 7 smaller parts to meet EU standards for NUTS 1 - but so would California. Another 12 provinces are too small for NUTS 1, though they tend to have large surface areas and all but 2 have over 1 million people, and the remaining 13 are "just right" according to Brussels.

They do fit the range of size of States in the USA just fine, however: these range from 600k to 40 million

There are 514 admin_level=5 Regency-level ("kota administrasi" and "kabupaten") entities in Indonesia which average 513k people, so they would fit into NUTS 2 or 3 mostly. These are quite important: "Following the implementation of decentralization beginning on 1 January 2001, regencies and city municipalities became the key administrative units responsible for providing most governmental services" so I think these count as NUTS 2 or 3: in densely-populated Java they average over 1 million people, so NUTS=2, but in eastern Indonesia they have ~250k.

Admin_level=6 is kecematan (district), led by a "camat" who is appointed by the Mayor or Regent of the admin_level=5 kota/kabupaten, rather than being directly elected. There are over 7000 of these, so average population is 37k, though in Jakarta they average 272k each and would qualify as NUTS3 - this is true of the kecamatan in other cities too. I'm not sure what defines a LAU vs NUTS - is it only average population, or more about the level of authority?

In the USA a county (admin_level=6) averages 100k people, but many are less than 10k and several are over 1 million.

admin_level=7 is a [desa or kelurahan] (rural village or urban "village"/suburb), headed by a Village Head who is directly elected in a rural village, or a Lurah who is appointed by the mayor in a Kota. So this level is a LAU (Local Administrative Unit) by EU standards. The national average at population is ~3100 for these, but with wide variation.

I agree that it would make more sense to use admin_level=8 rather than 7 for desa/kelurahan, and move the lower levels over by one. This would put RW at 10 and RT at 11. But this would still leave us with sub-village-level units (kampung/ dusun and RW) at admin_level 9 and 10, as in many other countries.

@jeisenbe
Copy link
Collaborator Author

jeisenbe commented Feb 2, 2020

After reading through the list at https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries - it appears that most countries use systems based on their colonial history or similar to their linguistic neighbors.

Britain and former colonies have few local administrative levels and levels do not always cover the whole area. Usually there is a county at admin_level=6 which covers the whole territory, but the municipialities and equivalients at admin_level=8 are only used in certain areas, while admin_level=10 is either limited in geographical extent (civil parishes in England) or non-administrative (electoral wards, statistical boundaries in Ireland, Australia, South Africa, India)

German-speaking areas and neighbors have municipalities at 8, parts of municipalities with self-governance at 9 and small areas without self-governance at 10

I can't understand the former-Soviet system, or China's organization.

Japan uses 7 for municipalities / village areas, 8 for parts of municipalities, 9 for quarters and 10 for small neighborhoods

Spanish-influenced countries are varied, but usually have "municipos" at admin_level=6 and actual towns at admin_level=8, with suburbs and neighborhoods (barrios, etc) at 9 or 10

French colonies usually have the same names: municipalites or "Communes" at 8, "Communes associées", "Arrondissements municipaux " or similar at (9) and "quartiers" at (10)

But there seems to be some consensus that level 8 should be a local unit like a town or village or municipality, with 9 and 10 for parts of a town/village/city and smaller subdivisions.

@Prince-Kassad
Copy link

This suggests they are less appropriate for displaying on this style, since it is not really possible for local mappers to correct any errors from the old sources, no?

There are a handful of map features we don't have usable sources for and cannot be easily inferred on the ground. Most smaller mountains/hills are like that, or the names of small streams.

@jengelh
Copy link

jengelh commented Feb 2, 2020

Perhaps the introduction of text-based values can alleviate some of the issues, e.g. admin_level={municipal|county|national|state}, or a mixture of text and numbers, admin_level={state|national1|national2|national3|local1|local2|local3|municipal1|...}. That's a tagging discussion though.

@IgorEliezer
Copy link

IgorEliezer commented Feb 2, 2020

I'd take one or two of the following:

  1. Make it so level 10 boundaries appear only z15 - z18, as this is a very local-wide feature;
  2. Change the disused railway pattern to look more "railway-ish" (the 2 left-most tracks on the mock-up), as dotted can be confused with intermittent streams and paths.

image

@Prince-Kassad
Copy link

The mockup looks too similar to railway=preserved in my opinion, but maybe I just need a better comparison.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 2, 2020

  1. I don't remember now where it was, but I've already proposed adding quite typical visual element for our borders rendering toolset - T-shaped line endings (like proposed in pipeline rendering - see Pipeline should be visible #640 (comment)) - which allows composing more distinguishable border line variants.

  2. Jakarta at z15/16+ looks OK even with such small admin areas, so this case suggests moving rendering down rather than removing: https://www.openstreetmap.org/#map=16/-6.1178/106.9159

@IgorEliezer
Copy link

IgorEliezer commented Feb 2, 2020

@Prince-Kassad , you are right https://www.openstreetmap.org/#map=19/-23.40464/-46.78841. Perhaps, preserved could be rendered black, while disused could be gray?

@kocio-pl but I've already proposed adding quite typical visual element for our borders rendering toolset - T-shaped line endings (like proposed in pipeline rendering

A thing I like in level 10 borders is that how it discretely renders, for instance, in a residential way (maybe the dots could be more sparse?). I'm afraid that adding more visual elements would get in the way of other actual/physical things, such as POIs near the street.

Alternatively, below is one of ways how we represent disused railways, as cross-long-dashed line:

image

@Prince-Kassad
Copy link

A thing I like in level 10 borders is that how it discretely renders, for instance, in a residential way (maybe the dots could be more sparse?). I'm afraid that adding more visual elements would get in the way of other actual/physical things, such as POIs near the street.

A new al=10 rendering doesn't necessarily need to be more obnoxious, if you look at how the PD German topographical maps render administrative borders. al=10 is rendered there as a combination of dash and dot (kind of like our current al=6, but thinner and with longer lines). They also use the T-lines proposed by kocio-pl for state borders (i. e. al=4).

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 8, 2020

Yes, I meant adding new tool (T-shaped endings) for the whole borders system, not in any specific admin level.

There's also more things to consider. We could also group some track renderings as we do with admin zoom levels. In the end, we use 6 different patterns for the track alone (one for each tracktype), while for the whole border system we use only 7 patterns, because we group 7+8 and 9+10. That would bring more balance between borders system rendering and road system rendering.

@jeisenbe jeisenbe changed the title Remove rendering of admin_level=9 and 10 boundary=administrative borders Reduce prominence of admin_level=9 and 10 boundary=administrative borders, or remove them Mar 30, 2020
@jeisenbe
Copy link
Collaborator Author

I've changed the title to "Reduce prominence of admin_level 9 and 10..." because I now think it is possible to render these in a subtle way which will not be so easily confused with other features. Rendering these features does mean that we cannot go to pure gray borders, but I no longer think that is necessary or beneficial.

New rendering idea is to use thinner dashes with an occasional gap, to echo the pattern for higher admin levels while still being clearly less important. (Admin_level=9 at bottom with 4 dots then a gap, admin_level=8 at upper right with 4 dots and a long dash)

borders-after-desaturated-16:56 8305:24 3370

@jeisenbe
Copy link
Collaborator Author

Tests with all the railway and path features that might be confused with boundaries:

Current z14
current-boundaries-z14

New
new-boundaries-desat-violet-z15

Current z15
current-boundaries-test-z15

New z15
new-boundaries-desat-violet-z16

@jeisenbe
Copy link
Collaborator Author

Fixed by #4100 which does not remove admin_level=9/10 but renders them with a thinner, less prominent style

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