After reading Pieren's comment to this Gnonthgol's answer and after having no response (not even negative one) to this enhancement ticket for Mapnik I started to wonder:

What is the big obstacle that prevents rendering of real width for higher zoom levels?

I do not believe it is technically impossible, since different types of roads get rendered in different widths.
Somewhere someone mentioned that road importance is the key for rendered width. This is a good option for lower zoom levels and for roads where the information is not present. Still more important roads (motorways) tend to be much wider and have more lanes than minor roads, so the relation of more important road being rendered more prominently is still there.

Even more so for waterways. Unlike for roads there are only two types based on size (river + stream). What else makes a river more important than its size/width? And having a uniform width tag for all linear objects is certainly much more consistent than developing tag array like small stream/stram/big stream/small river/river/big river/huge river (that partially happened for roads.

asked 01 Sep '11, 13:22

LM_1's gravatar image

LM_1
3.2k334988
accept rate: 10%

4

Seriously, if you want to discuss this then take it to the mailing lists. But in short, it's a map, not fake-aerial-imagery, so it's to be expected that things aren't always drawn to accurate scale.

(01 Sep '11, 18:31) Andy Allan
1

And I always thought that reality depicted as objects in an accurate positinon and scale are a map.

(01 Sep '11, 22:36) LM_1

The best solution for rivers is to draw the riverbank and tag it with waterway=riverbank. As I said in another question, the "width" tag solution works only if you put the tag everywhere along your feature (a road or a river). When the tag is not present, you can only estimate a default width which is very difficult because it is very cultural and country specific (the default width for a residential road is different between USA and Europe. Same for a default river width between Sudan and Switzerland). About rendering, the result might not be what you are expecting. Perhaps the segments with the tag "width" will be correct but the vast majority of the other segments will be incorrect. The resulting maps might be worst than not supporting the tag.

permanent link

answered 01 Sep '11, 13:36

Pieren's gravatar image

Pieren
9.6k2075157
accept rate: 15%

edited 01 Sep '11, 13:39

2

Riverbanks on uniformly wide rivers seem to me like a lot of duplicate data (in result three almost identical, slightly shifted parallel ways).
Within towns/cities there are good reasons to draw rivers with riverbanks because they are more often artificial and have more complicated shapes.
I believe that after renderer's support the width data would quickly be added.

For roads there is (despite some proposals) no way of tagging it. And the situation would be similar to rivers' - it is imaginable to create some "streetbanks" within towns, but otherwise width makes more sense.

(01 Sep '11, 13:47) LM_1

You're wrong within town/cities ! Riverbanks within cities are much more regular than in rural areas where these rivers vary considerably (mostly because they have lateral areas left that can be flooded). Look at a really natural river, even if it has been channelized, and you'll see large variations and irregularities of their banks, depending on the natural fields, type of soils, altitude. Rivers in cities are channelized so their banks are more regular, even if there are details such as harbour equipments & local adjustments around bridges, to help stabilize them on their feet.

(28 May '12, 07:12) Verdy_p

Sure that natural rivers are not regular, but generally in urbanized areas the map is much more detailed and smaller width differences are important. Even so it is better to know that a river is generally 20 m wide (and maybe wider in some areas) than not having any visual representation of its width. It would be perfect if everything could be mapped as area, but it is not - some things are simplified...

(28 May '12, 22:48) LM_1

It is generally admitted that a map is not an imagery, so that all widths are not proportional. But this is highly related to the current zoom level:

  • if we know the effective width of a path, and this width is already larger than the minimum display width to render it on the map, this width would override the default disaply width, so that it could be traced more exactly.
  • if there's no width specified, use a width assigned by default by the renderer for the type of path.
  • if the renderer minimum display width is larger than the specified width (or the default width for the type of path), then ignore the specified width or default width, just use the minimum display width to render the path (this will hide tiny details along the path, but it will create a usable map, where paths are consistantly visible all along).

This logic can be applied to roads, railways, rivers, and even to boundary limits (that don't have a specified width, but only a default width according to the boundary type, or may be according to the boundary effective surface (in square meters).

But for relaly large ways, whose width is not consistant along their way (notably rivers whose width are growing in a nearly monotonic way), specifying only widths would create inconsistant results. Gernally roads and railways have a very standard metric (which only varies when parallel lanes are added/removed along the way), but this is not the case of rivers that have much more variations (this would mean splitting the river into many more sections, each one with its own local width, plus a linear interpolation between points for this width).

For this reason it just seems simpler, for large enough rivers, to draw rivers not just with a single central path, but with its limiting banks, that are easier to geolocalize exactly on the map. In this case, choosing a representation of rivers by their boundaries (banks) is more consistant than using widths, at least for large rivers. A mapper can then autodetect these cases, and compute the widths itself, to determine if details of banks are accurate to represent the river, substituting the bounding banks by an auto-computed "skeleton" path that will be rendered by a minimum display width (larger than the effective width represented by the banks.

For now, such approach is not supported by renderers, so rivers have to be drawn twice, when their banks are detailed: you draw the bounding banks, as well as a virtual central path, which should be tagged correctly with a consistant width (or whose default width will be derived from the type of path). Which one of these two specifications of the same object should be chosen by the renderer, but I think that their task will be easier if both representations are grouped in a relation representing the whole river as a single object.

Note: nothing forbids using the same approach for streets, especially narrow streets in old cities, but these streets (generally not open to automotive traffic, but I won't bet it's always the case, there are certainly lots of exceptions, and such condition is then not determinant) could be assigned distinct types, without requiring to specify their effective widths (when they are consistantly narrower than the default widths of other streets of the same type). This is in fact the same kind of distinction between normal gauge railways, and narrow gauge railways.

permanent link

answered 02 Sep '11, 02:49

Verdy_p's gravatar image

Verdy_p
12681115
accept rate: 0%

edited 02 Sep '11, 02:54

If you want a map showing the width of rivers or roads (or other types of ways), I suggest you try rendering one yourself.

This will demonstrate what it look like, and show that it is technically possible. And you could share the stylesheets, which would make it easier for anyone else to make such a map.

permanent link

answered 01 Sep '11, 20:05

Vclaw's gravatar image

Vclaw
9.1k891140
accept rate: 22%

1

That is certainly possible. For someone like me (never attempted any rendering) it could be more than a job for one afternoon, but not impossible.

This question however is here to find out why it is not in place already.
Technical difficulties?
Processing power required?
Uniform width rivers are considered better?
Something else entirely?

(01 Sep '11, 21:51) LM_1
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×371
×308
×124
×61
×5

question asked: 01 Sep '11, 13:22

question was seen: 8,179 times

last updated: 28 May '12, 22:48

powered by OSQA