Suggestion needed regarding manually editing the per-section motion mode prediction

[xubowenhaoren]

Hello,

We are working on a project with sub-tasks to:

1. Collect ground truth data from pre-defined trips, similar to the MobilityNet study (slides, repo).
2. Optionally improve the motion prediction model that e-mission currently uses based.

For sub-task 2, we wish to add the feature to allow users to edit their motion modes directly in the e-mission app. A prototype below:

I understand that the original motion mode is stored in the server-side MongoDB. To make sub-task 2 work, we need to add the ability to update motion modes to MongoDB. I have the following questions:

1. Can you please point me to the right context where the e-mission-phone reads the motion mode data from MongoDB, once the server-side analysis is finished?
2. Can you suggest a way of achieving motion mode updates to MongoDB?

[shankari]

Hi @xubowenhaoren which version of the phone app UI are you using?
The current master branch supports including multiple user labels for each trip, storing them in mongodb and displaying them to the user. And it has been doing so since around a year. Please see video at
https://nextcloud.damajash.org/s/f2z28gK7e84WPWS
for an example

I've recently improved the structure to make it easier to add new labels. This should be trivial.
e-mission/e-mission-phone@5537278

Steps are:

• copy over www/json/trip_confirm.json.sample and edit as needed
• select the input types at the top of www/js/tripconfirm/trip-confirm-services.js
• make sure you have the correct buttons in www/templates/diary/list.html

Done!

[shankari]

On the server, the confirmed_trip object includes all user input labels (#476)

[shankari]

This actually makes me happy because it indicates that the labeling UX design was at least somewhat correct :)

[xubowenhaoren]

Thanks for the contexts! We actually wanted to do the "motion mode editing" on the section/segment level. I've also adjusted this issue title. But it looks like e-mission has a similar feature already, which will give us a good start.

which version of the phone app UI are you using?

I confirm that our branch currently has the mode & purpose dropdown. But I don't think it has the October commit. I will pull the update, start working on the actual implementation soon and update this issue accordingly.

[shankari]

@xubowenhaoren

We actually wanted to do the "motion mode editing" on the section/segment level.

That's fabulous! It's really hard to design an easy to use UI for that, so you might want to contribute your code back to e-mission when you have a chance.

