Relationship boundaries are rendered twice #344

Closed
Circeus opened this Issue Feb 19, 2014 · 25 comments

Projects

None yet

7 participants

@Circeus
Circeus commented Feb 19, 2014

From the code in admin.mss, I can't figure out why, but (as far as I can tell) boundary relationships will be rendered regardless of the tagging on the member ways. Since tagging ways separately with boundary tags will also cause these to be rendered, in many instances you'll get ways that render as boundaries twice. The result is that it is essentially impossible to have meaningful boundary relationships without making it impossible to have consistent rendering between ways with identical tags.

For a simple example: http://www.openstreetmap.org/#map=17/33.81944/-118.16976

The issue is not limited to the interaction of way tags and relationships, since a way that belongs to multiple boundary relationships will still suffer the same problem. Is there any way to limit the rendering at the way level (i.e. check for boundary tags OR membership in a boundary=administrative relationship) rather than rendering from both sides?

@dieterdreist

2014-02-19 23:26 GMT+01:00 Circeus notifications@github.com:

From the code in admin.mss, I can't figure out why, but boundary
relationships will be rendered regardless of the tagging on the member
ways. Since tagging ways separately with boundary tags will also cause
these to be rendered, in many instances you'll get ways that render as
boundaries twice.

maybe they also get rendered three times: in the case of adjacent
boundaries (i.e. not a coast boundary) you will get a rendering for each of
the adjacent adminitrative entities plus eventually of the way itself (if
it has rendered boundary/admin tags as well).

@math1985
Collaborator

I didn't follow the discussion, is this tagging as seen as correct?

@Circeus
Circeus commented Feb 20, 2014

maybe they also get rendered three times: in the case of adjacent boundaries (i.e. not a coast boundary) you will get a rendering for each of the adjacent administrative entities plus eventually of the way itself (if it has rendered boundary/admin tags as well).

Indeed. I revised the post and ended up accidentally deleting a mention of that.

I didn't follow the discussion, is this tagging as seen as correct?

Whether or not tagging the ways is correct is irrelevant since neighboring relationships do generate the issue (though of course having it render 3 times instead of 2 makes it that much more likely to have render issues). Relationships are essentially a required feature for nominatim and related services to work. Having boundary tags on the ways is appropriate because otherwise, you have elements in the database with no tags of their own, which I'm fairly sure is considered a major no-no (and there are many places where relationships have not been implemented, or incompletely etc.)!

@math1985
Collaborator

So that leaves us with solving it in osm2pgsql, the sql queries, or the cartocss, right? Any preferences?

@pnorman
Collaborator
pnorman commented Feb 20, 2014

What is commonly viewed as correct tagging for two administrative entities sharing one boundary is

  • Ways 1, 2 and 3 where 2 is the shared boundary, with admin_level=2 and boundary=administrative on the ways
  • A relation with ways 1 and 2 as members, admin_level=2 boundary=administrative, name=A
  • A relation with ways 2 and 3 as members, admin_level=2 boundary=administrative, name=B

The ways may have a name tag as well, but this is not the name of the country but the name of the boundary. For example, way 2 is the A/B boundary, the name is not A or B. The usefulness of these is disputed, and their names probably shouldn't be rendered on a general purpose map.

I would probably go with rendering dashed lines from the ways in planet_osm_line. If we decide to render administrative areas, those would be from planet_osm_polygon. I'm not convinced about lower-level administrative areas, having them and place nodes might get confusing.

@Circeus
Circeus commented Feb 21, 2014

The ways may have a name tag as well, but this is not the name of the country but the name of the boundary.

You mean in cases, mostly, where the boundary happens to be another feature (e.g. a road or a river), right?

I'm not convinced about lower-level administrative boundaries, having them and place nodes might get confusing.

Currently, Mapnik renders them all the way down to admin_level=10 and no one complains. The highest levels are usually not dashed, so do not have the issue in the first place! If e choose to not render any boundary below a certain level, this issue (which starts around, I believe, admin_level=6 and lower ranks) becomes moot entirely, but I suspect a bevy of users will complain very loudly.

So that leaves us with solving it in osm2pgsql, the sql queries, or the cartocss, right? Any preferences?

I'm assuming the relationships are rendered from something else than cartocss in the first palce, since (afaict) the CSS makes no reference whatsoever to relations

If we want to promote tags on the boundary segments, the simplest method is brute force: render solely based on way tags and ignore relations (only the administrative ones, leave other type of boundaries alone) as far rendering is concerned. This also solves the related issue that we currently can't prevent a boundary relation name rendering at the centroid (I believe?) even if there is a place= tag connected to that relation Issue (105, I believe). See e.g. here (twin Morsang-sur-orge labels) or here (twin Beverly Hills labels). I'm aware this brings up an issue in cases where there rendering of city names was left entirely to rely on boundary relations, but since those labels not only ignore the place= rendering hierarchy entirely anyway (they only show up, I believe, at zoom 14 and higher!), they are currently an undesirable method of rendering place names.

