Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Change default style to allways show an arrow pointing the direction for active lines. #3380

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 9 comments

Comments

@openstreetmap-trac
Copy link

Reporter: extremecarver
[Submitted to the original trac issue database at 8.30pm, Tuesday, 7th December 2010]

Even though it is nice that oneway=yes or -1 is displayed via the style, it is not friendly at all (and therefore makes P2 for me unusable) that the direction otherwise by default is not shown (at least for the active line). In P1 the direction reverse arrow pointed the direction of every line, which was very good too (except for circles).

There are plenty of things that are direction dependant (any multipolygon, rivers, skipistes, incline, forward/backward, left/right or any key that is only applicable to one side of a street (of which plenty exist), a myriad of restrictions, ......).

One cannot expect users to change the style to show this, nor would it be practical (too much clutter), to display arrows for every way. Hence the direction reverse arrow has to indicate the direction of any line just as it did in P1, or better, if any line is selected there should be some sort of arrows to indicate which direction the line is facing (a circle is a closed line, so arrows too).

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.37pm, Tuesday, 7th December 2010]

We aim to add Potlatch 1-like behaviour with the direction arrow. However it's a much more difficult task in ActionScript 3/Flex than it was in ActionScript 1, which is why we haven't done so yet (despite spending some hours on the problem).

For the record, Potlatch 1 did indeed show the direction of circles, though you had to look pretty closely!

@openstreetmap-trac
Copy link
Author

Author: extremecarver
[Added to the original trac issue at 10.46am, Saturday, 11th December 2010]

Okay, good to know. Why not show arrows for any active way then?
(the only real confusing problem is that many people might expect the arrows to show backwards, if say oneway=-1 is tagged - but that could be solved by showing then two arrows, one for the driving direction inside the street, and one outside showing the direction of the line).

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 11.59am, Saturday, 11th December 2010]

Drawing arrows is very computationally expensive - especially on a really long way (we haven't implemented clipping regions for way drawing yet, so everything is recalculated on each redraw including off-screen regions). Certainly there's nothing to stop someone coming up with a style that does this but I'd be loth to include it as the default style!

@openstreetmap-trac
Copy link
Author

Author: stevage
[Added to the original trac issue at 10.22am, Sunday, 23rd January 2011]

Since I forgot about Richard's comment until now, I made some styles as suggested and put them in [25117]. See my checkin comments.

Oh, also, if MapCSS supported simultaneous :selected and :hover, I'd be tempted to make that the time at which direction arrows show up.

@openstreetmap-trac
Copy link
Author

Author: BennieD
[Added to the original trac issue at 10.04am, Tuesday, 25th January 2011]

Replying to [comment:4 stevage]:

Since I forgot about Richard's comment until now, I made some styles as suggested and put them in [25117]. See my checkin comments.

Oh, also, if MapCSS supported simultaneous :selected and :hover, I'd be tempted to make that the time at which direction arrows show up.
:I can't see this - must I add a style? How? /~~~~/

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.11am, Tuesday, 25th January 2011]

The change has not yet been deployed onto the live site so you can't see it yet. Changes to the code are not automatically published to openstreetmap.org; they require manual deployment.

As per discussions on the potlatch-dev mailing list, this particular change probably won't make it into the default style; though valuable to advanced mappers, it has serious drawbacks as a default style (confusing to newcomers who don't realise it doesn't mean "one way", comparatively slow to draw which is a serious issue on Linux Flash Player).

Instead, there will be a separate 'Enhanced' style for this. I will commit this in the next few days though am busy with the day job at the moment.

@openstreetmap-trac
Copy link
Author

Author: stevage
[Added to the original trac issue at 4.36am, Wednesday, 26th January 2011]

I'll disagree politely with two of your statements then shut up:

  1. "Confusing to newcomers" - IMHO anyone who has seen a oneway=yes rendering will not get them confused. The arrows are as different as I could possibly make them.

  2. Linux performance - since rendering performance on Windows seems to be vastly superior, is it worth exploring a bit further how to simplify styles for Linux users without compromising the Windows experience? It seems likely to me that the majority of Potlatch users will be Windows, so if our approach is to always develop for the lowest common denominator (Linux Flash), we're limiting ourselves quite a bit. Can the client detect the environment and thus gracefully fall back to better performance styles?

Also, with the "enhanced" style, is this:
a) better styles for environments with "enhanced" performance
b) more informative styles for users with "enhanced" skills
c) "enhanced" detail for users who want to see more?

These are different use cases.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 1.28pm, Friday, 28th January 2011]

Fixed in r25152-r25170.

@openstreetmap-trac
Copy link
Author

Author: BennieD
[Added to the original trac issue at 9.26pm, Saturday, 29th January 2011]

Replying to [comment:8 Richard]:

Fixed in r25152-r25170.
The arrows is great - Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant