nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Amount of Time Within a Polygon from Tracks?

ArmstKP

I am looking to discern when snow plows are plowing parking lots. Our plows don't have a plow up/down sensor, so I have to use some logic. Is it possible to use the "Find Dwell Locations" of my tracks and determine this? Anybody have any other suggestions?

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

PeterNasuti

@ArmstKP Thanks for reaching out and asking your question! There are many different ways this could be approached and your analytics could be designed using ArcGIS Velocity. Much of this depends on your goals and desired outputs/outcomes:

Do you want to trigger an alert/notification when a plow is plowing a parking lot? (Filter by Geometry tool to notification outputs)
Do you want to enrich breadcrumb observations with whether or not a parking lot is being plowed, or also enrich with the parking lot ID associated with each breadcrumb (Join Features tool)
Do you want to identify the start and end times, know the event duration, create an event identifier of each "parking lot plowing event"? (Detect Incidents tool)
Do you want to know each time a snow plow "dwells" within a certain boundary, likely plowing a parking lot? (Find Dwell Features tool with distance/timespan tolerance)

You can do all of the above, or any combination of the above when building up your analytics. Feel free to provide additional details about your desired outcome/output goals.

ArmstKP

@PeterNasuti Thanks Peter!

I am trying to accomplish your last bullet point. I want to know when a snow plow is within or very near a parking lot polygon, then create a convex hull from the VehicleTracks using the Find Dwell Feature Tool, then if that intersects with the parking lot polygon, I will then take the timestamp of when it was processed and calculate the lastserviced field with that date. I have tested this and my model never outputs any records, even though if I look at my tracks it should trigger an output:

PeterNasuti

@ArmstKP Thanks for the additional info!

Looking at the metrics of your analytic, "Find Dwell Features" has 0 records, so we can identify this tool as the "blocker" to explain why your model has no outputs. This tool more than likely has no outputs because of your properties "distance tolerance: 500 feet" and "time span tolerance: 15 minutes". When a plow truck is moving around plowing a parking lot, it is still in motion and getting bread crumb updates at distance and time span greater than the tolerances specified. Therefore, none of your AVL track points satisfy a "dwell" per this criteria, so this tool has no output. You could adjust the distance/time tolerance to better identify parking lot plowing speed as a dwell, but this could capture many other events when the plow truck is merely driving slow or plowing elsewhere. Rather than diving into analytic design for that tool configuration, lets consider a few things.

From your description, it sounds like the fundamental goal is to update the parking lot polygons with their lastserviced field with the last date of service. In this reply, I am moving forward with that assumption, but if that assumption is wrong please correct me. This is a common AVL/geospatial scenario that has been addressed by various implementations of the below logic to identify/recognize vehicle visits to certain locations.

Consider the following design approach as an option:

Sources
1. Parking lot polygons
2. Vehicle tracks
3. Events (Assuming this is winter storm events)
Outputs
1. Parking lots (updated with lastserviced date)
Tools:
1. Keep your Join Features-1 to enrich Vehicle Tracks with event information
2. Add "Detect Incidents" tool as the next tool after Join Features-1
  1. Pipeline:
    1. Target: output of Join Features-1
    2. Join: Parking lot polygons
  2. Configuration:
    1. Open condition: spatial relationship: intersects
    2. Accept other defaults
  3. Why use this tool?
    1. Create unique sets of observations for each detected incident (plow truck in parking lot polygon)
    2. Filter your AVL dataset down to events where plow trucks are working on parking lot polygons
3. Add "Reconstruct Tracks" tool as the next tool after Detect Incidents
  1. Pipeline:
    1. Target: output of Detect Incidents
  2. Configuration:
    1. Summary Fields:
      1. Your datetime field, statistic of MAX, we will call this "datetimefield_MAX"
      2. IncidentDuration field, statistic of MAX
    2. Accept other defaults
  3. Why use this tool?
    1. Take your set of AVL/breadcrumb points and convert them to a polyline representing plow truck travel within the parking lot plowing event. Also acquires the duration of the dwell event in milliseconds.
4. Add "Filter by Expression" tool as the next tool after "Reconstruct Tracks"
  1. Pipeline:
    1. Target: output of Reconstruct Tracks
  2. Configuration
    1. Filter down any polylines less than "x" milliseconds of duration
    2. Filter on DwellDuration_MAX field
  3. Why use this tool?
    1. Filter out the cases where a plow truck drove into a parking lot briefly but didn't actually spend enough time to plow the location