Otherwise, a method that can detect either the tags on the way or membership in a boundary relationship, and turn on rendering if either condition is met would be needed. I do not have the technical knowledge as to whether tat is possible.

@pnorman
Collaborator
pnorman commented Feb 21, 2014

The ways may have a name tag as well, but this is not the name of the country but the name of the boundary.
You mean in cases, mostly, where the boundary happens to be another feature (e.g. a road or a river), right?

It would never be only the name of the country. In the example above, it would be the A/B border, if it were tagged.

I'm not convinced about lower-level administrative boundaries, having them and place nodes might get confusing.
Currently, Mapnik renders them all the way down to admin_level=10 and no one complains.

Whoops - I was speaking of administrative areas, and have corrected my earlier message. They're not currently rendered except when they trigger the catch-all.

I'd support removing admin boundaries from the catchall after we implement #103, but #104 is the issue for that while this is the issue for the lines, so let's carry any discussion about rendering the areas over there.

I'm assuming the relationships are rendered from something else than cartocss in the first palce, since (afaict) the CSS makes no reference whatsoever to relations

No - all boundaries are from cartocss and the osm2pgsql database, the same way roads and such are, with the exception of boundaries at low zooms (z1-z3?)

Fixing the dashed lines shouldn't be too hard, but the names on the lines which are also a mess require more work, since they're from the catchall afaik.

@Circeus
Circeus commented Feb 21, 2014

Honestly I don't care much for the names-on-line issue (which is as much a poor tagging issue as it is a rendering issue).

No - all boundaries are from cartocss and the osm2pgsql database, the same way roads and such are, with the exception of boundaries at low zooms (z1-z3?)

Then tell me with part of admin.mss is responsible for causing boundaries defined solely by relationships (with no boundary tags on the way) to render? I'm curious, since I couldn't figure out at all looking at the code 9which refers only to ways AFAICT). This comment clearly proves that not all rendering instructions are to be found in the CSS.

@cquest
cquest commented Feb 21, 2014

Improving boundary rendering has been on my agenda for some time (and still is).

Currently, boundaries are rendered from planet_osm_polygon, not from planet_osm_line and these polygons are coming from osm2pgsql processing of relations while lines are coming from ways.

This causes 2 problems:

  • if a relation is broken, the boundary is not rendered anymore (which may be fine in some renderings to indirectly show that there is a problem)
  • most boundaries are rendered many times causing for example unaligned dashes not looking great

To improve it, switching the the planet_osm_line is a option, but you'll face:

  • ways used in boundary relations that are not always tagged as boundaries: this will cause some boundaries parts to be missing
  • ways that may not have the lowest admin_level=* tag or no tag at all: this may cause the boundary style to be incorrect

The way to solve this I've explored, is to postprocess the boundary polygons to recreate linestrings.
I've worked on this for another purpose (create a topologically correct simplified boundary set for french municipalities), but the results my be reused. It could be maintained up-to-date using a trigger (not tested).

This kind of pre/post processing is a nice thing to do on renderings that aim the best graphical output despite data inconsistency, but I doubt this should be the goal of the OSM default rendering that needs to be showing data as the are and not as they should be.

@pnorman
Collaborator
pnorman commented Feb 21, 2014

This kind of pre/post processing is a nice thing to do on renderings that aim the best graphical output despite data inconsistency, but I doubt this should be the goal of the OSM default rendering that needs to be showing data as the are and not as they should be.

Yes - that's my view.

@pnorman
Collaborator
pnorman commented Feb 21, 2014

So I had a try in tilemill, the trick seems to add an osm_id > 0 restriction. PR soon.

@pnorman pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue Feb 21, 2014
@pnorman pnorman Stop boundary linestrings from relations being used
osm2pgsql will create linestrings for relations in planet_osm_roads (and
potentially planet_osm_line for incomplete/broken relations)

This leads to two problems

* Duplication of the lines when a boundary is complete and does not adjoin
another administrative area

* Overlapping lines

Fixes #344

This makes boundary lines substantially lighter as there are no longer many many
lines stacked on top of each other.
23065d1
@gravitystorm
Owner

I must confess to having read and re-read the conversation and I'm frequently lost as to what is going on.

I've made various changes today that affect the rendering of boundaries. Perhaps if I just state my goals it will make things clearer:

  • Each boundary should be rendered once, with the highest admin level (i.e. small number) of that particular line, whether from tags on ways or tags on relations
  • Each boundary should have the names of the admin area written alongside the line, on the interior of the area.

For example

    Canada
 -- 2 -- 2 -- 2 -- 2 --
   United States

I don't want the text written on top of the boundary, and I don't want the boundary line to be mis-mash of different admin_levels drawn over the top of one another.

Now how we manage this is a different topic :-)

@pnorman
Collaborator
pnorman commented Feb 21, 2014

#348 solves the line problem. I'll rebase it and re-test
I can probably get us POLYGONs instead of LINESTRINGs for the labels if that would help

@Circeus
Circeus commented Feb 21, 2014

Each boundary should be rendered once, with the highest admin level (i.e. small number) of that particular line, whether from tags on ways or tags on relations

That was indeed the basic gist of my original report. I got sidetracked along the way because there are multiple issues related to boundary rendering (the whole generating labels from relations, for example, which I believe will never be viable without a way to custom-place that label), but your comment captures exactly what I hoped to get.

@gravitystorm
Owner

That was indeed the basic gist of my original report.

Good stuff. This is all fixed as a combination of b0842bd 84daae0 and f0d0c9e

@gravitystorm gravitystorm added a commit that referenced this issue Feb 22, 2014
@gravitystorm Revert "Only use admin_levels from ways."
This reverts commit b0842bd.

Refs #348 #344

#348 (comment)

If this is making some boundaries disappear, then this clearly
needs a different approach or much more discussion.
3d79dfa
@Circeus
Circeus commented Feb 23, 2014

If the commit isn't going through, then his is NOT closed in any way or form and needs to be reopened.

@pnorman pnorman reopened this Mar 3, 2014
@math1985
Collaborator

Is this the same issue as https://trac.openstreetmap.org/ticket/2094?

@Circeus
Circeus commented Mar 31, 2014

Yes, clearly so.

@Circeus Circeus closed this Mar 31, 2014
@Circeus Circeus reopened this Mar 31, 2014
@Circeus
Circeus commented Mar 31, 2014

Accidentally used the wrong button >>;;;

@math1985 math1985 added the admin label Apr 14, 2014
@pnorman
Collaborator
pnorman commented Jul 20, 2014

Looked at this a bit. Currently a lot of boundaries are missing admin_level tagging on the ways, posing problems for only rendering from the linear features.

I do not believe slicing admin boundaries at run time to reconstruct this missing information is possible to do for performance reasons.

Mapbox takes the approach of pre-processing to reconstruct what should be the way tags. The approach could be adapted, but then we're introducing another process like coastlines, and of similar complexity.

Thoughts?

@pnorman
Collaborator
pnorman commented Sep 2, 2014

http://www.itoworld.com/map/2 indicates where boundaries are broken - anywhere in grey is an admin boundary without an amin_level tag. It looks like Poland is the major country with missing tags on ways.

@balrog-kun, thoughts on how to fix the data, as you were the reporter of problems in #348?

@balrog-kun

Just saw the comment, sorry.

With the slim tables it is possible to create an index telling you the lowest admin_level of all relations containing given way, something similar is done for hiking route relations for drawing all the route's colours as a parallel lines. But I guess the generic style should not assume slim mode tables being present.

Here's a slightly hacky idea that should help with the dashed lines appearing one on top of another but I can't test it at this time.

  • return the boundary polygons sorted by admin_level from SQL queries.
  • make each line being drawn overwrite what was there before, i.e. any boundaries of a higher admin_level. It seems it's possible to only overwrite the pixels inside the same Layer, and then once all the boundaries are rendered onto a clean canvas, have that canvas be blended with previous Layers. https://github.com/mapnik/mapnik/wiki/Compositing#style-level-compositing talks about this. To make a dashed line you'd probably need to use two LineSymbolizers, one to draw the dashes and another to erase the gaps with the "erasing stroke" trick documented there.
@pnorman
Collaborator
pnorman commented Sep 12, 2014

Ya, we can't depend on slim mode.

But what I was wondering about was a strategy for fixing the data in the regions with missing tags on ways.

@balrog-kun

@pnorman Sorry didn't realise that admin_levels on ways were considered correct tagging. The difference in Poland probably is a result of people documenting this on the forums as incorrect tagging and not encouraging it (I had stopped mapping boundaries earlier). Adding these tags as a big mechanical edit is technically easy, even with just JOSM and its search tool, not sure about other aspects of mechanical edits.

@math1985 math1985 added this to the Bugs and improvements milestone Sep 26, 2014
@math1985 math1985 added a commit to math1985/openstreetmap-carto that referenced this issue Nov 1, 2014
@math1985 math1985 Reduce number of overlapping admin borders
This reduces the number of overlapping admin borders by rendering them in order
from high to low admin_level, and by giving all admin borders a white background
while using comp-op: darken.

Admin borders are currently grouped into three groups: level 1-4, level 5-8,
and level 9+. This changes only prevents overlap of admin borders within a
group (including overlap of borders of the same level). To prevent overlap of
borders within groups, it would be necessary to merge the groups, which would
lead to performance loss, and is therefore not included in this PR.

This partially solves #344.
7dfed68
@math1985
Collaborator

Solved by #1107 some time ago.

@math1985 math1985 closed this May 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment