Proposal talk:Any moving thing grouping system

Ideas on the "grouping tree" image

• wheelchair is a four wheeled vehicle ;-)
• wheelchair, even if a vehicle, shares more properties with a pedestrian than a wheeled vehicle I think
• motorized, unmotorized. Putting bicycle at same level as motorcycle is a bit strange, they share some properties, but not all. Maybe create a sub-sub-class for mopped/scooter/motorcycles and another for racing_bike/trekking_bike/mountain_bike Sletuffe 19:11, 29 November 2008 (UTC)

You won't be able to make a tree where vehicle X only fits in one leaf without ambiguities (a person driving a wheelchair here is by law a pedestrian for example), and pursuing that world-wide super-tree looks like a waste of energy and time IMHO. First of all because countries have their own definitions for each of them (which may also differ with the meaning the translation of that word may have in natural language), and a vehicle category includes certain vehicles in one country but a different set in another one. If you don't want country dependent tags you'll have the great fun of picking all kinds of tags from the vehicle tree for just one restriction (although it could be defined as one vehicle group in that country). Lastly, the exact same vehicle could be put in two different vehicle classes in a country, just depending on what the owner wants when he registers it (a motorized quad for example, which can also be in the class of agricultural vehicles in Belgium, and certain signs don't allow the former but allow the latter). Or another example: a person on inline skates can choose whether he follows the rules of a pedestrian (and then he can't go faster than walking speed), or he can choose to follow the rules of cyclists. --Eimai 20:20, 29 November 2008 (UTC)

Yeah, I know that, what I want as a first step is to find a tree that comes closer to every country. Special case could be handle later, though I don't know how for the moment. The idea I am trying to construct is that country specific things will be added compared to the defined common tree. As an example, if mopped are class A or class B in belgium an extra tag mopped_A=yes could be added, either in the OSM DB directly, or as post-process by the fact it is known that the road having mopped_A=yes is a belgium road. Sletuffe 20:52, 29 November 2008 (UTC)

A wheelchair has two normal wheels and two depth wheels. It is considered to be like a bicycle which is allowed to drive on pavements with maxspeed=6. --Phobie 06:27, 3 December 2008 (UTC)

That's where you live. Over here it's a pedestrian. It's just a demonstration why this world-wide vehicle tree won't work. It has to be defined at country/state level. --Eimai 13:23, 3 December 2008 (UTC)

We have to do something on a per country basis (now or later), that's true, but I don't agree with what you say : "this world-wide vehicle tree won't work". The primary/secondary/tertiary/unclassified is irrelevant to france, because we only have 3. But, still it worked, a bit of explannation is to be done for the new users, but it work. The original schema came from the UK one I think, and we did manage to use it every where on earth. There problems of course, but we solve it on the "defaults" of each tags, or by a post-process of the data (routing software, or speed warning software take care about country defaults ). What I think is that we need a global world-wide system, and them do use the information with a little deviation for every country envolved Sletuffe 14:49, 3 December 2008 (UTC)

Per country defaults

"Ask in the talk page" :-) ...

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 somewhere in my "grouping tree" and 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 18:56, 22 November 2008 (UTC)

blop

I've just added most of the Belgian vehicles classification here so try to make a 1-1 mapping to UK, US, Chinese, Australian or German vehicle types. But I doubt you can do that with things like "moped class B". I'm quite sure every country has some special cases with its own categories or situations where one category includes a certain vehicle type in one country, but doesn't in another. We only need some smart mapping between them. Given that in each country they tag things according to their own rules, country defaults are already implicitly in use, we better define them properly. --Eimai 15:26, 22 November 2008 (UTC)

Man ! you'r fast, I haven't talk about this page to anyone. Okay, you got me ;-), I'm trying to put my ideas "clear" on a page, because I have to find by myself some of the monster problems that will raise

I will however keep the discussion on the page you created, but I find it too virtual, and things have probably come to a need of something clear, and another for discussion. Sletuffe 15:39, 22 November 2008 (UTC)

Sure, take your time. :-) It was just coincidence that I was starting to write down Belgian vehicle types somewhere today, been planning that for some time now. --Eimai 15:45, 22 November 2008 (UTC)

Ok !!! then I knwo why I didn't found it ! I have search for it this morning, and haven't re-checked before I started my nice SVG grouping tree. I'll stay tunned to the access namespace talk page also Sletuffe

languages and relations

This seems like a very messy subject, as this would require a large set of relations between words. In the end it would not be possible to render this in a map (though a good route planner might utilize the data). There is also a set of border definitions. Trike (tree wheel motorbike) comes under the definition of motorbike in some countries and car in other, some places buggies (small open cars with small engines) have access to beaches, and some places these are not allowed access to motorways. The suggestion here will not do anything else for us (the mappers) than to give us a bunch of more data to add, as I see no way of render this. If there is a need to differ between some of this in tagging, let us use subtags, so that we can say one default value, and a few exceptions. I do not have time, and I guess that goes for many of us, to make a relation database so that we can set up relations between all these words. --Skippern 19:14, 29 November 2008 (UTC)

I don't think it's going to be that more complicate to developpers, but for mappers it will be much much simpler.

tagging a "forbiden to vehicles" will be one tag with this solution, while now it needs something like 10 tags.

If developpers really cares for their work (and I agree they will) we might well set a database post-processor to take into account "implied tags" "country specific tags" "country implication tags". My message was on the talk list name Trying to find a solution for country specific and defaults values

Correct me if I'm wrong, but what I see in you subtags idea, is that you will need to tag :

• vehicles:wheeled:4:motorized:motocar=no isn't it about the same ?

Sletuffe 19:49, 29 November 2008 (UTC)

Subtags are already in use many places. is_in:continent=* is just one example. It is not an idea of me, just something that I have been introduced to. If you have a team to set up this relation, than by all means go ahead. Anything that can make OSM and connecting services better, but until there is a working system on pre or post-process level, than I would stick with a system that we know works. Subtags works. --Skippern 19:55, 29 November 2008 (UTC)

How ok ! I just call them differently as being "namespace" a way to group key with a same syntax. Anyhow, the problem isn't solved by that mean. I didn't say "subtags" are a bad idea, I am wondering how and if we can use them. My goal is to make tagging easier. What's your idea then ?

how do you tag a street that is, allowed to any vehicles but bus, but heavy goods and still allowed to pedestrians and bike with your system ? Sletuffe 20:57, 29 November 2008 (UTC)

highway=* with relation restrictions for psv. Can even set time limits on the restrictions, so that the nightbus can pass, but no buses in day time. --Skippern 22:50, 29 November 2008 (UTC)

How do I find the list of those relations ? are they allready defined (for every possible cases ?) do I have to write my own ? Sletuffe 23:24, 29 November 2008 (UTC)

Read Relations for information of the usage and implementation of relations --Skippern 10:02, 30 November 2008 (UTC)

I know what relations are, I'm not asking you to help me search on the wiki. I just read your comment that say : "with relation restrictions for psv." Well, that is not that clear, I could say "use the SVG grouping tree" and that wouldn't help either. So I still don't see your way of tagging. But if you are short on time, don't worry, just leave that, if other have understood they will answer you. Sletuffe 11:37, 30 November 2008 (UTC)

Computing access restrictions

I made a related proposal here. Basically my point of view is that any grouping system must be computable by software, otherwise it's useless. Moreover, a routing software is not really interested in the grouping system per se, but only in its effects on access restrictions: if I write a routing software, my only question is this: "can a taxi drive on a Belgian highway=tertiary which is tagged as psv=no?" I provided a generic algorithm which could work in any country and which needs, as parameters, a grouping system and a set of default access restrictions. However the algorithm can work only if the grouping system is a tree, not a directed acyclic graph. FedericoCozzi 14:31, 21 February 2009 (UTC)

The grouping system we created here is also (mainly?) intended for access restrictions. As of now, if you look closer, it is a tree. But the representation look more like a star for cosmetics reasons. As of computable, I don't see why it wouldn't be. But showing it as a picture is much more easy for people to understand what "vehicule=yes" will mean if they find "vehicule" in a tree. Use of this tree will of course need a more computable form, just like the table you created. The goal here is to define keyword than define a precise "moving thing". When well defined, it would be easier to apply restrictions. Sletuffe 11:07, 24 February 2009 (UTC)

I'm moving to Talk:Computing access restrictions in order to gather the discussion in one place, I'm copying this part there as well Sletuffe 11:30, 24 February 2009 (UTC)