Journey planner often gives unexpected, and usually unnecessary, disambiguation requestes,
For example:
Unsurprisingly, the API gives the same disambiguation request,
"place": {
"$type": "Tfl.Api.Presentation.Entities.StopPoint, Tfl.Api.Presentation.Entities",
"naptanId": "940GZZLUEFY",
"modes": [
"tube",
"bus",
"replacement-bus"
],
"icsCode": "1000067",
"stopType": "stop",
"url": "/StopPoint/940GZZLUEFY",
"commonName": "East Finchley, East Finchley Station",
"placeType": "StopPoint",
"additionalProperties": [],
"lat": 51.58737274427,
"lon": -0.16503096278999999
},
"matchQuality": 1000
I’m guessing that matchQuality gives a clue to why it is asking for disambiguation. But is matchQuality documented anywhere? And does it really need disambiguation, considering that there is only one match and it contains all the words from the question, consecutively and in the same order?
Conversely, try a journey to East Road, Enfield – a place which openstreetmap has no difficulty finding – it’s at Way: East Road (96143367) | OpenStreetMap
But Journey planner seems to think East Road, Enfield matches Cranfield Road East, Sutton (London) and matches it so well that it doesn’t even offer a disambiguation request, just goes ahead and plans a journey to somewhere that would be most confusing to a visitor who didn’t understand it was clearly wrong:
Somehow, I think the journey planner has got its criteria for disambiguation completely wrong.