[OSM-talk] Zonal restrictions.

[Ben Laenen]

On Wednesday 29 April 2009, Tobias Knerr wrote:
> Kurt Roeckx schrieb:
> > I'm looking for a way to map restrictions for a zone.  This
> > includes things like maxspeed, maxweight and parking restriction.
> >
> > I want to avoid having to place those tags on all the roads inside
> > the zone, specially for large zones, since it's very easy to forget
> > one.
>
> Well,
> - if you use tags to mark a zone, you can forget them just as easily

Tags are out. You need to combine the information, and a way to add more 
data. Unless you like adding the same set of tags on a lot of ways of 
course.

> - adding all ways to a relation isn't easier than tagging all of them

Sure, but nothing problem checkers wouldn't be able to show.

> - if you mark the entrances of the zone, you (or someone adding a
> track leaving the zone) can forget an entrance, which is much worse
> than forgetting a single tag because this error might affect areas
> far outside the zone

I think though that marking the boundaries with nodes could be used by 
some JOSM plugin to automatically create the zone relation. After that 
it's a matter of problem checking.

> - polygons indeed can save work, but suffer from problems e.g. with
> layered roads

And the problem that you don't know how to draw the polygon in the first 
place, if say you've only mapped part of the zone. So will you then 
guess to where it extends? And if not, how do you know later on the 
polygon isn't correctly placed? And at what places it's not correctly 
placed. And what if someone draws a road not part of the zone which 
curves a bit into the polygon you drew but forgets to replace the zone 
polygon, or doesn't see it? Etc.


> The advantages of zonal mapping for quality are, however, only minor.

I beg to differ. Zones often need something extra, like names or 
reference numbers. And if your zonal restriction is the equivalent of 
five tags on each way, I'd rather have that in one place instead of 
everywhere.

> Forgetting a tag on a single way isn't that much of a problem. It
> will either have only minor effects or be easily spotted by someone.
> This, in my opinion, isn't enough to compensate for the potential
> problems:
>
> - zonal mapping can be harder for newbies to understand, depending on
> editor support. Making simple road attributes hard to understand is a
> no-go.

Just a matter of documentation. There are a few countries on the wiki 
that have their traffic signs listed and their translation to OSM.

I also don't understand why it is harder for newbies in the first place. 
Is it because it might be solved with a relation?

> - zonal mapping makes it more difficult to write software evaluating
> the information, so less people will be able or willing to create
> cool stuff with OSM. Those who still do will have less time for other
> features.

Let's assume that one day the incredible OSM library will appear that 
will solve things like "I have vehicle type X, what are the access 
rules on this street?" You now sound like it's trivial as it is now, 
but it's actually surprisingly difficult to interpret a lot of tags 
already, and all countries have their own interpretations and rules as 
well on top of that.

> - some options for zonal mappings (such as polygons) have performance
> disadvantages. This makes providing OSM services more expensive or
> causes slower software.

You process the data before using it. You're not uploading OSM data in 
the xml format from the API directly into your gps either. When routers 
use the data it's also by processing the data first to make it usable 
to calculate routes.

And that's the real issue here: you want the data instantly ready, but 
that's not how the data should be in OSM. We map the world, if there's 
a zonal restriction, we map it as such.

> Therefore, I suggest that you map zones _in addition_ to directly
> adding tags with the information to the streets.

Duplicate tags are always a bad idea.

> This serves your
> stated purpose of avoiding errors: Zone information can be
> automatically compared with tag information to make sure that all
> streets in the zone have the required information.

But what if a street in a certain zone overrides those zonal 
restrictions with some other signs?

Just don't tag ways with the zonal restriction unless you specifically 
tell it's zonal.

> It would even be 
> possible to create editor plugins for the task of adding the zone's
> tags to the streets inside it on demand.

That's basically the worst thing you can do. If that happens I'll use it 
to tag all roads inside a country with "is_in=country X", or rather 
with "is_in=country X,continent Y". There's just no need for it, as it 
is tagged already, and the translation of tags to something a certain 
program can use should be done after getting the data from the API.

But in OSM, the data should resemble what's on the ground. If your 
purpose is to make a program that shows the traffic signs on a little 
screen on your gps, this kind of data is important.

> Most of this applies primarily to small-scale zones. I don't suggest
> that everyone uses tags to define which country an object is in. The
> built-up areas are probably a border case. I'm not entirely sure 
> whether tagging of individual highways is a good option here. It
> might still be, though, because it can also serve as a "I have
> checked for explicit access restrictions (such as maxspeeds) and
> there are none" marker.

Ben