Add basic controls for the routing helper reimplementation #25
Conversation
| public class RoutingHelperAction extends AbstractRelationEditorAction { | ||
| private static final Set<ITransportMode> TRANSPORT_MODES = Collections.singleton(new BusTransportMode()); |
There was a problem hiding this comment.
There's now a set of transport modes (for now just bus, others could follow later). The transport mode handles everything specific to the transport mode, like determining if you are allowed to travel along a certain way.
The routing helper selects the appropriate mode for a relation and queries the transport mode when there is something specific to the transport mode.
...va/org/openstreetmap/josm/plugins/pt_assistant/actions/routinghelper/RoutingHelperPanel.java
Outdated
Show resolved
Hide resolved
...org/openstreetmap/josm/plugins/pt_assistant/actions/routinghelper/WayTraversalDirection.java
Outdated
Show resolved
Hide resolved
floscher
force-pushed
the
routing_helper
branch
from
f7ed720
to
468d79b
Compare
…f UI that doesn't do much yet
…ke forward/backward navigation work and show connectivity (very primitive check)
floscher
force-pushed
the
routing_helper
branch
from
468d79b
to
08c2706
Compare
…just shows an icon next to the relation ID
Extended the highways they are allowed to use. And tried to make sure turn restriction relations are processed correctly. This needs some unit tests... I also added a class for trolley buses. Did I do that correctly?
...g/openstreetmap/josm/plugins/pt_assistant/actions/routinghelper/TrolleyBusTransportMode.java
Outdated
Show resolved
Hide resolved
...va/org/openstreetmap/josm/plugins/pt_assistant/actions/routinghelper/HorseTransportMode.java
Outdated
Show resolved
Hide resolved
floscher
force-pushed
the
routing_helper
branch
from
1c2fd0d
to
e6e452d
Compare
floscher
force-pushed
the
routing_helper
branch
from
e6e452d
to
bc77476
Compare
I think the name fits better and also makes it easier to distinguish between the original routing helper and this new one.
…hough. Does it make sense to do this?
…tTransportMode, where it's not getting the referrers of the from Way. I do see those referrers in my variables list while single stepping though.
…sted for bus, mandatory "only_" still need to be added
…tTrue statements most likely means not all cases are tested. So this needs some more thought.
I added support for TRs which have a via way instead of a via node
| } | ||
|
|
||
| @Override | ||
| public boolean canTurn(@NotNull final Way from, @NotNull final Way via, @NotNull final Way to) { |
There was a problem hiding this comment.
You cannot check this that easily. Have a look at the specs: Via can be a list of multiple ways.
The problem with turn restrictions is, that you cannot step through the route easilly, because you never know if they are part of a via or not.
if have not seen any usages of canTurn. What is the use case of it?
There was a problem hiding this comment.
… and this is my suggestion to check turn restrictions:
- Inputs
** ``List routeAll previous ways traversed as list (more than we need, but they are for free) **PartOfWay next` The next way we want to add - Returns
** true iff turning into that way is not blocked by any turn relation. (=> Returns true even if we might traverse the next segment but would be blocked later by a no_*** relation) - Algorithm
** (Check for no_* restrictions)
** Let R be the set of relations for which these conditions are met
*** relation hasnextas member
*** role ofnextis 'to'
*** relation is a turn for the current transport mode with no_ type
** For each item r in R, do:
*** Check if r matches current state. If it does => return false;
** (check for only_* relations)
** Let last be the last way of ways.
** Let O be the set of relations with:
*** Relation is a only_* relation for the current transport type
*** last is afromorviamember of the relation.
*** If it is aviamember, the previous members need to match theroute
** If O is empty, return true (no only_candidates)
** If any relation in O hasnextas next way (=> the way afterlast, no matter if it was a via or to), return true
** In all other cases return false
To check if no_ turn relation matches*
- If the relation has via ways:
** Traverse theroutebackwards and check if it matches the via ways
** Now traverse back one more way and check for thefromway. - If the relation has via nodes:
** Check if the via node is the connecting node.
There was a problem hiding this comment.
When the routing helper/ route explorer arrives at a gap, it would continue until the next junction.
At the junction it needs to propose ways that are
- suitable for the mode of transport
- the mode of transport is allowed to turn onto
We are creating the building blocks that can be used later on, so it's to be expected that they are not used yet. But they will be.
Thanks for the suggested workflow. I'll try to implement it. It is a lot more complex than I had expected it would be. But maybe that was to be expected :-)
cc @sudhanshu2
Fixes #23 .