pt_assistant crashes when using validator on certain bus routes

[max.walder@…]

What steps will reproduce the problem?

1. download a bus route where some platforms are mapped as ways (such as ​https://www.openstreetmap.org/relation/405996 ) and all relation members
2. run validator

What is the expected result?

The validator should run without throwing an exception and the validation results should be displayed.

What happens instead?

An Exception is thrown, no pt_assistant validation results are shown.

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

By doing some basic testing I noticed that the error seems to only occur when a platform is mapped as a way, not on routes without those platform ways.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-06-02 08:27:29 +0200 (Tue, 02 Jun 2020)
Build-Date:2020-06-02 11:11:35
Revision:16538
Relative:URL: ^/trunk

Identification: JOSM/1.5 (16538 en) Windows 10 64-Bit
OS Build number: Windows 10 Education 2004 (19041)
Memory Usage: 1476 MB / 3630 MB (470 MB allocated, but free)
Java version: 1.8.0_251-b08, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920x1080, \Display1 1280x1024
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ CustomizePublicTransportStop (35248)
+ pt_assistant (2.1.10-80-g7d9bba3)

Validator rules:
+ https://github.com/Jungle-Bus/transport_mapcss/raw/gh-pages/transport.validator.zip

Last errors/warnings:
- E: Handled by bug report queue: java.lang.NullPointerException
- E: Handled by bug report queue: java.lang.NullPointerException
- E: Handled by bug report queue: java.lang.NullPointerException
- E: Handled by bug report queue: java.lang.NullPointerException
- E: Handled by bug report queue: java.lang.NullPointerException


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-0 (27) of main
java.lang.NullPointerException
	at org.openstreetmap.josm.plugins.pt_assistant.utils.StopToWayAssigner.get(StopToWayAssigner.java:115)
	at org.openstreetmap.josm.plugins.pt_assistant.validation.SegmentChecker.performStopNotServedTest(SegmentChecker.java:246)
	at org.openstreetmap.josm.plugins.pt_assistant.validation.PTAssistantValidatorTest.proceedWithSorting(PTAssistantValidatorTest.java:364)
	at org.openstreetmap.josm.plugins.pt_assistant.validation.PTAssistantValidatorTest.visit(PTAssistantValidatorTest.java:161)
	at org.openstreetmap.josm.data.osm.Relation.accept(Relation.java:176)
	at org.openstreetmap.josm.data.validation.Test.visit(Test.java:216)
	at org.openstreetmap.josm.actions.ValidateAction$ValidationTask.realRun(ValidateAction.java:169)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:94)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:142)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

[taylor.smock]

I haven't been able to reproduce.

Looking at the ​code, it is likely getBBox returned null (since stop.getPlatform() != null is checked previously). Which is interesting, since a Way has been unable to return a null bbox since at least 2009.

[taylor.smock]

I've done a deeper dive into this problem, and I think the crash is "fixed" (see ​ecd4671f9beb24861808c776344ea4d71c0ec40d).

Analysis:
In context of comment:2, since I found it unlikely for a null bbox to be returned, it is likely that potentialStopPosition.getCoor() returned null, and then the method call to .distanceSq caused the NPE. Which is definitely possible (Node#getCoor will return null if Node#isLatLonKnown returns false).

In that case, Node#lon and/or Node#lat will return Double.NaN, which will could mess up the closestStopPosition, depending upon NaN semantics. On Mac OS X with Java 11, the min call should not be an issue with Comparator.comparingDouble. I tested with jshell DoubleStream.of(0, Double.NaN, -1, 1, Double.MAX_VALUE, Double.MIN_VALUE).boxed().min(Comparator.comparingDouble(b -> b.doubleValue())). Using max` did cause a problem.