5. Add "Join Features-2" tool as the next tool after "Filter by Expression"
  1. Pipeline:
    1. Target: output of Filter by Expression
    2. Join: Parking lot polygons
  2. Configuration
    1. Spatial: intersects
    2. Summary fields:
      1. Parking lot name/identifier, ANY
  3. Why use this tool?
    1. Append the associated parking lot name with the reconstructed AVL track plowing that parking lot to the schema
6. Add "Summarize Attributes" tool as the next tool after "Join Features"
  1. Pipeline:
    1. Target: output of "Join Features-2"
  2. Configuration:
    1. Field: the Parking lot name/identifier, ANY that was generated in prior Join Features tool
    2. Summary field:
      1. Datetimefield MAX
    3. Why use this tool?
      1. For each unique parking lot processed by the former tools, calculate the most recent datetimefield value to get the most recent plow visit
7. Add "Join Features-3" tool as the next tool after "Summarize Attributes"
  1. Pipeline:
    1. Target: Parking lot polygons
    2. Join: Output of Summarize Attributes tool above
  2. Configuration:
    1. Attribute join between parking lot name/identifier fields
    2. Summary field: datetimefield value ANY to append the latest edit value
  3. Why use this tool?
    1. Append the latest datetimefield value to the schema of the parking lot polygons
8. Add "Map Fields" tool as the next tool after "Join Features"
  1. Pipeline:
    1. Target: Join Features-3 tool output from above
  2. Configuration:
    1. Replace your original datetimefield value in Arcade expression with the value from this new field
    2. Delete this new/surplus datetimefield value once the value is utilized
  3. Why use this tool?
    1. Update the parking lot polygon modified datetime value

There are many ways to design and configure analytics in ArcGIS Velocity, and I have provided the above as an example that has led to success for other users for similar use cases.

ArmstKP

@PeterNasuti Thanks a million for the detailed steps. One question, though? In step 3.3.2.1.2, do you mean the IncidentDuration field, not the DwellDuration field?

JeffSilberberg

A little off topic, but what device are you using in your plow trucks that you can not get a Telemetry point from for Up/Down ?

brudo

I don't think the "Find Dwell Locations" tool fits your use case, as the plows would still be moving while plowing. To find the total time the plow spends on each trip through a parking lot polygon, I would use the "Detect Incidents" tool. You could either detect incidents spatially, directly against the parking lot polygons, or you could first use a "Join Features" tool earlier in the analysis than Peter showed, to enrich with the parking lot ID (with option to retain all features) - then detect incidents where there is a value for the parking lot ID. I like the second way, as it enables the parking lot ID to be carried forward onto the incidents, without requiring a second spatial join.

In either case, to get the total duration spent on each visit to a polygon, you would be looking for the IncidentDuration on the output records where IncidentStatus is 'Ended'. Or, if you want to allow for the possibility that the plow may still be in a parking lot, you could summarize to get the maximum IncidentDuration for each IncidentId.

If you want to subtract the time the plows spend stopped or parked in a parking lot, and not count that as part of the plowing time, that is where "Find Dwell Locations" might come into the analysis. I won't go into further detail on how you would use that, as I'm not sure of your exact requirements, or whether this would be relevant for you.

Depending on your desired output, "Reconstruct Tracks" might or might not be needed. It depends whether you want line features showing the vehicle's path while moving within the parking lot polygons. If you only want the start and end time for each parking lot traversal, there may be simpler ways, using tools like Summarize Attributes or Join Features against the results from "Detect Incidents".

ArmstKP

@JeffSilberberg We currently aren't using any up/down sensors. We are testing and looking into them right now, but there are many issues with them. We are using speed, location and vehicle type to determine if a route has been plowed. We plow park trails, so we do not get a lot of vehicles traversing segments other than when they are plowing, so it makes it easier.....

ArmstKP

@brudo Thank you for your detailed suggestion!!! I like your idea, but am having a problem placing in my model view (which I screenshotted above) the "Join Features" tool earlier in the analysis that Peter showed, that you mentioned. Could you point out where in my model view you are mentioning?

JeffSilberberg

@ArmstKP

Thank you for the reply. Doing some work with Lonestar out of Texas an they have a number of LTE based trackers that we have interfaced to Velocity that do have the ability to grab Telemetry input. They may be of help to you.

ArmstKP

@JeffSilberberg We obtain our AVL from Verizon with the ability to have sensor data, we just don't have sensors yet.....but looking into them. If you have any suggestions, I would be all ears.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.