Modify

Opened 3 years ago

Last modified 3 years ago

#18488 new enhancement

Lane count validation

Reported by: gaben Owned by: team
Priority: normal Milestone:
Component: Core validator Version: latest
Keywords: lanes lanes-tagging Cc: imagic

Description (last modified by gaben)

The current lane validation rule only warns if the lanes < lanes:forward+lanes:backward values.
I think a not equal rule would be more useful.

What steps will reproduce the problem?

  1. Tag a way with eg. lanes=3 lanes:forward=1 lanes:backward=1
  2. Run the validator

What is the expected result?

A warning informs the user that the values don't match

What happens instead?

Nothing

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-12-29 22:32:02 +0100 (Sun, 29 Dec 2019)
Revision:15624
Build-Date:2019-12-30 02:30:57
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15624 hu) Linux Debian GNU/Linux 10 (buster)
Memory Usage: 321 MB / 1990 MB (81 MB allocated, but free)
Java version: 11.0.5+10-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Screen: :0.0 1912x1020
Maximum Screen Size: 1912x1020
Java package: openjdk-11-jre:amd64-11.0.5+10-1~deb10u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-22
fonts-noto: fonts-noto:all-20181227-1
Dataset consistency test: No problems found

Plugins:
+ tageditor (35258)
+ turnlanes-tagging (283)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

Attachments (0)

Change History (9)

comment:1 Changed 3 years ago by gaben

Description: modified (diff)

comment:2 Changed 3 years ago by Don-vip

Keywords: lanes added

comment:3 Changed 3 years ago by Don-vip

related to #16395

comment:4 Changed 3 years ago by gaben

After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

comment:5 in reply to:  4 ; Changed 3 years ago by skyper

Replying to gaben:

After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I think you do mix up "access" and "lanes".

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

comment:6 in reply to:  5 ; Changed 3 years ago by gaben

Replying to skyper:

I think you do mix up "access" and "lanes".

Why do you think that? 😀

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

Just looked up the wiki (https://wiki.openstreetmap.org/wiki/Key:lanes) and there is an example, where it says the
lanes=3
lanes:forward=1
lanes:backward=1
is a valid combination. I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

Version 0, edited 3 years ago by gaben (next)

comment:7 in reply to:  6 ; Changed 3 years ago by skyper

Cc: imagic added

Replying to gaben:

Replying to skyper:
After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I think you do mix up "access" and "lanes".

Why do you think that? 😀

Sorry, was a wild guess as you leave out path, foot- and cycleway.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

Just looked up the wiki (osmwiki:Key:lanes#Examples) and there is an example, where it says the
lanes=3
lanes:forward=1
lanes:backward=1
is a valid combination.

You forgot the "in some countries" but sadly the countries are not mentioned.

I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

+1, so a discussion on tagging@ ?

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

Dough, auto-fixing is really dangerous, as the tool does not know where the error/mistake was made or if there is a tag missing.

comment:8 in reply to:  7 Changed 3 years ago by gaben

Replying to skyper:

I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

+1, so a discussion on tagging@ ?

Can you please do it?

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

Dough, auto-fixing is really dangerous, as the tool does not know where the error/mistake was made or if there is a tag missing.

It's not harmful and it does only one object at a time. Try it out :)

comment:9 Changed 3 years ago by skyper

Keywords: lanes-tagging added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to gaben
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.