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

The events/incidents in intersections #2547

Merged
merged 20 commits into from
Aug 25, 2020
Merged

Conversation

purew
Copy link
Contributor

@purew purew commented Aug 20, 2020

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

  • Add tests
  • Add #fixes with the issue number that this PR addresses
  • Generally use squash merge to rebase and clean comments before merging
  • Update the changelog

Requirements / Relations

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

@purew purew requested a review from danpaz August 20, 2020 14:05
src/thor/triplegbuilder.cc Outdated Show resolved Hide resolved
@purew purew added this to the Sprint 17 - Left Turn milestone Aug 20, 2020
@purew purew self-assigned this Aug 20, 2020
danpaz
danpaz previously approved these changes Aug 21, 2020
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 {
Copy link
Member

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?

Copy link
Member

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

Copy link
Contributor Author

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";
Copy link
Collaborator

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?

@@ -1760,6 +1760,16 @@ std::string EnhancedTripLeg_Admin::ToString() const {

return str;
}
google::protobuf::RepeatedPtrField<valhalla::TripLeg_Node_Incident> empty;
Copy link
Contributor

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?

std::string incident_type;
switch (incident.type()) {
case TripLeg_Node_Incident_Type_ACCIDENT:
incident_type = "accident";
Copy link
Contributor

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?)

Copy link
Contributor Author

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.

boost::get<std::shared_ptr<valhalla::baldr::json::Jarray>>(&existing->second)) {
serialized_incidents = *ptr;
} else {
throw std::logic_error("This should not be possible");
Copy link
Contributor

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.

}
json::ArrayPtr serialized_incidents = std::shared_ptr<json::Jarray>(new json::Jarray());
for (const auto& incident : incidents) {
{
Copy link
Contributor

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?

Copy link
Contributor Author

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.

for (const auto& incident : incidents) {
{
// Bring up any already existing array
auto existing = doc.find("incidents");
Copy link
Contributor

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?

Copy link
Contributor Author

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.

danpaz
danpaz previously approved these changes Aug 25, 2020
return "weather";
break;
};
return "Unhandled case";
Copy link
Member

Choose a reason for hiding this comment

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

throw?


{
uint64_t id = static_cast<uint32_t>(incident.id());
metadata_json->emplace("id", id);
Copy link
Member

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?

Copy link
Contributor Author

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;
Copy link
Member

@kevinkreiser kevinkreiser Aug 25, 2020

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
}

Copy link
Contributor Author

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.

kevinkreiser
kevinkreiser previously approved these changes Aug 25, 2020
to be able to decide if type is set or not
@purew purew merged commit 791cc24 into master Aug 25, 2020
@purew purew deleted the anders-incidents-in-intersections branch August 25, 2020 16:06
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.

None yet

4 participants