Modify

Opened 2 years ago

Last modified 5 weeks ago

#21966 new enhancement

[Patch] Allow cardinal directions as roles in road routes

Reported by: ZLima12 Owned by: team
Priority: minor Milestone:
Component: Internal preset Version:
Keywords: road route relation role Cc: aighes

Description

Attachments (0)

Change History (9)

comment:1 by ZLima12, 2 years ago

Keywords: road route relation preset added

comment:2 by skyper, 2 years ago

Component: unspecifiedInternal preset
Keywords: role added; preset removed
Summary: Allow cardinal directions as roles in road routes[Patch] Allow cardinal directions as roles in road routes
Version: tested

These roles are only for route=road relations and should not be mixed with e.g. forward/backward, am I right?

I'd prefer an own preset for these route relations and similar to #20731 we should add validator rules to warn about a mix of both concepts within a relation.

comment:3 by 1ec5, 2 years ago

Cardinal direction roles are incompatible with forward/backward roles. Every route relation that currently has a forward or backward role for one of its members would eventually need to be refactored into two subrelations, one for each direction, in order to communicate the cardinal direction to a router. (Routers use the cardinal direction in guidance instructions because they’re so important for navigation in the countries that use them.)

How would the preset work? The cardinal direction roles aren’t the preferred roles for any network in particular. They‘re only a crude first pass, compared to PTv2-style subrelations, that are acceptable because less experienced mappers would find it difficult to perform that refactoring every time they encounter a short dual carriageway along an otherwise single-carriageway route.

comment:4 by ZLima12, 2 years ago

Just ran a homemade script on every road route that has a network beginning with US: (47246 of them). Was looking for statistics on how they were mapped in the US: for member roles, do people use forward/backward more, or north/south/east/west more? Here's the results:

  • All members have empty role: 37870
  • forward/backward`: 6176
  • north/south/east/west: 1673
  • Mixed between forward/backward and north/south/east/west: 923
  • All relations (presumably superroute): 311
  • >=1 member has a role different from those mentioned: 291
  • Everything else (invalid, probably): 2

comment:5 by ZLima12, 2 years ago

Those 923 mixed relations should rightfully have a warning issued by JOSM.

comment:6 by skyper, 16 months ago

Ticket #22602 has been marked as a duplicate of this ticket.

comment:7 by skyper, 16 months ago

Cc: aighes added

comment:8 by aighes, 5 weeks ago

Is there any plan to add the mentioned 4 additional allowed values?

in reply to:  5 comment:9 by 1ec5, 5 weeks ago

Replying to ZLima12:

Those 923 mixed relations should rightfully have a warning issued by JOSM.

I agree. One of the downsides of the cardinal direction roles is that, in principle, any usage of forward or backward required for topological reasons also needs a cardinal direction at the same time. The idea to combine these roles in a semicolon-delimited list never took off.

In my largely iD-based mapping, I do add cardinal direction roles to routes that only had forward/backward roles to begin with, if anything. To me, adding a cardinal direction role is better than nothing, as it adds some value that a router can use. But in my opinion, it’s just a placeholder for someone else to restructure the relation with a superrelation, since iD doesn’t have a function for duplicating a relation like JOSM does. The warning should be worded to encourage mappers to perform that refactoring, rather than thinking they need to simply remove the role as invalid.

All relations (presumably superroute): 311

By the way, these are mostly type=route superrelations rather than type=superroute. Both the role-based and superrelation-based approaches are documented on the wiki.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to ZLima12.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.