Proposal talk:Trafficzone

maxspeed is not zone:traffic

I think explicit maxspeed tagging should always be done!
This Proposal can give us the ability to save information about if honking is allowed and about the speed-limits for hgv.
For speed-limits we need to save explicit information like "in town, but no extra speed-limit sign" or "in town with a 50-sign".
I would tag this with zone:traffic=DE:place + maxspeed=DE:place resp. zone:traffic=place + maxspeed=50.
Also I would prefix "walk" with "DE" maxspeed=DE:walk because it has a different meaning on different countries.
The prefix is needed because it would be very hard to precompute it from the country-boundries for every way.
One person mentioned that it would be problematic for tools to parse non numeric maxspeed values. I don't think so, but if the community does, we could place those values in a sub-tag like maxspeed:mark=DE:place or maxspeed:sign=DE:place.
--Phobie 01:27, 19 May 2009 (UTC)

Could you explain why we should do explicit maxspeed tagging if there is no explicit maxspeed sign? Implications are a widely used concept, so having zone:traffic=DE:place imply (among other things) a maxspeed tag is trivial and doesn't require applications to implement new features, as they already should know about implications anyway. Your solution does require a new concept for software ("constants" -- maybe those are a good idea but they aren't as common right now) and requires mappers to set an additional tag. --Tordanik 09:07, 19 May 2009 (UTC)

About allways tag maxspeed: Because maxspeed tagging will never be complete and therefore we need to know if a road has been checked for having a explicit limit! It does not matter how this will be tagged, but it has do be done. So maxspeed=DE:place is the same as zone:traffic=DE:place + maxspeed:checked=yes without a maxspeed=* tag (My first idea is easier to parse and does not depend on zone:traffic=*). The usefulness of knowing if a road has been checked for maxspeed is undisputable. Current navigation devices already do it that way. If it knows the currently valid speedlimit it will be show, if not it shows "-" (for "I don't know the current limit"). If you propose to not tag maxspeed where default "in town"-rules apply, that would mean for a navigation device to show no maxspeed on those roads or to make claims about the value. The zone:traffic=* key is also useful for navigation devices, they can use for calculating driving time and to show implicit maxspeeds in grey or something like that if maxspeed=* is missing. --Phobie 10:09, 19 May 2009 (UTC)

The "completeness check" argument applies to everything, not just maxspeed. (Think of access rights, inclines, tunnels and bridges, oneway; well, every tag really whose absence might either mean "there isn't anything special here" or "don't know"). Those aren't that bad, though, because adding explicit incline=0%, tunnel=no, bridge=no, oneway=no to every checked way doesn't require additional constants or anything else that makes using the tags harder. (I still think they are a bad idea, but if you really want to use them...)

That doesn't apply to maxspeed, you would need to introduce additional complexity. So I really suggest using a concept that doesn't mix up the actual tags with completeness metainformation. For example, maxspeed:checked=yes sounds like a good idea. It's extensible to other types of information. More importantly, software that doesn't care whether something is checked can simply ignore it, whereas using the maxspeed tag to convey checkedness affects every maxspeed user. --Tordanik 12:43, 19 May 2009 (UTC)

incline, tunnel and bridge have defaults which reflect the reality but this does not apply to maxspeed, the default is only one value out of many. In most places the official default is 50 but in reality this value applies to less than 20% of the streets. If a maxspeed-tag is missing we have a very good chance that a non default speed applies to this way.

maxspeed:checked=yes is a bad idea because it requires a additional tag and a additional database request for a parser. If we tag maxspeed=UK:place where others would tag nothing (the "do not tag defaults" mantra), we lose nothing. A parser could easily ignore this value or just use it in conjunction with a internal dictionary. --Phobie 10:38, 20 May 2009 (UTC)

I admit that the probability of a road without tunnel=yes not being a tunnel is higher than a road without maxspeed=* having default maxspeed, so you have a point there. I'm not sure about e.g. access rights or max*, though.

Regardless of that, I still favour separating quality check information from real content. Especially because this whole "unmapped vs. default" problem is only relevant now, while we still have large areas with missing or poor mapping. Two years from now, the basics will be mapped properly in many areas and we will instead have to keep data up-to-date. At that point, we don't need to know whether something has ever been checked, we need to know when it has been checked. That's easily possible with separate checking information (maxspeeed:checked=DATE, for example, even though I'm not perfectly convinced that this sort of data should be in the main db at all). It's absolutely impossible with explicit tagging of defaults.

Therefore, it seems to me that your solution addresses a temporary problem by changing the usage of a tag that is supposed to be in use long after the original problem was relevant. --Tordanik 18:11, 20 May 2009 (UTC)

maxspeed has no global default, so it always needs to be tagged. Trying to compute defaults from boundaries or zones is complicated and error-prone. Dates can be extracted from changeset/history data. --Phobie 00:08, 21 May 2009 (UTC)

I enter a maxspeed=50. Two years later, I check whether that maxspeed is still valid. It is, so I don't change anything. How can you tell that I have re-checked it from changeset/history data? Also, maxspeed can have local defaults, e.g. because a way has a zone:traffic tag. --Tordanik 17:03, 21 May 2009 (UTC)

About constants: The concept is not new and it has already been implemented by several applications because of widely used maxspeed-values like city_limits/default, walk, none/no/unlimited and variable/signals. --Phobie 10:09, 19 May 2009 (UTC)

About requires extra tag: No, it does not "require" mappers to set an additional tag! For me zone:traffic=* is an extra tag for additional information and does not depend on maxspeed*=* or the other way round! --Phobie 10:09, 19 May 2009 (UTC)

The suggestion is to make zone:traffic=* imply maxspeed information. Therefore, one tag is enough for a traffic zone with default maxspeeds. If we use your interpretation of maxspeed and zone information being independent, I need more than one tag to describe the same situation. --Tordanik 12:43, 19 May 2009 (UTC)

I think less tags makes it more simple to complete an area, that is important for most of the users, which don't use the whole encyclopaedia of tags. It is a great idea, implicit tagging is very strong - and a high risk project. But what about tagging maxspeed implicit via highway=residential? Outside city areas this tag shouldn't be used and for other highways the trafficzone-tag might be a good solution (OK, some problems with other highways or residential tagging without mayspeed, but this idea should be only an impulse). I think it will be hard to tag all the existing streets with such a tag, perhaps there is a more simple solution instead of another tag. More tags implicit more bugs, we should reduce them or keep the number down. To enable the OSM-data for navigation, we have to tag it consistantly and the maxspeed is one of the most important features for navigation. We have to discuss with maxspeed=no ;-) --DINENISO 07:24, 20 May 2009 (UTC)

This is a bad idea! The maxspeed=* on highway=residential can be everything from walk to 50 in places and walk to 100 out of places. --Phobie 00:15, 21 May 2009 (UTC)

The suggestion is to make zone:traffic=* NOT imply maxspeed information! If a navi/router wants to deduce maxspeed-information from "you are in a city" it is free to do that. Until now we have no tag to save the information "you are in a city by traffic laws". Telling me both tags describe the same situation is like telling me we do not need administrative-boundry-relations because we tag highway=residential... --Phobie 10:51, 20 May 2009 (UTC)

I don't understand what you are trying to tell me here. If I can (what I believe this zone:traffic tagging is for) tell that I'm in a zone of type xyz by traffic law, then I don't need any additional tags for maxspeeds, honking, whatever, if the defaults for xyz zones are valid. That means I don't need more than a single tag. (Unless I also want to add some "I've checked this" information, but that's not part of the information itself.) --Tordanik 18:11, 20 May 2009 (UTC)

Simply because in zone:traffic=DE:place you will see different maxspeed-values like "30", "walk", "30-zone", "50", "city_limits", etc.! (30-zone might be tagged as a sub-zone of place) And yes a honking-tag is not needed. --Phobie 00:40, 21 May 2009 (UTC)

30-zones are explicitly signposted. So we need not extra traffic-zone for them but can tagg this global maxspped with maxspeed=*. So a explicit 30-Zone is tagged as traffic-zone=DE:place + maxspeed=30. I don't know implicit 30-Zone when "in-town-speed" is set to e.g. 50 by law, but living_street implies a lower speed (in germany it's maxspeed=walk).