For the record, you would continue to store the data on the server as manual/* objects but with the start and end time of the section. I haven't yet created a confirmed_section, similar to the confirmed_trip in #476 but maybe you can contribute that?

[shankari]

@xubowenhaoren while labeling sections is definitely useful, it assumes that the section segmentation is correct. That is not always the case, so you might want to allow users the ability to edit the section segmentation.

@asiripanich plans to implement editing of trip segmentation (#593).

If you do end up implementing section segmentation, I wonder if you could share that with @asiripanich?

[shankari]

There is a prior PR on section editing based on the incident reporting that you could experiment with (e-mission/e-mission-phone#308, e-mission/e-mission-phone#469)
Or maybe leaflet editor (https://github.com/Leaflet/Leaflet.Editable)

[xubowenhaoren]

@xubowenhaoren while labeling sections is definitely useful, it assumes that the section segmentation is correct. That is not always the case, so you might want to allow users the ability to edit the section segmentation.

@asiripanich plans to implement editing of trip segmentation (#593).

If you do end up implementing section segmentation, I wonder if you could share that with @asiripanich?

This project is on a very tight timeline (only 10 weeks!). Therefore we won't implement segmentation editing for now.

[xubowenhaoren]

Copying from issue #623:

We are working on a project with sub-tasks to improve the overall accessibility of the E-mission app UI. We've discovered that the Leaflet map cannot display the start & end location for each trip segment in an accessible manner. Since this is a very short 10-week project, we've decided to add the text display of the start & end location for each trip segment. A UI prototype below:

To display the start & end location information for each trip segment, we've added the following

in www/js/diary/services.js.points2Geojson():

      var start_place_name_res = {name: "dummy start place"};
      var end_place_name_res = {name: "dummy end place"};
      CommonGraph.getSectionDisplayName(startPoint.data.latitude, startPoint.data.longitude, start_place_name_res);
      CommonGraph.getSectionDisplayName(endPoint.data.latitude, endPoint.data.longitude, end_place_name_res);

        // missing properties are:
        "properties": {
          distances: distances,
          distance: distances.reduce(function (acc, val) {
            return acc + val;
          }, 0),
          duration: endPoint.data.ts - startPoint.data.ts,
          end_fmt_time: endMoment.format(),
          end_local_dt: moment2localdate(endMoment),
          end_ts: endPoint.data.ts,
          feature_type: "section",
          sensed_mode: "MotionTypes.UNPROCESSED", // TODO: pass this information to change-mode.js
          source: "unprocessed",
          speeds: speeds,
          start_fmt_time: startMoment.format(),
          start_local_dt: moment2localdate(startMoment),
          start_ts: startPoint.data.ts,
          times: times,
          trip_id: {$oid: tripAndSectionId},
          start_point_lat: startPoint.data.latitude,
          start_point_long: startPoint.data.longitude,
          end_point_lat: endPoint.data.latitude,
          end_point_long: endPoint.data.longitude,
          start_point_name: start_place_name_res,
          end_point_name: end_place_name_res
        }

in www/js/diary/detail.js:

  $scope.formattedSectionProperties = $scope.tripgj.sections.map(function(s) {
    return {"fmt_time": DiaryHelper.getLocalTimeString(s.properties.start_local_dt),
            "fmt_end_time": DiaryHelper.getLocalTimeString(s.properties.end_local_dt),
            "fmt_start_place": s.properties.start_point_name.name,
            "fmt_end_place": s.properties.end_point_name.name,
            "fmt_time_range": DiaryHelper.getFormattedTimeRange(s.properties.end_ts, s.properties.start_ts),
            "fmt_distance": DiaryHelper.getFormattedDistance(s.properties.distance),
            "sensed_mode": s.properties.sensed_mode,
            "icon": DiaryHelper.getIcon(s.properties.sensed_mode),
            "colorStyle": {color: DiaryHelper.getColor(s.properties.sensed_mode)}
            };
  });

These additions work pretty well with the unprocessed trips. However, we noticed that the UI was broken after the trips are segmented. After checking the e-mission-server code, we discovered that the section.py wrapper only wraps formatted information in the original E-mission UI. Hence my question is:

1. What are the necessary changes to add to the e-mission server to add/preserve the start & end location for each trip segment?
2. Given that our current server instance is based on the e-mission-server GIS branch, how can we add our own branch after making the necessary changes?

[shankari]

After checking the e-mission-server code, we discovered that the section.py wrapper only wraps formatted information in the original E-mission UI.

I don't understand this statement. What unformatted information are you looking for?

1. the start and end location are in start_loc and end_loc fields of the section
2. Not sure you need any server changes at this point 😄

[xubowenhaoren]

I was still unable to get the correct information.

  $scope.formattedSectionProperties = $scope.tripgj.sections.map(function(s) {
    console.log("start place json", s.properties.start_loc);
    console.log("end place json", s.properties.end_loc);

    return {"fmt_time": DiaryHelper.getLocalTimeString(s.properties.start_local_dt),
            "fmt_end_time": DiaryHelper.getLocalTimeString(s.properties.end_local_dt),
            // "fmt_start_place": s.properties.start_point_name.name,
            "fmt_start_place": JSON.stringify(s.properties.start_loc),
            "fmt_end_place": JSON.stringify(s.properties.end_loc),
            // "fmt_end_place": s.properties.end_point_name.name,
            "fmt_time_range": DiaryHelper.getFormattedTimeRange(s.properties.end_ts, s.properties.start_ts),
            "fmt_distance": DiaryHelper.getFormattedDistance(s.properties.distance),
            "sensed_mode": s.properties.sensed_mode,
            "icon": DiaryHelper.getIcon(s.properties.sensed_mode),
            "colorStyle": {color: DiaryHelper.getColor(s.properties.sensed_mode)}
            };
  });

Logcat:

2021-02-24 23:25:03.669 10520-10520/edu.berkeley.eecs.emission I/chromium: [INFO:CONSOLE(75)] "start place json undefined", source: http://localhost/js/diary/detail.js (75)
2021-02-24 23:25:03.669 10520-10520/edu.berkeley.eecs.emission I/chromium: [INFO:CONSOLE(76)] "end place json undefined", source: http://localhost/js/diary/detail.js (76)

[shankari]

Ah you are not looking at trips directly, you are looking at tripgj (geojson)
That is generated here:
https://github.com/e-mission/e-mission-server/blob/master/emission/analysis/plotting/geojson/geojson_feature_converter.py#L106

The output is a standard geojson feature collection, to make it easier to represent in a map.
You want the "stop" objects from the trip to get the location points

I would connecting with the chrome debugger so you can inspect the resulting data structures more efficiently than using locgcat.

[xubowenhaoren]

In the same www/js/diary/detail.js, now I have

  $scope.tripgj = Timeline.getTripWrapper($stateParams.tripId);
  console.log("tripgj.stops", JSON.stringify($scope.tripgj.stops));


  $scope.formattedSectionProperties = $scope.tripgj.sections.map(function(s) {
  ...
}

Logcat:

2021-02-25 10:34:44.532 27787-27787/edu.berkeley.eecs.emission I/chromium: [INFO:CONSOLE(69)] "tripgj.stops []", source: http://localhost/js/diary/detail.js (69)

So I am still not able to get the stops. Can you point me to a guide for setting up and using the Chrome debugger?

[shankari]

in the docs
https://github.com/e-mission/e-mission-docs/blob/e7c60ae611fc31ebd362b6c3157789af66235777/docs/dev/front/high_level_faq.md

[xubowenhaoren]

I was still unable to locate any useful information in the tripgj.stops.

However, I discovered that each of the tripgj.sections has a geometry array with lat and long points. Can I simply take the first one and the last one of these points and convert them to start & end points for each segment?

[shankari]

I was still unable to locate any useful information in the tripgj.stops.

If there are no stops, then this is a unimodal, not multi-modal trip, so there is only one section.

However, I discovered that each of the tripgj.sections has a geometry array with lat and long points. Can I simply take the first one and the last one of these points and convert them to start & end points for each segment?

That should work