Opened 13 years ago

Closed 13 years ago

#2366 closed enhancement (fixed)

Visualise width of streets and ways (given by Key:width)

Reported by: Claas Augner Owned by: ulfl
Priority: major Milestone:
Component: Internal mappaint style Version:
Keywords: Width Cc:


While mapping a multitude of housenumbers and other pois alongside streets, I have experienced inconvenience with intuitively (i.e. effortless) putting the respective nodes at the right spot (i.e. in an appropriate distance to the street). As I became increasingly aware of it and started to develop a sense, I came across others making the same mistakes and, for this reason, came to the conclusion that this is a fundamental problem.

It would be really helpful if JOSM could render (all kind of) streets (and ways) not only as normalised lines (which represent the middle line), but as areas (or three lines respectively: middle and outer lines) which visualise the streets' actual extent in width. In doing so, the width could and should be derived predominantly from the correspondent key ( and, if not given, either the conventional render method or (optionally) a standard value per street type (stored and configurable in JOSM) could be used instead.

--- (Further explanation)

Even though I intended the feature primarily to be a benefit for poi mapping, it does indeed have at least two further applications. On the one hand, visualisation of the width key (initially in JOSM and hopefully sometime in Mapnik/Osmarender) provides an incentive for mappers to actually record these widths. On the other hand, "seeing" the extent of an already recorded street makes it pretty easy to check whether one's GPS track does really differ to a relevant dimension and thus requires the street to be corrected – or not.

Finally, I would like to point out the importance of actually implementing this enhancement as soon as possible. In my view the current visualisation of streets in JOSM fools us, when we focus (e.g. due to housenumbers) on the areas next to the streets. We err, as we lack a sense for realistic lengths and areas there (caused by the lines' zoom-independent width), a sense that the scale alone isn't able to establish.

A simple thought experiment therefor consists of two parallel streets, crossed orthogonally by another two parallel streets, forming a rectangle or – to simplify things – a square. If the task – in JOSM – was to record a meadow (extending over the whole square) as a closed way, that would be seemingly unproblematic and, as the streets "are certainly rendered on top" of the meadow and any white space between "looks unaesthetic", overlapping into the streets' (unknown) extent could probably be accepted; hardly anybody (if any) would spend the time to properly determine the meadows' boundaries (not to mention the streets' – areas are anyway deadly for routing devices at present).

While missing accuracy might be rather harmless in this case, it isn't in connection with mapping housenumbers, pois and buildings. To make a long story short, we have three problems here:

Firstly: A segment between two crossings is actually shorter than (currently) displayed in JOSM, but we tend to neglect that fact and thus potentially "fix" our correct measuring points (we have to interpret the waypoints due to the GPS device's accuracy anyway, haven't we?).

Secondly: If we put a node in direct proximity to an – what we might not know at that time – inaccurate street and the street gets fixed someday (unthoughtfully but well-intentioned), the node can possibly and literally change sides.

Thirdly: If we unintentionally create an overlapping by drawing a building's ground plot with correct proportions but slightly oversized scale, a subsequent correction is almost impossible without damaging the proportion, in particular for thirds.

Naturally, the more complex situations get (e.g. curved streets of different width enclose a small area), the more accuracy gets lost. Having a realistic visualisation, it would not only be much easier to record even complex situations (the exemplary meadow would be a child's play), but also would these situations automatically gain higher accuracy.

On the contrary, not having the extent of a street visualised causes at least three negative effects on mapping quality:
– Data is recorded inaccurately.
– Inaccurate data causes confusion and further inaccurate data.
– Fixing inaccurate data remains an inefficient process and often causes further inaccuracy or damage.

Attachments (0)

Change History (4)

comment:1 Changed 13 years ago by stoecker

Try setting "mappaint.useRealWidth" to "true".

comment:2 Changed 13 years ago by Claas Augner

I tried that, but it does not have exactly the desired effect. The rendered width of each street is still static, only depending on the street type (footway: 0.75m, residential/unclassified: 3.25m, secondary: 5.25m, service: 2m, tertiary: 4m, etc.).

Could you please add support for individual width rendering according to Key:width when given?

comment:3 Changed 13 years ago by anonymous

Component: unspecifiedInternal mappaint style
Owner: changed from team to ulfl
Priority: criticalmajor

comment:4 Changed 13 years ago by ulfl

Resolution: fixed
Status: newclosed

I changed it that "mappaint.useRealWidth" will also use the "width" / "est_width" tags

fixed in SVN1551

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain ulfl.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.