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

Fix annotations=true handling in NodeJS bindings & libosrm #6415

Merged
merged 7 commits into from
Oct 19, 2022

Conversation

SiarheiFedartsou
Copy link
Member

@SiarheiFedartsou SiarheiFedartsou commented Oct 18, 2022

Issue

Found this problem while working on #6411 (it was actually caught by one of our tests when I started running them against NodeJS based server - one more reason to rewrite osrm-router in NodeJs :) ).

Now it works the same as in osrm-routed:

Or in constructors of RouteParameters:

annotations{annotations_ != AnnotationsType::None}, annotations_type{annotations_},

Tasklist

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

assert.ok(first.routes[0].legs.every(l => { return l.annotation.nodes;}), 'every leg has annotations for nodes');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.weight; }), 'every leg has annotations for weight');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.datasources; }), 'every leg has annotations for datasources');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.speed; }), 'every leg has annotations for speed');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw problem was happening only for speed, because we have these checks here which it seems were added for backward compatibility, but I am not sure if we should use parameters.annotations_type(but not requested_annotations) when checking if speed annotations were requested.

requested_annotations = RouteParameters::AnnotationsType::All;

Screenshot 2022-10-18 at 18 35 51

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but I am not sure if we should use parameters.annotations_type(but not requested_annotations) when checking if speed annotations were requested.

It looks as a bug, because it is different from other annotations, so I changed it to use requested_annotations

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, looks like it.

@@ -845,6 +848,9 @@ inline bool parseCommonParameters(const v8::Local<v8::Object> &obj, ParamType &p
Nan::ThrowError("this 'annotations' param is not supported");
return false;
}

params->annotations =
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this annotations boolean field completely, but it seems it would break libosrm backward compatibility

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should think about all the breaking changes we would make for a v6 release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, it's already there: #3644

@SiarheiFedartsou SiarheiFedartsou changed the title Fix annotations=true handling in NodeJS bindings Fix annotations=true handling in NodeJS bindings & libosrm Oct 18, 2022
@@ -439,7 +439,7 @@ class RouteAPI : public BaseAPI
{
// AnnotationsType uses bit flags, & operator checks if a property is set
flatbuffers::Offset<flatbuffers::Vector<float>> speed;
if (parameters.annotations_type & RouteParameters::AnnotationsType::Speed)
if (requested_annotations & RouteParameters::AnnotationsType::Speed)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can leave it "as is" and NodeJs tests will still pass, but this seems to fix the problem for libosrm(when annotations = true was used).

See:
https://github.com/Project-OSRM/osrm-backend/pull/6415/files#r998472037

@SiarheiFedartsou SiarheiFedartsou marked this pull request as ready for review October 18, 2022 16:51
@SiarheiFedartsou
Copy link
Member Author

Fix for CI issues #6416

assert.ok(first.routes[0].legs.every(l => { return l.annotation.nodes;}), 'every leg has annotations for nodes');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.weight; }), 'every leg has annotations for weight');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.datasources; }), 'every leg has annotations for datasources');
assert.ok(first.routes[0].legs.every(l => { return l.annotation.speed; }), 'every leg has annotations for speed');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, looks like it.

@@ -845,6 +848,9 @@ inline bool parseCommonParameters(const v8::Local<v8::Object> &obj, ParamType &p
Nan::ThrowError("this 'annotations' param is not supported");
return false;
}

params->annotations =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should think about all the breaking changes we would make for a v6 release.

@SiarheiFedartsou SiarheiFedartsou merged commit fb1bb7a into master Oct 19, 2022
mattwigway pushed a commit to mattwigway/osrm-backend that referenced this pull request Jul 20, 2023
@DennisOSRM DennisOSRM deleted the sf-fix-annotations-node branch May 3, 2024 12:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants