-
Notifications
You must be signed in to change notification settings - Fork 665
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
The events/incidents in intersections #2547
Conversation
proto/trip.proto
Outdated
@@ -226,6 +226,30 @@ message TripLeg { | |||
optional float default_speed = 44; // km/h | |||
optional Restriction restriction = 45; | |||
optional bool destination_only = 46; | |||
|
|||
message Incident { |
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 know im a late comer here but if the incident is to happen at the node, shouldnt we put this on the node rather than nest it on the edge?
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.
or is the idea that since the incident will cover the whole edge (because we cut the edge wherever the incidents occur both at the beginning and end of the incident that we dont need to put it on the node? what if the incident isnt linear but is a point? how do we really understand the full spatial extent of the incident. i feel like we are missing just a little bit of structure 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.
Yep, node makes more sense, moving it there!
@@ -69,6 +69,7 @@ const std::string kEdgeTruckSpeed = "edge.truck_speed"; | |||
const std::string kEdgeTruckRoute = "edge.truck_route"; | |||
const std::string kEdgeDefaultSpeed = "edge.default_speed"; | |||
const std::string kEdgeDestinationOnly = "edge.destination_only"; | |||
const std::string kEdgeShowIncidents = "edge.show_incidents"; |
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 guess this will become node.incidents
?
src/odin/enhancedtrippath.cc
Outdated
@@ -1760,6 +1760,16 @@ std::string EnhancedTripLeg_Admin::ToString() const { | |||
|
|||
return str; | |||
} | |||
google::protobuf::RepeatedPtrField<valhalla::TripLeg_Node_Incident> empty; |
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.
Should this made const
since we're using it as one?
src/proto_conversions.cc
Outdated
std::string incident_type; | ||
switch (incident.type()) { | ||
case TripLeg_Node_Incident_Type_ACCIDENT: | ||
incident_type = "accident"; |
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.
Maybe we can avoid a copy by returning directly from the case
statements? (not sure if the compiler can do away with the string copy being created here, maybe it can?)
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 sure either. I'd assume the compiler could optimize it, but I can make it a direct return.
src/tyr/route_serializer_osrm.cc
Outdated
boost::get<std::shared_ptr<valhalla::baldr::json::Jarray>>(&existing->second)) { | ||
serialized_incidents = *ptr; | ||
} else { | ||
throw std::logic_error("This should not be possible"); |
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.
Can we put a bit more information into the error message? Like "could not get existing incidents" or some such.
src/tyr/route_serializer_osrm.cc
Outdated
} | ||
json::ArrayPtr serialized_incidents = std::shared_ptr<json::Jarray>(new json::Jarray()); | ||
for (const auto& incident : incidents) { | ||
{ |
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.
Whats the purpose of this additional scope?
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.
Keeping the local context small on the temporary variables used for bringing out any existing array in the json doc.
src/tyr/route_serializer_osrm.cc
Outdated
for (const auto& incident : incidents) { | ||
{ | ||
// Bring up any already existing array | ||
auto existing = doc.find("incidents"); |
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 don't need this inside the loop, 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.
Correct, I thought I moved this out in a previous version of the code. Anyway, moving out of the loop.
src/proto_conversions.cc
Outdated
return "weather"; | ||
break; | ||
}; | ||
return "Unhandled case"; |
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.
throw?
src/tyr/route_serializer_osrm.cc
Outdated
|
||
{ | ||
uint64_t id = static_cast<uint32_t>(incident.id()); | ||
metadata_json->emplace("id", id); |
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.
why not cast inline like the others below?
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 had a really long, opaque compiler error which didn't resolve until I did this. In hindsight, it seemed like the json document wouldn't allow both uint64 and uint32 inside.
With the increase of id
to 64bits, this entire cast goes away.
proto/trip.proto
Outdated
optional uint64 start_time = 3; // START_TIME as seconds since epoch UTC | ||
optional uint64 end_time = 4; // END_TIME seconds since epoch UTC | ||
optional uint64 creation_time = 5; // time the incident was created/updated in seconds since epoch UTC | ||
optional uint32 id = 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.
we might want to make the id some sort of a unique-ish information carrier for the important bits of the incident:
incident_id {
uint64_t start_lon: 26; //int(lon * 100000)
uint64_t start_lat : 26; //int(lat * 100000)
uint64_t type: 4;
uint64_t time: 8; //epoch second modulo 255
}
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 like this idea. I'll implement this in the follow-on PR where the real incident data is implemented.
to be able to decide if type is set or not
Issue
What issue is this PR targeting? If there is no issue that addresses the problem, please open a corresponding issue and link it here.
Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?