So with the 3 Values of HIGHWAY, TRAFFICZONE and MAXSPEED we can clearly define any situation without using complex polygons or algoriths (with both are more incorrect) --Cbm 14:56, 21 May 2009 (UTC)

The signs 310/311 (zone:traffic=DE:place) are very similar to 274.1/274.2 (zone:traffic=DE:speed:30)! The German law defines speed-30-zones as sub-zones of a place-zone! See the German wikipedia page for Tempo-30-Zone! --Phobie 02:45, 22. Mai 2009 (UTC)

trafficzone and traffic-laws

Every road which is part of the official traffic should be taqgged with trafficzone. Because with trafficzone we can combine the traffic-laws with Ways. E.g. tracks and private service-roads does not get a trafficzon-value because they are not in. Because trafficzone is a "placeholder" for a set of laws/restrictions there is no need to tag implicit maxspeed-values, because these parameters as given with trafficzone. ONly explicit restrictions (e.g. by signs) should be set with maxspeed=* --Cbm 13:57, 19 May 2009 (UTC)

"Traffic zone" is not enough to imply speeds

The rules in Belgium for default speeds are like this (I'm not discussing rules for buses or trucks here):

• motorway: 120 km/h
• inside built-up area (there are signs along the way to mark its boundaries): 50 km/h
• outside built-up area:
  • if the road has two lanes in each direction and it's dual carriage: 120 km/h
  • otherwise: 90 km/h

So those last two are in the same "traffic zone", but imply different speeds, depending on how the road looks like exactly. Now I'm all for implied maxspeed values given other tags, but if you're proposing to have a simple translation from the zone:traffic tag, we're getting problems here. We can't make two virtual traffic zones for these, as rules can change later on and it's exactly problems like that we want to avoid with this tag right? --Eimai 11:34, 20 May 2009 (UTC)

• motorway: maxspeed=BE:motorway (not needed because highway=motorway --> maxspeed=120 in BE)
• inside built-up area: maxspeed=BE:place
• outside built-up area:
  • if the road has two lanes in each direction and it's dual carriage: maxspeed=BE:motorway
  • otherwise: maxspeed=BE:land

Seems to be easy! --Phobie 15:31, 20 May 2009 (UTC)

First of all don't call it BE:motorway for non-motorway roads, that's asking for trouble.—Preceding unsigned comment added by Eimai (talk • contribs) 15:46, 20 May 2009

Aren't these motorway-like roads clearly be identify by highway=trunk or highway=primary and NOT highway=motorway to differ them clearly from real motorways, so it would be no identification-problem to tag them with zone:traffic=motorway as well? But If you want to define anoter name, do it. You name it. ;) --Cbm 14:48, 21 May 2009 (UTC)

Secondly, you didn't read my comment: you can't make two zones from one here. If the rule changes tomorrow that from now on it's 90 on dual carriage roads outside a built-up area (no need for two lanes in each direction) and 70 on other roads outside the built-up area, this tagging scheme will be completely useless, as you can then revisit all roads in the entire country and that's what this tag should basically avoid, otherwise there's no need for the tag and it would be just as good to tag with explicit values like maxspeed=50. —Preceding unsigned comment added by Eimai (talk • contribs) 15:46, 20 May 2009

No tagging concept is compatible with all changes of traffic laws. However, zone:traffic is compatible with some changes in law (changing the defaults without changing zone definitions, combining zones). It only slightly helps with splitting zones (it limits rechecking to those roads that are in the class that has been split, in your case the "otherwise" case, all others are still fine). That it doesn't solve all potential problems doesn't make it worthless.

There are other reasons for this proposal, too, it's not just about changing laws. I don't know about your local rules, but often the defaults cannot be expressed with a single explicit value, so explicit tagging wouldn't look like be maxspeed=x, but more like maxspeed=x + maxspeed:hgv=this + maxspeed:otherstrangevehicle=that + maxspeed:weight>7.5=evenlower + honking=bla, etc., which rules out explicit tagging, imo.

From your description, I'd probably go with creating two zones for the different road types outside built-up areas. --Tordanik 18:33, 20 May 2009 (UTC)

OK, call it zone:traffic=BE:motorwaylike if you find that value more comfortable.

I read your comment! zone:traffic=BE:motorwaylike is a subzone of zone:traffic=BE:land.

Normally I tag roads with lanes=*. With that key, zone:traffic=BE:place and a script your unlikely example would be auto-fixable! --Phobie 22:43, 20 May 2009 (UTC)

FAQ

I've decided to add a FAQ, because after about 400 mails on talk-de, I don't want to read everything again on all other mailing lists, fora etc. I hope this step improves the quality of this discussion. Feel free to point out or correct missing alternatives, wrong arguments and so on. --Tordanik 12:37, 21 May 2009 (UTC)

More zones?

Something that needs to be clarified: So far, I thought this proposal was about disjunct "classes" of defaults that aren't signed individually; _not_ about those "pedestrian zones" and "maxspeed zones". Was I wrong or is this simply a case of the choice of name ("zone") making people think that it was about the rectangular signs with a "Zone" written on them? What's the original intention here? --Tordanik 09:56, 22 May 2009 (UTC)

the original intention was catching inplicit traffic-laws and define the "field of traffic" (e.g. tracks, path ins parcs or private property is not a member of the field of traffic). Explicit signed zones like "maxspeed=30-zones" should IMHO be tagged with trafficzone=DE:urban (or DE:city, or DE.place, name isn't clear yet) + maxspeed=30 --Cbm 11:35, 22 May 2009 (UTC)

In a German Tempo-XX-Zone only the maxspeed is explicit but it implicates other values. Since this zone is not the same as maxspeed=30 that should be tagged "in some way"! --Phobie 00:30, 25 May 2009 (UTC)

I added some of the zones. All zones except "like a motorroad" are signed in some way. All mentioned zones are implicit in some way. --Phobie 00:30, 25 May 2009 (UTC)

Low emission zone is not a restriction

... but a complicated toll system. You can always drive there, it only depends how much you have to pay to be allowed to. --Lulu-Ann 16:53, 22 May 2009 (UTC)

In Germany they are restriction zones! There is no toll system and the badge costs only 5€ once. Currently there are zones which need at least a EURO2 or EURO3 badge. See Umweltplakette (German)! --Phobie 23:47, 24 May 2009 (UTC)

Redundant country prefix

I proposed to prefix all values with a country code. This makes parsing those country-specific values a lot easier! But it also has the drawback of being redundant information in the database. The information can also be derived from the countries boundary. For mappers it would be enough to map zone:traffic=place. A bot could prefix those values later for easier parsing. What is the best solution? --Phobie 13:52, 25 May 2009 (UTC)

The last one, I think. A bot can make the work, if necessary. And a bot can ignore the complete tags with the prefix. But perhabs the bot shouldn't write on the database but only the render-engine/navigation-software? Must be possible to combine the nation tag and the trafficzone tag!?

"Redundant information" isn't necessarily bad. Something being "redundant" is no problem at all if it doesn't cause inconsistencies or additional work. In this case, it doesn't, it's not harder to tag "DE:place" than "place", and it does help with evaluation. While it isn't additional information, it is a much more convenient way of accessing that information. Of course, it's also possible to have it calculated by the data user, but that means it has to be done again and again.

Whether a human or a bot puts it into the database doesn't matter that much, but I really don't see the problem with using DE:place from the start. Also note that not every country needs to have the same traffic zones. Country-specific tags prevent people from using those that don't make sense for their country. --Tordanik 21:19, 25 May 2009 (UTC)

Redundant: please describe the algorithm to be used by a program to determine the country (or the municipality) in which a street is.

Status: Draft -> next phase?

Anyone willing to make a first proposal out of this draft?

• Statement what a traffic-zone is, what it is not and what kind of regulations are collected in it.
• List all valid values,
• their semantics,
• how to deal with ambiguity arising from conflicting other tags
• What default-values to apply when some rule is not given/known for a country
• What country-codes are used, capital or non-capital letters, dealing with different rules in parts of countries and groups of countries
• ...(lots of stuff to discuss)

Currently there are just examples. I propose to open a set of forum-topics for these and someone to moderate the discussion. (so many topics in one forum-topic or worse wiki-talk-page would be confusing) --MarcusWolschon 05:53, 28 May 2009 (UTC)

• The statement is clear. Think about the last traffic_sign=city_limit you've seen and you know if you are rural or urban.
• For now globally valid values are <countycode>:rural and <countycode>:urban. We'll add more values if a country needs them...
• The semantics are clear.
• Which conflicts do you mean? This proposal doesn't need to care about conflicts, Inspector and Validator should...
• No default values. If a application designer wants do assume a default value, he is free to do so.
• Already made clear, capital letters ISO 3166 ALPHA-2.
• What else to discuss?

I changed that...

If you want to discuss in the forum, open ONE topic. You will see if the topic needs more subtopics later.

--Phobie 03:28, 9 July 2009 (UTC)

"Think about the last traffic_sign=city_limit you've seen and you know if you are rural or urban." that is not how routing works. You don't see routes but individual sections of roads without any knowledge where you will come from or go to in a final route. --MarcusWolschon 07:11, 10 July 2009 (UTC)

Zone key is confusing

Zone is used on traffic signs as a method to tell that a certain restriction starts at one point and won't end at the next junction, but at the end zone traffic sign. If you're using zone in a tag, people will assume it's meant for those traffic signs, and that's not the case. So please find a better key for this. --Eimai 12:03, 9 July 2009 (UTC)

Isn't that exactly what we want to express here? A urban zone starts at a place-name sign and does not end at the next junction. What is your suggestion for improvement? --Phobie 15:04, 9 July 2009 (UTC)

+1 to Phobie. an urban area is a zone which borders are im most cases are signed by a city_limit-signs. So it's the same behaviour as for other restriction-zones. --Cbm 21:40, 9 July 2009 (UTC)

If you're tagging built-up areas, then call it something like that. But you aren't really, as you also want to tag things like "motorway-like" roads, i.e. the kind of roads outside built-up areas where you can drive faster than normal roads. Those roads don't make up any zone at all. So if you purely want to tag built-up areas here: use a tag like "built-up_area=yes", or if you really like zone: "zone:built_up=yes". Trafficzone is way too general and would apply to numerous other things, including what's proposed elsewhere in the designation proposal, but obviously collide with those as you can only tag the built-up area with the proposed trafficzone tag. --Eimai 12:25, 10 July 2009 (UTC)

as you can see on the proposal-site there is no need for more than zone:traffic=DE:urban and DE:rural, at least for Germany --Cbm 13:24, 10 July 2009 (UTC)

I find the tag-name problematic. What if something is a part of multiple zone:traffic once more possible values are added to this key? That is the same mistake we did with amenity= all over again. --MarcusWolschon 07:02, 13 July 2009 (UTC)

Nothing can be in town and out of town at the same time! If you don't like the key-name, ok, but your argument doesn't count. I'm open for alternate names like traffic_law_locality=DE:in_town ;). (BTW. The amenity-problem can simply be fixed by amenity:"amenityname1"=yes or amenity="amenityname1";"amenityname2") --phobie m d 02:40, 29 August 2009 (UTC)

In other words: you're just using the tag for built-up areas. So why don't properly rename the tag then? --Eimai 16:49, 13 July 2009 (UTC)

Like written on the proposal page ways tagged with zone:traffic=DE:urban are official roads enclosed by traffic_sign=city_limit. It does not matter if the area is built-up or not. --phobie m d 02:40, 29 August 2009 (UTC)

IBTD about DE:urban/DE:rural. At least a zone 30 tag would be quite helpful (DE:speed:30, DE:zone30 or whatever), as it not only defines the speed, but, in most cases, in 30 zones there are other rights of way (left yields to right). --glglgl ✉ 15:37, 27 March 2018 (UTC)

On my understanding key zone:traffic is a definition of a set of traffic rules, or modifies or further restricts super-ordinate rules. It's not just about speed limit. As DE:zone30 is included in urban areas, full tag should be in hierarchical order: zone:traffic=DE:urban;zone30. As each country has limited set of rules for specific type of roads, number of traffic zones is limited as well. --Vanagaudi (talk) 14:43, 30 December 2019 (UTC)

Implications of zone:traffic as shorthand notation

It occurs to me that zone:traffic is in fact a shorthand notation (to programmers also known as a macro), i.e. using the zone:traffic tag is in every way equivalent to using the tags that make up its definition. Therefore, some thought should be given on what that means in practice.

• Any osm data extract will be incomplete and not fully parsable without the zone:traffic definitions, which should therefore be made available as part of the data (ideally in the form of meta-tags/objects in the database, or at least as an XML-file containing all definitions, world-wide, in a central location under version control); someone writing a parser should not be required to search the wiki for updates
• We need some elementary rules, e.g.
  • A zone:traffic definition must not contain other zone:traffic tags to avoid recursive parsing (technically possible, but makes things even more difficult to understand and apply)
  • Multiple zones should be able to coexist (to allow for nested zones which do exist in reality), and a tag zone:traffic=CC:zone1;CC:zone2;CC:zone3 should e.g. be parsed outside in. I.e. first apply definition of zone3, followed by zone2 and zone1, finally apply individual tags used to override defaults (tags applied later will override tags applied earlier)
• We must be aware that for what I believe to be the first time, osm-tags have more than local scope, an the meaning of the zone:traffic tag is defined elsewhere. In other words, changing a zone:traffic definition can have significant side-effects country-wide and using zone:traffic requires up-to-date knowledge of its definition. Country communities must find some way to establish and manage their zones.

--Wolfbert 18:06, 4 April 2011 (BST)

zone:traffic and maxspeed/source:maxspeed

Given that the value for maxspeed is currently defined as a number or "signals" (even though used in other ways to express zones), source:maxspeed was the first attempt to allow for something similar to zones (but as source-tag, it was really only a comment and not meant to be interpreted).

With this proposal, almost all source:maxspeed tags can be migrated to zone:traffic (rural, urban, living_street, motorway, ...), and source:maxspeed could be used more in line with other source tags. E.g. source:maxspeed=sign might still be used to indicate to a mapper that a zone-default was overridden on purpose.

There is one exception however, which is "walking speed". This is country-specific and does not form a zone by itself (but may be used e.g. as part of the definition of zone:traffic=CC:living_street). One way to handle this would be to officially extend the values for maxspeed by "CC:walk" (partly used already), and leave the assignment of a number to the application. If a country-specific number (say, 5km/h) is used instead, then a comment source:maxspeed=CC:walk would be required to distinguish this from a signed speed limit with stated limit.

--Wolfbert 18:06, 4 April 2011 (BST)

What is the rationale behind name "zone:traffic"

Is there particular reason for using column in the name? --Jakubt 21:19, 29 July 2011 (BST)

Mindmap

Hi, I found this proposal, and wrote a Question-Answer mindmap. Maybe this will help for the discussion. This is my initial mindmap and you are welcome to edit it directly. Change yes to no for example or rewrite something. Unfortunately my English is not the best,but you can correct it.

• Q1: Why do we need to add a Tag?

  A1,1: A additional Tag is needed <if> there is some information that we want in the database and currently we have no tag for that information.

  A1,2: <maybe> A additional tag is needed <if> there is some information that we have tags for it but will be easier to map with an additional tag.

• Q2: Is there some information that we want to represent but there are no tag?

  A2,1: Yes we want to know if we are in a urban or outside urban trafficzone.

  A2,2: And additional I think <maybe> we want to know if we are in a country or not,what can also be a traffic zone.

  ...more answers of course

• Q3: Is A2,1 is true?

  A3,1: Yes because we want the implizit information given with that

  A3,2: Yes because we want the explizit information given with that

• Q4: Is A3,1 is true?

  A4,1: <if> there is nothing against implizit information generally

  A4,2: <and if> theres nothing against implizit information from the tag in this case.

  A4,3: <and if> we think the implizit information from the tag will be useful.

  A4,4: <and if> we think the disadvantages of having this implizit information from the tag are smaller than the advantages

• Q5: Is theres nothing against implizit information generally?

  A5,1: No

• Q6: Is there nothing against implizit information from the tag in this case?

  A6,1: No

• Q7: Do we think the implizit information from the tag will be useful?

  A7,1: I think yes

• Q8: Do We think the disadvantages of having this implizit information from the tag are smaller than the advantages (without viewing the countrycode aspect,this is extra)

  A8,1:<Maybe>

  We make the database bigger and more confusing with some implizt given redundant information.

  redundant: some implizit things,but the key information that is given is not redundant.

  Less tags are better.

  Some information will no been set for a long time for some streets, not only maxspeed,so implizit information is good.

  The tag will not replace maxspeed.

  The tag gives some information for the time maxspeed is not set.

  And it is easier to set the zone:traffic tag than maxspeed, and you make no wrong information if you set zone:traffic.

  If you want to set maxspeed you have to check for signs.

  A big advantage is to have better maxspeed "guessing"

  Currently the navigation software have to think maxspeed is 100 if on a highway=tertiary in urban traffic zone. With the tag the software can guess 50, wich is in most cases a better guessing.

  And of course everything on the proposal page have to be considered.

• Q9: Do we want the explizit information given from the tag(the tag that gives the information about the traffic zone)?

  A9,1 No

• Q10: Is a additional Tag is needed <if> there is some information that we have tags for it but will be easier to map with an additional tag?

  A10,1: No,but maybe one is useful.

• Q11: Do we want to know if we are in a country or not?

  A11,1: <Maybe> Maybe a application is not able to calculate the country membership of a road. because of the advantage that applications can easy know the country to get implizit maxspeeds for routing,even if the application has not downloaded the whole country/boarder polygon. But on the other side it is possible for applications to preprocess the database data to get country informations and then store only a small part of the map with country informations for later offline use. Maybe the polygon method to get country information have some of the same issues Cbm described on the proposal page Proposed features/trafficzone.

Other Questions:

• Q12: Why use maxspeed=30 and source:maxspeed=DE:zone and not a zone tag.

  A12,1: The Decision is like that for A3,1 but in this case the zone tag would give implizit only the information that it gives explizit. Because of that it is better to make no extra tag. better the source tag to know why,maybe the reason changes.

• Q13: Is it good to have additional information in the database about whether a maxspeed tag is explizit because of a local traffic sign?

  A13,1: I think yes. And the the information can be hold in the source tag. If the source tag is not set there is no information. If the maxspeed tag is set ,but there is implizit maxspeed information avaiable and no source tag you have to assume that it is because a sign.

--Chili 14:44, 3 August 2012 (BST)