Opened 9 years ago

Closed 4 years ago

#1721 closed defect (wontfix)

[water] mapnik dosn't use width tag for waterway=canal

Reported by: bmog Owned by: mapnik-team@…
Priority: minor Milestone:
Component: mapnik Version:
Keywords: waterway canal width Cc:

Change History (6)

comment:1 Changed 9 years ago by Ldp

  • Owner changed from steve8@… to mapnik-team@…

comment:2 in reply to: ↑ description Changed 8 years ago by bmog

Replying to bmog:

For example:
http://openstreetmap.org/?lat=50.6042&lon=9.46831&zoom=17&layers=B000FTF

Hi,

this bug is still present and very annoying.

Was this bug simply forgotten or is there a more fundamental problem ?
width tag on an artifical object like canal provides practical information, I think !?

comment:3 follow-up: Changed 7 years ago by Ldp

The width tag is visually hard to implement. What should render at the transition from sections with width tag and those without, or with different values?

All that could conceivably be done now is to make a sudden change in the width of the rendered line, which is aesthetically displeasing.

A major technical hurdle is the fact that the source data can be in different geographical projections, some in projected values, some in latlong values. Line widths are done in pixels. Somehow the geographical value would need to be translated to a pixel value.

In short, I don't see support for width=* tags in the foreseeable future.

comment:4 in reply to: ↑ 3 Changed 6 years ago by cmuelle8

Replying to Ldp:

The width tag is visually hard to implement. What should render at the transition from sections with width tag and those without, or with different values?

All that could conceivably be done now is to make a sudden change in the width of the rendered line, which is aesthetically displeasing.

A major technical hurdle is the fact that the source data can be in different geographical projections, some in projected values, some in latlong values. Line widths are done in pixels. Somehow the geographical value would need to be translated to a pixel value.

In short, I don't see support for width=* tags in the foreseeable future.

Why not just adjust the rendering in ranges, this way you don't have to translate width to an exact pixel value? E.g.

waterway=canal  &&  width less than 2.5m -> render like waterway=ditch
waterway=canal  &&  width less than 7.5m -> render like waterway=stream
waterway=canal  &&  width above 7.5m -> render like waterway=river

of course these values might be consented upon

If this is not implemented people "tag for renderers", e.g. tag small man_made canals as waterway=stream, instead of doing it right. It's understandable since a small canal carrying wood in the medieval ages should not appear visually the same as a large canal built for barges or similar.

Thanks a ton to whomever steps up and fixes this bug in the mapnik stylesheet.

This would most probably also fix #3590 and #4656

Last edited 6 years ago by cmuelle8 (previous) (diff)

comment:5 Changed 4 years ago by math1985

  • Summary changed from mapnik dosn't use width tag for waterway=canal to [water] mapnik dosn't use width tag for waterway=canal

comment:6 Changed 4 years ago by math1985

  • Resolution set to wontfix
  • Status changed from new to closed

This is difficult to accomplish. For example, what should we do where the width changes? Explicitly mapping the outline would be the best solution. I will close this as wontfix.

Note: See TracTickets for help on using tickets.