Test "Way end node near other way" is too aggressive for railroads

[tomasmarklund]

Railroads have often parallell ways ending with short distances from each other (~5 m) without this being wrong in any way. However, the validation at upload always gives warning for these which the user needs to accept.

It would be easier to respect the warning, if there were no "false" warnings like these.

[tomasmarklund]

Screenshot of railway tracks which give validator warning

[skyper]

Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.

Please add all needed information according to this list:

• The required parts of the Status Report from your JOSM.
  • Please, use Report Bug from Help menu and copy & paste.
• Describe what behaviour you expected.
• Describe what did happen instead.
• Describe if and how the issue is reproducible.
• Add any relevant information like error messages or screenshots.

To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Help → Report Bug.

Remember: This is a generic notice so we don't need to write the same stuff again and again. It may only apply in parts to the specific case!

---

Usually, a noexit=yes will silence this warning but this tag is not supposed to be used with railway=*. Do not completely understand why.
Take a look advanced preferences validator.UnconnectedWays.node_way_distance.

[GerdP]

The test also looks for railway=buffer_stop on the end node, but some mappers place such a node a few cm before the end of the rail.

[tomasmarklund]

Sorry for bad bug report, here's an update.

*Railway tracks do not always have buffer stops, often they just.. end.
*Buffer stops are not always mounted at the end of the track, sometimes 10 m from the end of the track (so called "sliding buffer stops")

What steps will reproduce the problem?

1. Create two railway tracks which end a "normal" railway distance to each other, 5-10 m
2. Run validator (either manually, or when uploading)

What is the expected result?

No warning for proximity to other wailway tracks when running validator (or uploading, with auto-validator)

What happens instead?

Validator warning for "Way end node near other way"

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

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-06-02 22:03:39 +0200 (Wed, 02 Jun 2021)
Build-Date:2021-06-02 20:11:30
Revision:17919
Relative:URL: ^/trunk

Identification: JOSM/1.5 (17919 sv) Windows 10 64-Bit
OS Build number: Windows 10 Home 2004 (19041)
Memory Usage: 743 MB / 910 MB (228 MB allocated, but free)
Java version: 1.8.0_291-b10, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 2560×1440 (scaling 1.00×1.00) \Display1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 2560×1440
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: sv_SE
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djava.security.manager, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlp.tk=awt, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.splashport=49177, -Djnlpx.home=<java.home>\bin, -Djnlpx.remove=false, -Djnlpx.offline=false, -Djnlpx.relaunch=true, -Djnlpx.session.data=%UserProfile%\AppData\Local\Temp\session9039261492510108189, -Djnlpx.heapsize=NULL,NULL, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-39974266]
Dataset consistency test: No problems found

Plugins:
+ FastDraw (35640)
+ SeaMapEditor (35543)
+ apache-commons (35524)
+ areaselector (368)
+ austriaaddresshelper (1597341117)
+ buildings_tools (35756)
+ continuosDownload (91)
+ editgpx (35562)
+ ejml (35458)
+ geotools (35458)
+ jaxb (35543)
+ jts (35458)
+ log4j (35458)
+ measurement (35640)
+ opendata (35640)
+ reverter (35732)
+ utilsplugin2 (35691)

Tagging presets:
+ https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/SE.zip
+ https://raw.githubusercontent.com/OpenNauticalChart/josm/master/INT-1-preset.xml

Map paint styles:
+ https://raw.githubusercontent.com/OpenSeaMap/josm/master/INT1_Seamark.mapcss

Last errors/warnings:
- 00266.441 W: Unable to find supported projection for layer Lantmäteriet ortofoto. Using EPSG:3857.
- 00266.443 W: Unable to find supported projection for layer Lantmäteriet ortofoto. Using EPSG:3857.

[tomasmarklund]

Validator report when uploading (with JOSM in swedish)

[GerdP]

I don't know what to do here. We can either remove railways from this test or add a new preference like validator.UnconnectedWays.node_way_distance_railway which would overwrite the general validator.UnconnectedWays.node_way_distance when railways are tested if that really helps.

[skyper]

How to find two unconnected railways with a small gap in between, then?

Personally, I would like the use of noexit=yes on these end nodes but this tag is disputed with railway.

[GerdP]

How to find two unconnected railways with a small gap in between, then?

Right, the better value is the hard coded FACTOR=4 for the allowed detour. With railways we probably have to use a larger value.

[anonymous]

I'd say a typical ok distance would be ~4.5 to 5 m for railways. If the distance between unconnected railway nodes is..

• less than 4 m ==> warning.
• more then 4 m ==> no warning

A new preference value that can be fine tuned is of course better than a hard coded value.

With a value of 4 m, the validator would find most (I guess) nodes that are unconnected by mistake. A normal distance, at least in Sweden, for double track railways is 4.5-5 m, so I think distances less than 4 m would be an ok "validator warning distance".

Edit: Sorry; I wasn't logged in when I wrote my comment tomasmarklund

[GerdP]

OK, so you just want to set a smaller value for railways and keep the default 10.0 m for others? In that case the validator.UnconnectedWays.node_way_distance_railway preference would be an easy solution.

[tomasmarklund]

Replying to GerdP:

OK, so you just want to set a smaller value for railways and keep the default 10.0 m for others? In that case the validator.UnconnectedWays.node_way_distance_railway preference would be an easy solution.

I think that would solve the problem in a very efficient way, yes.

The general problem is that railway tracks in reality DO end in closer proximity to each other than "other" roads/paths/cycleways etc, without this being "wrong". A smaller value for railways would probably solve most of the "false warnings".

[GerdP]

Please try it by setting the preference validator.UnconnectedWays.node_way_distance to 4.

[tomasmarklund]

Works excellent!

Which means a dedicated railway preference validator.UnconnectedWays.node_way_distance_railway should work too.

[GerdP]

I tested this with an overpass download railway=* in Germany which returned ~200.000 nodes and ~28.000 ways. With the default dist (10.0 m) I see 2467 warnings, with 4.0 m I still see 644. So, this is not really fixing the problem.
I also tried a larger detour factor (10 times higher) but this doesn't solve the problem with side tracks.
Some observations:

• I think railway=disused should be treated like railway=abandoned. I see several false positives for nodes connecting a railway=abandoned with a railway=disused. This is a very simple change and reduces the warnings to 1682 with default dist 10.0 m.
• I'll try to add code to stop complaining about unconnected end nodes if the next node is a railway=buffer_stop.

If this test is meant to only find gaps it should work in a different way, e.g. testing the angle/direction.

[tomasmarklund]

I did a similar test for Sweden. Downloaded ways railway=* which returned ~33.000 ways and ~359.000 nodes (would have suspected there were more in Germany than Sweden though)

By setting preference validator.UnconnectedWays.node_way_distance to 4 I see 525 warnings "end node close to other way"
By setting preference validator.UnconnectedWays.node_way_distance to (default) 10 I see 3528 warnings "end node close to other way"

So I'd say that even if it's not perfect, it is still better then 10 for railways.

Setting the value down to 3 I got only 194, so tweaking the value furter could find a reasonable amount of warnings. When I suggested 4 earlier, that was because of my experience of railways IRL, I had not made these "large amount of data research" then.

Reducing the false warnings to 5-10% I'd still say is a lot better than nothing! Mostly when editing, I don't people download 30.000 ways, they edit a smaller area, and then the 5% false (maybe) warnings is not more than they can be manually checked at least. I would call this a big improvement.

[GerdP]

I tested a bbox within Germany, maybe 220 x 160km. So far I found only very few correct warnings, all of them about proposed railways.
I wonder if this test is of any use when nearly all messages are false positives.

[tomasmarklund]

Deleting the test entirely would of course remove 100% of the false warnings, but also a few % of the true warnings.

How about this:

• add validator.UnconnectedWays.node_way_distance_railway preference, set default value to something very small like 1 m or 0.5. If an end node is closer than 1 m (or 0.5) to another railway, there probably IS something strange, worth looking at.
• exclude the railway=proposed from this test, since proposed railways criss-cross the landscape and other railways without ever being connected to "real" railways.
• maybe also exclude railway=construction.

[GerdP]

proposed railways criss-cross the landscape and other railways without ever being connected to "real" railways.

I wondered if this is wanted or not. With highways it was decided that proposed, planned, or construction ways should be connected to existing roads, at least Klumbusbus and I think so.

[tomasmarklund]

In any case, a proposed or planned railway is not a railway in the real world (yet), they are maybe nothing more than a line on a map. This is why I don't think it is absolutely wrong that they stay unconnected, criss-crossing the landscape. But of course, that is only my personal opinion.

At least I would not be happier if a proposed railway crossed a highway with a common node, and the validator said "missing level crossing" every time, for a crossing that doesn't even exist in the real world.

A railway=construction however, IS something in the real world, not only a line on a map. Because of this, they very well could (should) be connected to other railway-ways and highways. This I agree on.

[GerdP]

The patch implements

• new preference validator.UnconnectedWays.node_way_distance_railway with a default dist of 1.0 m
• additional check if end node is next to a buffer_stop
• improved include/exclude lists to ignore railway planned or proposed and some objects which are buildings.

I'd prefer to have a positive list of tag values for ways with railways=* which should be connected. I found only rail,tram,narrow_gauge,subway,turntable,traverser
Are there more?

[skyper]

funicular, miniature, monorail and I am not sure about preserved, roundhouse and wash.

[skyper]

platform_edge needs to be exclude or even tested the opposite way, e.g. needs to end near a railway track.

[GerdP]

The patch treats platform_edge like platform.

[skyper]

#7120 can probably be (marked as) fixed along side this ticket.

[Don-vip]

Milestone renamed

[GerdP]

In 18272/josm:

fix #21038: Test "Way end node near other way" is too aggressive for railroads

• new preference validator.UnconnectedWays.node_way_distance_railway with a default dist of 1.0 m
• additional check if end node is next to a buffer_stop
• improved include/exclude lists to ignore planned or proposed railway and some objects which are buildings.

[skyper]

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