I'm trying to identify bus stops using GPS dataset including those attributes:
Bus Number
Current Bus Latitude
Current Bus Longitude
Current Time Recorded
I grouped data by bus_no and date and I did calculation on the data to get distance, duration, speed, and each stop occurred with its duration until a move happen. Now I want to identify bus stop from these set of stops occurred some of these stops occurred because of a traffic or because it's a bus stop and I want to identify this so is it a way to do it ?
I tried to read papers on this problem but I didn't find any thing that like this. most of papers already have stops determined.
So is there anyone can give me an advice for how I can solve this problem?
The main difference between a bus stop and a traffic stop in your situation is the duration of the stop. Bus stops duration would be consistent and short, rather than long and inconsistent like a traffic stop, hence I would advise you to create small bins of duration and plot a histogram. Ideally, the highest bin would be your bus stop duration, then you can map the duration bin back to the stops.
Related
I am working on a scheduling and routing app that uses Google Maps to create my route to the appointment location. Upon arriving at the appointment location, the app sets up a geo-fence around that location. The app is designed to send an eta text to the next appointment when I leave out of the geo-fence. Since I am likely to drive through the geo-fence due to either missing the address or looking for a parking spot, I have a timer set for 3 minutes. This requires that I stay inside of the geo-fence for 3 minutes. Once the 3 minutes elapses, then the app is set to send my eta text to the next appointment once I leave out of the fence. My location on the map appears to be determined by the triangulation of the cell towers. Here's the problem, I'm testing in a rural area with poor cell signals and limited towers. This reduces the accuracy of my actual location as determined by the triangulation of the cell towers. It is causing the icon that represents my location to bounce in and out of the geo-fence without completing the 3 minute time requirement. This is most likely due to the poor cell connection and network. Is there a way for me use only the GPS feature of the phone/Google Maps and disable the cell network from trying to position me? This doesn't happen in urban areas where there are more towers and a strong network.
Is there a way to detect a user pausing a run/activity within the strava API?
With Get Activity Streams (getActivityStreams) you can obtain differents StreamSet from your activity: in order to detect pause I think you can analyze CadenceStream or MovingStream.
Pauses are not available in the Strava API and can not be extracted consistently through algorithmic processing of the available fields. Moreover, the data contained in the API's streams collection can not be processed in a way which will arrive at the summary distance or time of the run.
The MovingStream contains a bit field which does not flag pauses, but instead (presumably) flags points where the athlete stopped moving. Although, that said, this field can not be used to arrive at the Moving Time by summing up the time values where this flag is true.
I am aware of the way CAN bus does its arbitration. In a nutshell the CAN node ID having more '0' 's in its indentifier wins the rite to transmit on the bus and the rest of contending nodes back off.
But i dont find any details of how long the backed out node waits before re-trying to win the bus back. I consulted a few sources but still cant find the answer. Any experimental evidence for this ?
Bosch CAN
Introduction to the Controller Area Network
It is free to try again after the winning frame has been transmitted and no dominant bit has been found in the "intermission field" at the end of the CAN frame. You'll probably find a formal definition of this if you search the spec for "intermission field", see for example 3.1.5 of the old (obsolete) Bosch spec you linked.
The important part here is to realize that every CAN controller listens to every single frame, even if it isn't interested in it. This is how you achieve collision avoidance, rather than collision detection.
As mentioned in the Bosch CAN specification document all the CAN nodes can start to send pending frames when Bus Idle condition occurs (no dominant bit found on the bus). During the intermission period in the Interframe spacing no node can transmit (Overload frames can be transmitted but not Data or Remote frames). CAN nodes must wait for 3 recessive bits during this period. All nodes can start transmitting right after this intermission period.
If multiple nodes start at once after intermission period then the lowest identifier frame will win the arbitration. If the remote and data frames (both have same identifier) from different nodes start then the data frame will win the arbitration.
I agree with the answers above but i was looking for more mathematical analysis of the CAN bus timings. I found this excellent lecture notes : Time analysis of CAN messages
. Chapter 3
As seen in:
http://aprs.gids.nl/nmea/#gga
The first part of the GPGGA sentence , is UTC time. for example:
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
The UTC time is: 12:35:19
My GPS device output the sentence:
GPGGA,000019.032,,,,,0,00,,,M,0.0,M,,0000*5F
As I see it, this is a standard - these sentences have a certain structure.
Or am I wrong?
It would appear that your GPS does not have a fix yet. If it doesn't have information from satellites, then it doesn't know what time it is.
The time you see is likely indicating that your GPS has been on for 19 seconds, or that it thinks it is 00:00:19 based on an internal clock that was running since the time was last received.
Looks like GPS is not in sync with satellite signal, so it is showing time from internal clock.
#kaushik, did you connected the antenna. If you connected pls check whether your gps has active receiver or passive receiver.
I am creating a BREW app that requests the user's position.
If the phone cannot acquire the position, I would like to display an error.
How long should I wait for my callback to be called before I determine that the phone is not likely to get a GPS fix?
When a cold start is required, the receiver has to download a full set of Ephemeris data, which is broadcast from the GPS satellite over a 30 second cycle and re-transmitted every 30 seconds.
So I would say that 60-90 seconds (two or three Ephemeris cycles) would be a suitable time to wait before declaring failure.
http://www.navigadget.com/index.php/gps-knowledge/ttff-time-to-first-fix
Note that if a device requires an almanac download, the startup time can be much longer (on the order of 12.5 to 15 minutes). This is referred to as a Factory TTFF (Time to First Fix).
I might go with an increment (say 20 or 30 seconds) between notifying the user that you have failed to establish a link, and give them the option to stop trying. Keep at it until they stop you, or a set number of iterations have passes (say 5 - 10 iterations).
45-90 seconds.
For more information, see the GPS Time To First Fix article at Wikipedia.
But you can never know when the user actually has view to the satellites or not, maybe they are still inside when they start your program, so the approach suggested by Matthew Vines is much better than a constant delay.
Cellphone-specifically, I've had a Motorola phone that had a GPS receiver, but was horrendously bad at it - it could take it around 5 minutes to get a fix where my standalone Bluetooth receiver would manage in less than a minute.
Why are you declaring failure after a fixed timeout anyway? Why not, after a reasonable time has passed (say, a minute), display a message to the tune of "GPS fix still not available; but I'm still trying" with a possibility to cancel at any time if the user is fed up? What do you expect the user to do with the failure message you're proposing to give him?