|
Hi, Take a look at relation 1083434, it has a tag route_master = bus which means it refers to some bus routes and in this case:
Which means there are directional routes between two addresses. Now that being said, if you look at Bus 89 : Gare de Vanves-Malakoff → Porte de France, you will see a square (Place d'Alleray) that is included fully in the route! And same goes for the reverse direction of the other route! Now my questions:
Any helps would be appreciated. Thanks. :)
This question is marked "community wiki".
|
|
Some people will split roundabouts for routes, but many will not. There is even editor support in JOSM for having complete roundabouts in routes. See the roundabout symbol in the picture below. So please don't "fix" this. There is no need for any special tagging for this. JOSM is open source. So you can look at the code they used to check if the roundabout was connected properly: http://josm.openstreetmap.de/
Does JOSM show you a uni directional arrow over the square? or does it draw the whole square circle and checks if they have connections with other parts of the route? Assume that you come from line a to a square and then from square to line b (in order of appearance in relation). Which nodes of the square will the bus driver actually drive on? Is that somehow indicated in JOSM or OSM?
(05 Jun '14, 14:28)
Aram Azhari
1
If you want to know what JOSM shows, then you should look at the picture above (at the end of the row highlighted in yellow). If you want to visualize only part of the roundabout you have to calculate that. You know from which node the bus enters from the previous way. You know from which road it leaves from the next way. A junction=roundabout is oneway by definition, so there should only be one possibility. OSM is a geodatabase with many data consumers but there are many more people adding data to it. When we "design" a tagging scheme, it should be easy to add the data foremost.
(05 Jun '14, 15:14)
cartinus
Yes that is what I had in mind when fixing. In the same route, some parts of the line are drawn in reverse and they are left for the application developers to guess the correct direction. Assume that I am trying to create one line that merges all route lines. What happens is that some line that are in the order, are drawn the other way around (basically the data contributor had clicked to draw in the opposite direction). There I check if the end of the current line matches the start of the next line, if not I reverse the second line so it would match. Now imagine this for our square...
(05 Jun '14, 15:29)
Aram Azhari
A line comes in order that enters, and then the square and after that, another line that also enters! Do you see my point? If these errors happen together, it makes the data un-fixable and therefore should not be allowed. The easiest fix to this is to come up with a better standard. If it was an easy fix then the application developers would go ahead and do it, but if it requires multiple heuristic trials, then at least as a standard it should not be allowed. Sure people can enter what they want in OSM, but there has to be a way to know what is right and what is not.
(05 Jun '14, 15:34)
Aram Azhari
3
You should only "fix" these things in you local copy. As these are not errors in the tagging.
(05 Jun '14, 15:35)
cartinus
2
It should be noted that there is indeed an error with the relation. With a sole exception, the "forward" and "backward" roles have been neglected, leaving doubt as to which direction the route follows a way. Being a unidirectional route, every way member should have a role defining the direction. Adding these roles would eliminate the ambiguity mentioned by Aram about multiple ways pointing into a roundabout.
(05 Jun '14, 17:33)
alester
A square is uni-directional by implication. But there are ways in this route where the direction is not defined but the nodes are in the reverse order. So it has to be fixed (by application) to have the proper order. Same goes for the square. If the person starts drawing the nodes clockwise or drawing them counterclockwise then we see the problem.
(07 Jun '14, 07:51)
Aram Azhari
Also, a square cannot necessarily have the start of its node on a line as there may be more than one entre/exit, but a bus route should absolutely be drawn regardless of the general shape of the street/square. Otherwise, I could just specify a bunch of lines selected from the actual roads and tell everyone one to guess the bus route. I can draw a sketch to better visualize the problem.
(07 Jun '14, 07:51)
Aram Azhari
You don't have to sketch anything as everybody understands you. If you have trouble understanding us, then maybe you can try talk-fr@, where you can ask questions and get answers in French (guessing that you are more fluent in that language).
(07 Jun '14, 10:16)
cartinus
Unfortunately I don't speak French. I came to the realization that this discussion should be taken to the core team that define the standards, otherwise your statement does not overcome the presumption that 'the mentioned relations produce ambiguous and difficult-to-resolve bus routes and is merely a visual representation of the actual bus routes'
(09 Jun '14, 13:06)
Aram Azhari
Then I guess given the fact that this is an openly collaborated database, I shall apply the corrections to the cloud and whoever that does not like it, may re-break it in their local copies. Of course, at the end of the day we are all looking for a working headache free database that everyone can benefit.
(10 Jun '14, 11:48)
Aram Azhari
1
As alester wrote above, one needs to add the forward/backward roles to each street segment in the relation that has to be followed in a particular direction. This is the direction you are looking for. This does not have to be added to the roundabout, as the direction for that is defined by the driving rules of the country.
(10 Jun '14, 12:53)
escada
You can see that in http://www.openstreetmap.org/way/108025091 (a part of this route) the person drew a circle and have mentioned in the note tag that "Ceci n'est pas un rond-point" or in other words, this is not a roundabout. What to do in this case?
(12 Jun '14, 13:43)
Aram Azhari
showing 5 of 14
show 9 more comments
|
|
In order to be usable by data consumers that don't have special handling to visualize the route, the roundabout Place d'Alleray would need to be split and the relations would need to be modified to include only the segment(s) actually crossed to get from an entrance to exit. 1
When importing OSM data into a routing database ways have to be split at every junction. We don't split the ways at every junction in the OSM data either to make this easier for them. Similarly this is a "problem" that has to be fixed by the application and not by changing the data.
(05 Jun '14, 12:21)
cartinus
|
|
Okay, After some research and with regards to those who commented on the issue, I am concluding and answering my own questions here:
Also, I realized that this was not the best route to give as an example. If you look at this part of the route, you will clearly see that the person has made a mistake of drawing on the wrong side of the street and worse, create alternate dead-end paths. To resolve these up to some extent, you can iterate through the ways of the relation and if you want any way that does not have its both ends connected to some other ways, then remove it. Note that you should not touch the first and last way of the route as they are supposed to only be connected on one end. Also note that removing a dead end from the relation will only remove that tail of the dead-end path and may leave a new dead-ends and as a result you need to recursively do this on the updated list until you are left with no dead-end paths. Best Regards, |
I recently saw a comment to the effect that some software will process such relations correctly (probably on IRC). However, if the relation is used directly for visualising the route then, as here, it will look wrong.
Visualization of the road itself is the less worrying factor for us. But let's say if you want to animate a bus moving on the route, then the case is that the bus has to follow a path and given that the square here is only one line, you cannot easily find where to exit. I mean I may be able to analyze the square and find out, but that is not preferred and only puts more weight on the system. So another question is, if this is a mistake, shall we fix it ?
@SK53 At least JOSM is able to handle such relations correctly, e.g. when ordering their elements. But I would expect difficulties in several end user applications.
@scai What do you mean by handling? The order is not the issue here. If you read the post again, the issue is the incorrect inclusion of extra geometry.
In JOSM you can add as many lines as you like and call it a relation, but JOSM does not check if you have actually created an incorrect bus route.
It sometimes even gets worse. The person who draws the route tends to choose various line direction when drawing and as a result, current ending of a line may have a common node with the ending of the next line in the order!
JOSM actually allows you to check if the bus relation is correct. First you have the relation editor sort the route. Then there is the column with the arrows/lines and the roundabout symbol you can see in the picture in my answer below.