Bug in graphview
- Thanks, I've checked, tested and applied the patch. --Tordanik 10:14, 22 August 2009 (UTC)
How is graphview treating no_u_turn restrictions
First of all - thanks for a greate tool! As far as I see graphview does not visualize the possibility of making a u_turn on nodes, connecting to ways. So I think that it does not use the no_u_turn restriction when creating graph. Is it possible to implement such feature (both visualizing u_turns and taking the restriction into consideration), couse it is very difficult to check the graph for missing no_u_turns and you plugin can be very usefull for that.
- GraphView does evaluate no_u_turn. However, the visualization doesn't show whether turning at junction nodes is legal, so it's indeed impossible to see the effect of many no_u_turn restrictions right now. I'm going to examine whether modifying the graph representation has undesired effects. If it doesn't, I'll try to improve this in a future update. --Tordanik 21:43, 23 September 2009 (UTC)
Oneway does work!
Here is a screenshot that showes that oneway is not working: http://www.abload.de/img/onewayerrory77t.png
- You have created the graph for pedestrian routing (see "Graph View Dialog" in the lower right of your screenshot). GraphView assumes that pedestrians are not restricted by oneway=yes. --Tordanik 22:09, 20 March 2010 (UTC)
- ty --pr0wl 00:37, 21 March 2010 (UTC)
suggestions for better rendering
Thank you for this awesome plugin! Now I feel like I've got more than just hope on my side when I fiddle with turn restrictions.
I'm writing to request that you change the way you draw the arrow heads in the graph view layer.
I think that positioning the arrow heads at the ends of lines (as it is now) optimizes the display for looking at a node, and seeing where travelers may come from. But I'd much rather see where travelers may go _from_ there. Also, the very end of a line is a very busy place to put the arrow head, as this area sometimes becomes filled in solid with all the arrow heads. Rather than 100%, I suggest putting the arrow heads at 20% along the line. Or perhaps at 30% and 80%. Or perhaps it might be even more readable if the arrow heads were never more than 50px out from the starting node.
That way, I think it would be much easier for me to double check everything by tracing with my eyes the way a car/bike/person would go. With the arrow head near the starting node, I could quickly scan the lines leaving that node, and look for a missing/extra arrow head. As opposed to the way it is now, where I have to scan to the end of each line to see if there's an arrow head there.
Thanks for considering this. Take care -- JasonWoof 18:29, 1 February 2011 (UTC)
- Placing the arrow heads somewhere along the line, rather than at the line's end, is an interesting idea and could make the graph more clearly readable. Thanks for your suggestion, I'm experimenting with it. --Tordanik 16:19, 6 February 2011 (UTC)
- It has been a while now, but you might be interested in the additional rendering options in the new version of GraphView. It lets you place the arrowhead anywhere along the line (based on percentage of line length). --Tordanik 18:58, 7 August 2011 (BST)
Roads tagged as highway=tertiary_link are currently ignored. -- JanTH 11:46, 10 April 2012 (BST)
- You are right, that tag is missing from the access ruleset files . I'm going have to add it. --Tordanik 19:44, 12 April 2012 (BST)
What do you think about an option to only display important nodes (and edges between them), i.e. a graph where all nodes v with indeg(v)=outdeg(v)=1 have been removed? My guess is this would greatly improve the usefulness of the plugin. -- Eckhart 23:14, 21 October 2012 (BST)
- If I understand you correctly, your suggested simplified graph for the example on the article page would have only 6 nodes marked with circles and arrowheads for the edges, and remove the other 6 (such as the two nodes at the bottom, for example)? --Tordanik 00:34, 24 October 2012 (BST)
- Yeah, sounds right. -- Eckhart 21:36, 24 October 2012 (BST)
- Just as a quick status report: It seems that this isn't really trivial to implement in the existing architecture. As I'm quite busy anyway (because of my master thesis and OSM2World, among other things), this task is a bit too large at the moment. :/ I'll try to keep it in mind for when I get around to working on GraphView again. --Tordanik 02:12, 9 November 2012 (UTC)
access=no not for pedestrians?
I get a pedestrian graph to and from ways (e.g. highway=footway) that have the tag access=no. This is wrong because access=no implies foot=no. The graph is right if I add foot=no. Tested with version 28807. --holgermappt 17:00, 26 January 2013 (UTC)
- Unfortunately the evaluation rules that involve implications are not so clear. According to the logic used by GraphView, highway=footway already implies access=no + foot=designated, so adding access=no again changes nothing. This is consistent with OSM tags for routing/Access-Restrictions#Default. Of course I realize that the mapper who added access=no probably meant to imply foot=no, but these expectations aren't easy to formalize. --Tordanik 02:15, 28 January 2013 (UTC)
- OK, so the bug is the missing definition of the precedence of implicit and explicit access restrictions. This is really confusing because the Access page doesn't even mention implicit access regulations. And highway=steps is not even mentioned on the OSM tags for routing/Access-Restrictions page. Issue closed. --holgermappt 19:09, 29 January 2013 (UTC)
Preferences not stored?
Reversing "Draw directions separately"?
I live in a left-hand-drive country (Australia), so while the 'separate directions' option is very useful for spotting problems, it's effectively drawn reversed when compared to the physical road network.