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
add shape to matrix response #4432
Conversation
…elf doesn't segfault
…ansion with deadend logic; still could/should be based on max cost of (which?) adjacency set
valhalla/midgard/util.h
Outdated
@@ -15,6 +15,7 @@ | |||
#include <utility> | |||
#include <vector> | |||
|
|||
#include <valhalla/baldr/json.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not a good idea. it works for now because json.h is header only so you dont have to link the bit of the library that is baldr but id really really rather not mix baldr into midgard.
anyway i think you dont need this? nothing is using it here anyway right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, must be a relict from before. I moved the function which needed it to tyr/serializers.h
@@ -126,6 +126,7 @@ inline void reserve_pbf_arrays(valhalla::Matrix& matrix, size_t size) { | |||
matrix.mutable_distances()->Resize(size, 0U); | |||
matrix.mutable_times()->Resize(size, 0U); | |||
matrix.mutable_date_times()->Reserve(size); | |||
matrix.mutable_shapes()->Reserve(size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call!
src/tyr/serializers.cc
Outdated
baldr::json::array({baldr::json::fixed_t{p.lng(), 6}, baldr::json::fixed_t{p.lat(), 6}})); | ||
} | ||
geojson->emplace("type", std::string("LineString")); | ||
geojson->emplace("coordinates", std::move(coords)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its all shared pointers so move
isnt really needed, just an fyi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, I'll change that then
some tiny things to change otherwise looks done |
Co-authored-by: Kevin Kreiser <kevinkreiser@gmail.com>
89ec5a8
to
7580c8d
Compare
oops done |
merge master and update changelog yet |
src/worker.cc
Outdated
@@ -806,10 +806,17 @@ void from_json(rapidjson::Document& doc, Options::Action action, Api& api) { | |||
options.set_shape_format(polyline5); | |||
} else if (*shape_format == "geojson") { | |||
options.set_shape_format(geojson); | |||
} else if (*shape_format == "none") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh i didnt notice this in the json api it is still called none
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm that was the case since the beginning. but you're right, it's unintuitive to have them differ in PBF/JSON formats, I'll change it
if (action == Options::height) { | ||
throw valhalla_exception_t{164}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its not clear to me why we need this. the height action will never look at options.shape_format()
right? i think we shouldnt throw errors for superfluous parameters. or what am i missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the height action will never look at options.shape_format() right?
yes it does actually, to return either polyline5 or 6. in fact it's the only documented use of shape_format
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not to return though right! its the input format in that case hahaha, i had forgotten about that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably have to block this then for mapmatching too right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i should also say i didnt check this but we should have a look quick while we are here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 839 to 852 in 253443e
// parse map matching location input and encoded_polyline for height actions | |
auto encoded_polyline = rapidjson::get_optional<std::string>(doc, "/encoded_polyline"); | |
if (encoded_polyline) { | |
options.set_encoded_polyline(*encoded_polyline); | |
} | |
if (options.has_encoded_polyline_case()) { | |
// Set the precision to use when decoding the polyline. For height actions (only) | |
// either polyline6 (default) or polyline5 are supported. All other actions only | |
// support polyline6 inputs at this time. | |
double precision = 1e-6; | |
if (options.action() == Options::height) { | |
precision = options.shape_format() == valhalla::polyline5 ? 1e-5 : 1e-6; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like mapmatching forces to polyline6. kind of dumb, we should allow it but its a problem for another day
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for height as input, right.. for map matching not relevant, it's hard-coded to polyline6 it seems in worker.cc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3 small things then merge:
- changelog entry at bottom of list
- merge master into branch
- check if we can remove height action error response
last things done, sorry for the hassle.. |
hmpf.. tidy again and a test was broken after the recent changes.. I also remembered I'd like to add a warning when TDMatrix is used but shape_format was requested. since the approve is dismissed anyways, I'll add now. don't hurry with this really, let's take it on monday real quick. |
fixes #4300
based on #4372
implements a new
shape_format
request field for/sources_to_targets
with all available formats (polyline5/6, geojson and by default"none"
), but only for CostMatrix.shape_format
will dictate what theshape
response field contains, if not"none"
in which case there is noshape
response field.note: trivial routes have a bug in master (and the PR this is based on), where it finds the connection on the wrong directed edge, consistently. I guess this went unnoticed for so long because it hardly matters for the matrix. the distance will always be the same, thought the duration can of course vary. I'll band-aid that for now.