Opened 10 years ago

Closed 5 years ago

#2094 closed defect (duplicate)

Draw only one dashed line per boundary way

Reported by: Vid the Kid Owned by: jburgess777@…
Priority: minor Milestone:
Component: mapnik Version:
Keywords: mapnik boundary relation dashed line drawing Cc: mapnik-team@…

Description

When Mapnik renders ways that are part of boundary relations, it will draw a dashed line over the way for each boundary relation the way is in. Since many boundary ways are in at least 2 boundary relations, this causes multiple dashed lines to be drawn on top of each other. Since the dashes often don't line up, this leads to some messy-looking boundaries. Example: http://www.openstreetmap.org/?lat=39.2541&lon=-84.0042&zoom=14&layers=B000FTF If Mapnik could, instead, draw only one dashed line per boundary way, the resulting map would be a lot prettier.

Change History (17)

comment:1 Changed 10 years ago by steve8@…

Owner: changed from steve8@… to jburgess777@…

John - this is something we have discussed previously. Any further thoughts/ideas.

comment:2 Changed 10 years ago by Ldp

Quickest solution would be to not render boundary relations anymore, but only the constituent ways. That does require those ways to be properly tagged: boundary=administrative + admin_level=n.

Only thing required: WHERE osm_id>0 in the query for boundaries, and it happily ignores every relation. Relations happen to have a negative osm_id in the postgis db.

A cleaner way would be to 'touch' every constituent way on import, and only 'remember' the lowest admin_level value for that way. Question remains: how to handle a diff where the way should be made into a higher numbered admin_level?

comment:3 Changed 10 years ago by Vid the Kid

Odd thing is, I'm not actually sure anymore exactly what Mapnik is doing, now that I've seen more boundaries in relations.

http://www.openstreetmap.org/browse/way/38006064

  • Way is tagged boundary=administrative, admin_level=6
  • Way is in two relations, each tagged boundary=administrative, admin_level=6
  • Dashed line is drawn twice (possibly 3 times, but probably only twice)

http://www.openstreetmap.org/browse/way/38236472

  • Way is tagged boundary=administrative, admin_level=8
  • Way is in two multipolygon relations, each tagged boundary=administrative, admin_level=8
  • Dashed line is drawn once

http://www.openstreetmap.org/browse/way/38256499

  • Way is tagged boundary=administrative, admin_level=8
  • Way is in one multipolygon relation tagged boundary=administrative, admin_level=8
  • Dashed line is drawn once

http://www.openstreetmap.org/browse/way/38746463

  • Way is tagged boundary=administrative, admin_level=8
  • Way is in one multipolygon relation tagged boundary=administrative, admin_level=8
  • Way is in one non-boundary multipolygon relation
  • Dashed line is not drawn at all

http://www.openstreetmap.org/browse/way/24314063

  • Way is tagged boundary=administrative, admin_level=6
  • Way is in one relations tagged boundary=administrative, admin_level=6
  • Dashed line is drawn once
  • This way overlaps another way, which is not in any relation, and is tagged boundary=administrative, but no admin_level tag. That's drawn as a thin purple line at z11 and lower.

It seems that for admin_level=6, the dashed line is drawn once for each relation, and not once for the tags on the way itself. Yet, for admin_level=8, the dashed line is drawn no more than once. Does Mapnik ignore boundary relations at admin_level=8 and only use the way tagging? If so, that's in contrast to admin_level=6, where the way tagging doesn't seem to add to the number of times the line is drawn.

comment:4 Changed 10 years ago by Ldp

Mapnik treats all boundary=administrative lines it finds in the database the same, whether they came from a way or a relation. Where you didn't see any line rendered at all, it probably never made it into the postgis database, due to tagging issues.

I think that where you see that a boundary is 'drawn once', the patterns for all of them happen to be exactly aligned.

Another thing to look for is if the boundary seems darker. That's where two or more of them were drawn on top of each other. Because each is drawn semi-transparently, the more there are, the darker the lines get.

comment:5 Changed 10 years ago by Ldp

Cc: mapnik-team@… added

comment:6 Changed 10 years ago by Vid the Kid

I'm fairly certain the city boundaries (admin_level=8) really are only being drawn once. The darkness is the same, whether it's a boundary of one city only, or a shared boundary between cities. And there's never any appearance of misaligned dashes, while the county boundaries (admin_level=6) dashes only line up about 1/4 of the time when they're drawn multiply.

Could the difference be that the county boundary relations are usually type=boundary whereas the city boundary relations are usually type=multipolygon?

comment:7 Changed 10 years ago by Ldp

No, type=boundary/multipolygon makes no difference. I had a closer look at the example you gave, and that can all be explained by what I said before: stacked rendering of ways and relations.

The Clinton County/Brown? County border even has 2 overlapping ways with admin_level, so even when you discount relations, you still have overlapping lines on the map. There are more of these overlapping ways.

By the way: the Clinton County relation is nowhere near a closed loop, so it doesn't render. Which in turn causes the northward going border in your example to be only rendered from the way and the Warren County relation, which happen to line up for that segment.

And there are other problems in your example. Ways without admin_level, for one. East of Port William and the I-71 should be a boundary, but it misses admin_level.

Oh, and the appearance of the border just north of Port William is what a single unstacked boundary render looks like. As you can see, it's much fainter than the other lines. So even where you see a darker line that has a good looking dash line, it's still from a stacked render.

comment:8 Changed 10 years ago by Vid the Kid

I'm aware of the county boundary ways with no admin_level. They were created in an earlier import as one closed way per county, and no relations. An editor in southwestern Ohio is splitting, merging, and incorporating them into the new tagging scheme with admin_level and relations. I'm just disregarding those old ways altogether, deleting them when a county's entire border has been created in the new system. When I'm done, there's only one way (or an end-to-end string of ways) defining the border between two counties. Currently that's only the Franklin-Delaware border, which in places has issues with overlapping city boundaries. The rest of the boundaries I've worked on have one way (which has its own admin_level and is in 2 boundary relations each with their own admin_level) and an older way or two with no admin_level which will eventually be deleted. Those older ways are rendered without dashes and I don't consider them to be contributing to the problem.

Anyway, I've got a more-isolated set of examples to show where the rendering behavior is different from how you say it is.

Three ways:

Each has its own admin_level=8 tag. Two of them are in exactly one boundary (multipolygon) relation, and the third is in both of those relations. Each of these relations has its own admin_level=8 tag. The three ways all come together at one node http://www.openstreetmap.org/browse/node/450579841 so comparing them should be easy.

The way you have described rendering behavior, one of these ways should be rendered with 3 stacked lines, and the others 2 stacked lines each. But clearly they are all the same effective opacity. Further, I've never seen overlapping out-of-phase dash patterns on these municipal boundaries from this particular import.

Bottom line: how can I tag the county boundaries so they render as nicely as the municipal boundaries do? Look specifically at the way http://www.openstreetmap.org/browse/way/38006271. It has no other ways overlapping it. (The county relations it's in are actually open, a situation I only just now noticed. I intend to fix that soon. Still, you said that should prevent the relation from contributing to the rendered output, but that's apparently not the case.) The behavior you describe seems consistent with what I can understand of osm.xml -- yes, I've looked through it. Except the new city boundaries seem to defy that beautifully. It doesn't make sense to me.

comment:9 Changed 10 years ago by Vid the Kid

Re closedness of Franklin and Delaware county relations: Franklin county relation should now be closed. Delaware county relation was closed, but somebody deleted a couple of the member ways. That'll take a little bit longer to fix.

comment:10 Changed 9 years ago by Ldp

Mikado in #2521 asked if there is any progress with this ticket.

No, not when dealing with type=boundary relations.

The solution is relatively easy: do not render boundary lines for the boundary=administrative relations, but for boundary=administrative way only.

Curiously, this is already happening if you convert to type=multipolygon+boundary=administrative relations for boundaries, due to a technicality in the mapnik db. The effect can be observed, for example: http://osm.org/go/0EnmZO3-- where the whole southwest corner of The Netherlands has been converted to multipolygon relation boundaries.

As the wiki entry for boundaries currently already says to tag the member ways with the most important relevant admin_level, I'm all for keeping the current behaviour for type=multipolygon relations, and implementing it for type=boundary relations.

In the end, it would be much simpler if the transition to type=multipolygon were made everywhere, but that is a discussion that has another place, not in this ticket.

comment:11 Changed 9 years ago by Mikado

Wouldn't this approach disable boundary rendering when a river or a highway is included in boundary relation? This behavior could be observed in Osmarenderer now.

I think that other than boundary ways could be included in boundaries since this is stated in territory division documents (border proceeds by the axis of river X until the bridge and then by the axis of road Y (sorry for bad translation)), and drawing boundaries over other ways is a bad practice: first, for unneeded duplicating of objects, and second, for making data to fit particular renderer instead of following approved mapping standard.

comment:12 Changed 9 years ago by Ldp

First, it would be better to talk about established mapping standards, instead of approved ones.

What would break down if you add boundary=administrative + admin_level=* to those river or road ways that are a member of a boundary?

The practice of tagging the member ways with the highest relevant admin_level (+ boundary=administrative) is described in http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries.

comment:13 Changed 9 years ago by Mikado

Oh, I guess you're right here. Adding boundary tags to the existing ways somehow didn't come to my mind; sets of different purpose tags seemed mutually exclusive. Thanks for the tip.

comment:14 Changed 8 years ago by Landwirt

Type: enhancementdefect

Well, looks like the drawing of boundaries is broken. Recently Mapnik seems to ignore the members of boundary relations and draws dashed line over dashed line, some borders are almost solid purple.

comment:15 Changed 8 years ago by Ldp

This overlapping rendering has always been there for type=boundary relations, and it was recently 'fixed' (in osm2pgsql) so type=multipolygon relations render the same.

You may have gotten used to non-overlapping rendering in Germany and The Netherlands, since these countries use type=multipolygon boundary relations.

PS: Please, continue to (also) tag the member ways with the relevant highest order admin_level.

comment:16 Changed 5 years ago by math1985

This is now also discussed on Github: https://github.com/gravitystorm/openstreetmap-carto/issues/344 Therefore, I will close the issue here.

comment:17 Changed 5 years ago by math1985

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.