[OSM-talk] tagging roads

[Blaž Lorger]

On Monday 03 August 2009 12:18:14 Emilie Laffray wrote:

> > 4. At the end it is always up to the individual mapper to decide what is
> > narrow. While 1 meter is 1 meter.
>
> Yes, 1 meter is 1 meter. That's why using an approximation is actually
> worse than using a relative factor. Using a precise number is going to
> introduce errors that can be quite bad in the end. I strongly oppose any
> tags that is using a measurement that WILL NOT be accurate. Height is fine
> because it is defined. Relative parameters are more flexible.

We generally agree that there needs to be a way to assure quality of entered 
data. Using two distinct tags for measured and estimated values (width and 
est_width) is one possible approach. But in my opinion it is not the right 
approach:

a. You must be careful when entering the data to use appropriate tag. It is 
easier to use tag width in place of est_width. So most people will probably 
use width instead of est_width. In such dual tag approach using tag width for 
estimated width and measured_width for exact width is likely to give better 
results, since people that put more effort in gathering data are more likely to 
put more effort in entering such data in database.

b. But dual tag approach is also problematic for software that uses data. 
Either software has to use exact value with fallback to estimated value, or 
more likely, software will only use one value and ignore the other. This in 
turn will likely cause that mappers will use tag supported by software 
regardless if their data is accurate or not.

What I'm proposing is to add additional quality assurance tags. Absence of 
such tags would mean that there is no way to know how accurate data is. But 
presence of such tags would give reasonable assurance on data quality. I see 
need for two such tags: measurement method and date of data acquisition.
So, when road width is just roughly estimated mapper would add only tag width. 
When road width is actually measured, tagging would look like this:
   width=6.5
   width:method=tape
   width:date=2009-07-23
When width is measured on aerial photography method could be aerial and date 
would be date when photography was taken, ...

This approach can be used with all values that require measurement. It gives a 
way to quickly gather rough and inaccurate data with a way to identify 
inaccurate data, so it can be improved upon.


>
> > 5. Should definition of "default road width" ever change. All narrow=*
> > tagging
> > will be completely useless and will have to be reevaluated from scratch.
> > Actually it will be useless before that due to subjective nature of value
> > assigned to tag.
>
> Roads don't change width every day. Any change in the road will likely mean
> that it has been redone and therefore would probably need to be retagged if
> you want to be fully accurate in the first place.
>
> > 6. You will actually require large number of values for "narrow" to even
> > approach granularity offered by one simple tag "width". Either you will
> > have to
> > have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could
> > not
> > be used, since it does not specify how narrow the road is or it could be
> > equivalent for narrow=car.
>
> I disagree. It is a relative parameter not to the vehicles but to the roads
> tag used. But in all honesty, it will only be applied on the smaller subset
> of the roads to be properly meaningful.
>
> > 7. You must prepare clear enough instructions how to select value for
> > narrow,
> > to reduce subjective factor to minimum.
>
> I believe that the subjective factor is no worse and actually better than
> using approximate width. It is something that is relative.
>
> > 8. You must get renderers to support it.
>
> Like everything else, like width......
>
> > On the other hand, if you use tag width, which is already established tag
> > if I
> > may add, you have to accomplish following:
> > 1. You must get renderers to support it.
> > 2. Prepare some guidelines how to estimate road width. Of course using
> > measuring equipment is always preferred but less realistic.
> > 3. Deprecate tag est_width and always store width data in tag width. Add
> > additional tag that would state accuracy of width data. This is really
> > not necessary, but will be easier to use by the software and probably
> > also easier
> > to map.
>
> This is ridiculous. I don't see how you can give guidelines to estimate
> road width. One of the problem with that is that in some areas the roads
> width will be fluctuating. In residential areas, it is common for streets
> to be changing.
> Deprecating est_width is a bit ridiculous. You are just saying in the end
> that width is estimated and therefore cannot be relied upon. Numbers and
> units are not something to be toyed with. The estimated factor clearly says
> it all. It is estimated. If you change this, width will not have a proper
> meaning as you will be mixing two qualities (estimated very broadly, and
> estimated ok).
> The relative factor of narrow is avoiding most of those issues since it is
> linked to a highway tag.
>
> Emilie Laffray