Proposed features/Narrow width

Text about width=narrow has been removed on page Key:width. Keep Right has been informed.

Narrow width
Status:	Approved (active)
Proposed by:	Kslotte
Tagging:	width=[[:Tag:width=narrow|narrow]]
Applies to:	ways
Definition:	A way that is narrower.
Rendered as:	depends on map purpose
Draft start:	2010-02-18
RFC start:	2010-02-18
Vote start:	2010-03-14
Vote end:	2010-03-28

Contents 1 Proposal 2 Tagging example 3 Rendering 4 Comments 5 See also 6 Voting

Proposal

width=narrow is a vague and subjective measurement that is currently in use (257 ways 18.2.2010).

The proposal is that tag width=narrow is made obsolete, that will guide mappers to give width in meters "numberm" (or in feet "numberft"). One argument for this approach is that narrow is a very vague definition and depends much on what type of maps are generated from OSM. If the width cannot be given precisely it is recommended to use est_width=* instead of width=narrow. An additional note can be made for example note=Road looks narrow, width needs verification.

Not to be confused with narrow=yes, that correspond to the traffic sign that a road is getting narrower.

The proposal has been heavily been re-written since RFC sent by e-mail 18.2.2010

Tagging example

Tagging of a way with 2 meters width as width=2m; not as width=narrow.

Or since 2 meters is a little less than seven feet width=7ft; not as width=6.5616ft

Rendering

width=narrow shouldn't be rendered in anyway. Rendering of absolute meter values depends of map type.

Comments

See discussion page.

See also

• RFC e-mail
• Proposed features/residential narrow
• Approved_features/Narrows
• Key:width
• Key:narrow

Voting

Voting has started, 2010-03-14.

• I oppose this proposal, You can't force OSM mappers to do anything. If someone wants to tag things with or render this then that's up to them. Socks 11:05, 14 March 2010 (UTC)
  • I improved the text to ", that will guide mappers". --Kslotte 12:35, 14 March 2010 (UTC)
• I don't like this proposal. Just use narrow=yes to the whole street, not only to traffic calming segments. "est_width" is not better neither more accurate as nobody agrees on the width limits (with or without parking lanes, sidewalks, etc). --Pieren 13:32, 14 March 2010 (UTC)
• This proposal is completely insane for reasons mentioned by Socks --Cartinus 18:45, 14 March 2010 (UTC)
• I like this proposal. Though I don't think we can actually ban a specific tag, it's clear to me that width=narrow should be discouraged in favour of verifiable distances. "narrow" is just too subjective a value to use for the width of a road. Rjw62 18:51, 14 March 2010 (UTC)
• I oppose this proposal. Tag is subjective and not verifyable --Gnonthgol 19:52, 14 March 2010 (UTC)
  • According to text this looks like a "yes". --Kslotte 07:30, 23 March 2010 (UTC)
• Not sure what yes/no means in this context as this is a poorly worded proposal, however subjective tagging should always be discouraged as no one else can verify it. -- Delta foxtrot2 23:10, 14 March 2010 (UTC)
  • This is a "yes". --Kslotte 07:25, 23 March 2010 (UTC)
• I oppose this proposal. If a numeric value with units cannot be used, than note=* or FIXME=* should be used to alert other mappers about missing data. width=narrow is an subjective value and will wary with mode of transport, therefor are almost useless as a value itself. --Skippern 00:25, 15 March 2010 (UTC)
  • This is a "Approval" according to the text and earlier opinion by Skippern. Note, the original proposal had an opposite meaning. --Kslotte 07:25, 23 March 2010 (UTC)
• I oppose this proposal. From the comments associated with the vote, it is rather obvious that this proposal is confusing. The proposal is to make width=narrow obsolete. Voters are agreeing and then voting no. I don't particularly like the tag, but I disagree with making it obsolete (deprecating it?). I would agree to adding comments to the tag description encouraging mappers to be more specific where possible.--turbodog 01:09, 15 March 2010 (UTC)
• I oppose this proposal. I doubt the average person cares to, or is able to, survey or estimate the actual width of a road. I don't believe that it really matters. I believe width=narrow, despite its subjectivity, is easy to estimate and understand. AM909 05:05, 15 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. -- Dieterdreist 12:39, 15 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. --Lulu-Ann 23:02, 17 March 2010 (UTC)
• I approve this proposal. Except for the fact this reads as two proposals Key:est_width= should be a separate vote from Key:width= plus Key:comment=road width was estimated or something to that effect.
  --Chief Mike 10:22, 18 March 2010 (UTC)
• I approve this proposal. narrow is a vague and a worst subjective measurement!! Use the width in metres and not some relative and subjective values. It important for later use in navigationsystems and errors + / - one meter from different user are not a problem. Or later the renderer can use it for redering.--Sali 06:02, 23 March 2010 (UTC)
• I oppose this proposal. In principle, I agree that a width in meters or feet is much better than a vague term like "narrow". But from a practical point of view, I think we should allow both options, and ask people kindly to use exact measures whenever possible. This is better for humans and computers (see discussion page for my reasoning). --Brian Schimmel 10:24, 23 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. --Wikifriend70 11:34, 23 March 2010 (UTC)
  • width=* is not less subjective as there is no agreement on what to measure. And width is not constant along the road in many places, so you will approximate anyway. I'm really tired about this lazy argument. Or you draw polygons for all your highways or even better, for each lane ? OSM is by nature subjective. So if you reject approximative tags, you can drop 9/10 of Map Features and just keep "width", "height", "surface" and "access". You know why the amounts of Wikipedia contributors is decreasing ? One of the reasons is of course because many articles looks complete but another major reason is that required standards for contributions are too high. And you start the same mistake in OSM.--Pieren 12:36, 23 March 2010 (UTC)

• I approve this proposal. Use the width in metres and not some relative and subjective values. --DanielH 12:59, 23 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. Bahnpirat 16:24, 23 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. peter.schoenemeier 18:30, 23 March 2010 (UTC)
• I approve this proposal. Use the width in metres and not some relative and subjective values. --StefanHuehne 06:36, 24 March 2010 (UTC)
• I approve this proposal. Use the width in metres, this is an SI unit. --Noframe 10:57, 27 March 2010 (UTC)

Voting has ended, 2010-03-28. Approvals 13, Opposes 6, Neutral votes 2; the result is Approved.

• Sorry, I don't count the same result. Approvals 12, Opposes 4 and 2 neutral and the rest is not clear.
  • But the result is anyway the same. --Kslotte 14:24, 29 March 2010 (UTC)
    • Yes I notice 4 strange votes coming very late at the same day from the same country. I could also play that game and call for colleagues on my local list but it's not my philosophy. --Pieren 14:38, 29 March 2010 (UTC)
      • I'm from Finland and I know nobody from German, neither I know what local list you are talking about. Anyway, there is support for "approval" even if we don't count the four last votes. --Kslotte 14:53, 29 March 2010 (UTC)
        • It is not forbidden to send a note to a local mailing list to ask for support on a certain proposal. That's why the votes from members of one local mailing list came close in time. If you are unsure about the validity, you are welcome to check the IPs. After all, the users on the mailing list could have come to a different opinion and vote against... Lulu-Ann