Talk:Country specific default values

against

Okay, I'll try to give my point.

The danger IMHO of having country defaults is that we cannot take advantage of existing tools made for another country. So we have one more risk to have routing specific programs, or renderer specific. But here is the dilemma : Those country specific things exists, we have to take them into account wich ever is the method.

I see two : 1 let the osm db be self-explanatory and all data in it is enough to know, without wich country it is in, what are the propertie of the object 2 Maintain a separate data base for wich we have each country's defaults that defers from the "world wide defaults"

In the 1 case, a country in wich pedestrian are allowed on motorway will need to add foot=yes at every motor way. In the 2 case, every program will need a way to know what are the defaults for each country.

All the question is, do we put the burden on developpers or on mappers ? or, in a more clever question : what will benefit more to the global usage of osm ? or, which is, in hours, longer ?

I don't really have the answer to my last questions.

What I can say, is that in the end, it will anyway fall on the developpers, either the developper of the editors, to ease the pain of mappers ( in JOSM, you "just" say you are from belgium, and at every way some defaults of your country will be added, based on a defaults's country list ) or to the developpers of tools that make use of the data.

Seams to me, that we will ever have less editors of the data than tools to manage the data. But this is a thought

+ there is some voice that tells me (but I have no good example to show it) : the fact that pedestrians are or are not allowed on a motorway is a data, and so, we shouldn't pull it out of the DB and let is closer as possible as the data to which it relate (the motorway)

My point is also true for default groupe of vehicles, for default values assumed all along the osm data.

BUT ! I don't say that a specific type of object, specific to a country shouldn't be described on the wiki or shouldn't be in the OSM DB.

for example, even if "Moped class A" is specific to belgium, it has to be in some group and has to be usable in all the access=* tags

However, if the "Moped class A" can be expressed with other tags or values, such as : motor_engine=50cc and that there is a chance we find a same class somewhere else, then we should merge IMHO.

Let's suppose one minute, that in france we have a "mopped 50cc max" restriction system and that in belgium you have a "Moped class A" wich is any mopped with power engine under 50cc. We agree that we use the same thing right ? but with a different name ?

I now buy in france, a garmin GPS unit and a "mopped 50cc max". I am lucky : there is a field in my garmin "for mopped under 50cc" (that is not the case, don't worry :-) ) and it match osm perfectly, because In france we have mapped with a class "mopped 50cc max" perfect. Now I'm going to belgium, my garmin unit will stop routing me ;-(( because the two class are the same, but not with same name.

Either I will need to call the mkgmap developper to ask him to take into account all 20 class of the world that are equivalent (on wich he will probably ask me to do it )

Or we define a key max_mopped_power and every one includes in JOSM a preset that create the mapping

• "mopped 50cc max"->max_mopped_power=50
• "Moped class A"->max_mopped_power=50
• "Moped class B"->max_mopped_power=100

etc... Sletuffe 19:03, 22 November 2008 (UTC)