Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

journeys(): Walks have wrong distance #298

Open
dabund24 opened this issue Sep 14, 2023 · 4 comments
Open

journeys(): Walks have wrong distance #298

dabund24 opened this issue Sep 14, 2023 · 4 comments

Comments

@dabund24
Copy link
Contributor

dabund24 commented Sep 14, 2023

I've noticed that legs that are walks have an incorrect distance value. The value is generally about 500 meters greater than the one displayed in DB Navigator, but the offset unfortunately doesn't really seem follow a pattern. Here are some examples:

from to DB Navigator hafas-client difference
Berlin Hbf (tief) Berlin Hbf (S-Bahn) 80 500 420
Hamburg Hbf Hauptbahnhof Süd, Hamburg 243 666 423
Köln Messe/Deutz Köln Messe/Deutz Gl.11-12 59 615 556
München Hbf (tief) München Hbf 130 692 562

This problem seems to be there on a lot of/maybe all profiles (I haven't tried all). I noticed it with the db profile. Options like a different walking speed or transfer time don't affect this.

@derhuerst
Copy link
Member

(I looked into this using the DB profile.) It seems like, without opt.polylines (a.k.a. getPolyline), HAFAS returned wrong leg distances, presumably because they're just estimated or even a static fallback value.

With getPolyline: false:

{
	"type": "WALK",
	"dep": {
		"locX": 1,
		"dTimeS": "083100",
		"dTZOffset": 120,
		"type": "N"
	},
	"arr": {
		"locX": 3,
		"aTimeS": "084000",
		"aTZOffset": 120,
		"type": "N"
	},
	"gis": {
		"dist": 500,
		"durS": "000900",
		"dirGeo": 4,
		"ctx": "H|1|W$A=1@O=Berlin Hbf (tief)@L=8098160@a=128@$A=1@O=Berlin Hbf (S-Bahn)@L=8089021@a=128@$202309260831$202309260840$$$1$$$$$$|#VE#2#CF#100#CA#0#CM#0#SICT#0#AM#17#AM2#0#RT#8#",
		"gisPrvr": "H",
		"getDescr": true,
		"getPoly": true,
		"sumLDrawStyleX": 2,
		"resLDrawStyleX": 3,
		"prodX": 1
	},
	"resState": "N",
	"resRecommendation": "N"
}

With getPolyline: true:

{
	"type": "WALK",
	"dep": {
		"dInR": true,
		"dTZOffset": 120,
		"dTimeS": "083100",
		"locX": 17,
		"type": "N"
	},
	"arr": {
		"aOutR": true,
		"aTZOffset": 120,
		"aTimeS": "084000",
		"locX": 15,
		"type": "N"
	},
	"gis": {
		"ctx": "H|1|W$A=1@O=Berlin Hbf (tief)@L=8098160@a=128@$A=1@O=Berlin Hbf (S-Bahn)@L=8089021@a=128@$202309260831$202309260840$$$1$$$$$$|#VE#2#CF#100#CA#0#CM#0#SICT#0#AM#49#AM2#0#RT#7#",
		"dirGeo": 4,
		"dist": 80,
		"durS": "000900",
		"gisPrvr": "H",
		"poly": {
			"crdEncF": "??",
			"crdEncS": "NN",
			"crdEncYX": "q}q_IqbrpAfCmA",
			"crdEncZ": "??",
			"delta": true,
			"dim": 3,
			"ppLocRefL": [
				{"locX": 17, "ppIdx": 0},
				{"locX": 15, "ppIdx": 1}
			],
			"type": "WGS84"
		}
	},
	"icoX": 11,
	"resRecommendation": "N",
	"resState": "N"
}

@derhuerst
Copy link
Member

It seems like, without opt.polylines (a.k.a. getPolyline), HAFAS returns wrong leg distances […].

This doesn't seem to be the case with the VBB endpoint (and the parameters current VBB hafas-client profile, of course).

With getPolyline: false:

{
    "type": "WALK",
    "dep":
    {
        "locX": 1,
        "dTimeS": "083100",
        "dTimeFS":
        {
            "styleX": 0
        },
        "type": "N"
    },
    "arr":
    {
        "locX": 2,
        "aTimeS": "084000",
        "aTimeFS":
        {
            "styleX": 0
        },
        "type": "N"
    },
    "chg":
    {
        "txt": "Umstieg",
        "durS": "000900",
        "durFS":
        {
            "styleX": 1,
            "txt": "9 Min"
        }
    },
    "gis":
    {
        "dist": 67,
        "durS": "000900",
        "dirGeo": 10,
        "ctx": "H|1|W$A=1@O=S+U Berlin Hauptbahnhof (tief)@L=900003200@a=128@$A=1@O=S+U Berlin Hauptbahnhof@L=900003201@a=128@$202309260831$202309260840$$$1$$$$$$",
        "gisPrvr": "H",
        "getDescr": true,
        "getPoly": true,
        "sumLDrawStyleX": 2,
        "resLDrawStyleX": 3,
        "prodX": 6
    }
}

With getPolyline: true:

{
    "type": "WALK",
    "dep":
    {
        "locX": 1,
        "dTimeS": "083100",
        "dTimeFS":
        {
            "styleX": 0
        },
        "type": "N"
    },
    "arr":
    {
        "locX": 2,
        "aTimeS": "084000",
        "aTimeFS":
        {
            "styleX": 0
        },
        "type": "N"
    },
    "chg":
    {
        "txt": "Umstieg",
        "durS": "000900",
        "durFS":
        {
            "styleX": 1,
            "txt": "9 Min"
        }
    },
    "gis":
    {
        "dist": 67,
        "durS": "000900",
        "dirGeo": 10,
        "ctx": "H|1|W$A=1@O=S+U Berlin Hauptbahnhof (tief)@L=900003200@a=128@$A=1@O=S+U Berlin Hauptbahnhof@L=900003201@a=128@$202309260831$202309260840$$$1$$$$$$",
        "polyG":
        {
            "polyXL":
            [
                1
            ]
        },
        "gisPrvr": "H",
        "getDescr": true,
        "getPoly": true,
        "sumLDrawStyleX": 2,
        "resLDrawStyleX": 3,
        "prodX": 6
    }
}

@derhuerst
Copy link
Member

This problem seems to be there on a lot of/maybe all profiles (I haven't tried all).

Which ones did you witness the behaviour with?

@dabund24
Copy link
Contributor Author

It looks like I was a little bit too pessimistic about that issue after also having had stumbled across it with sbahn-muenchen and mobil-nrw. I've tested more profiles and vrn is another one with faulty distances. On the other hand, with bvg, oebb, nahsh and vmt Hafas returns distances properly.
Also, thanks for figuring out the workaround, it fixes the issue for every tested profile :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants