two users with same countingLocation?

[roughani]

From @wleddy on January 2, 2016 0:21

so, if 2 or more users somehow get the same counting location code and start counting… we currently just record all the trips.

Maybe we should have a way to lock out other users once a trip has been recorded for that counting location.

How do we know if someone other than the first counter is submitting counts? What do we do about it when we detect a second user?

Copied from original issue: wleddy/bikeandwalk#6

[roughani]

From @wleddy on January 2, 2016 3:1

Ok, what if we record the IP address of the user the first time we record a trip, i.e. It goes from a count o zero to not zero. If there is a trip, the ip must match.

In theory 2 users could be behind the same NAT router, but I doubt that they will be standing in the same location while they are counting.

A good question is do the cell network use NAT? One per cell or something else? Are mobile users likely to get different IP between connections?

[roughani]

From @jasonody on January 6, 2016 16:20

I think you are thinking along the right lines that recording IP addresses won't be the most reliable way to check for this as you have no control over that piece of information.

Have you considered storing something in session to tie the client to the counting location? This could be checked every time count data is submitted. Also by keeping the check server side, you'd be able to code it so the client can be refreshed and the count would still be able to continue as the session will still be active.

[roughani]

From @wleddy on January 7, 2016 1:11

That's a good idea.

Here's the scenario I'm mostly thinking of:

2 users some how click the same link or manually enter the UID for a location. They both start counting, but at different locations.

So the trips are rolling in. Their counts are ligit, but I can't tell who is at which location (it looks like the same one to me, just really busy)

Before I set the session for this I can check the trips to see if anyone has created a trip for this location already. If so, I know that I have a second counter but they may in fact be at another location and are just using the wrong UID. (really unlikely i know but still...)

I know from my experience counting that I can't just tell the second user "Sorry you have to contact your count admin and sort this out". The counter won't have time since the count period has started and the admin probably couldn't figure it out anyway.

Here's my current thought. Anytime I have a suspect trip record to create, instead of adding it to the real trip table or discarding it, I add it to a "Provisional Trip" table with an indication of the issue. Duplicate counter, bad/missing data, what ever. Email the Super Admin (me) that there are provisional trip records to review. In the case of a second counter, I would set the session value to indicate that.

I then dive into them and contact the local count admin or what ever to try to fix them if we can and then we can add the trips to the real trip table.

Long road to a little house...

What do you think of that Idea?

On Jan 6, 2016, at 8:20 AM, Jason Ody wrote:

I think you are thinking along the right lines that recording IP addresses won't be the most reliable way to check for this as you have no control over that piece of information.

Have you considered storing something in session to tie the client to the counting location? This could be checked every time count data is submitted. Also by keeping the check server side, you'd be able to code it so the client can be refreshed and the count would still be able to continue as the session will still be active.

— Reply to this email directly or view it on GitHub.

[roughani]

From @jasonody on January 7, 2016 6:48

That would allow the count to continue and the data to be collected. I see what you mean about once the count is in progress you pretty much just have to let it continue.

I'm still wondering if there's a way that you can make the likelihood of two counts mistakenly happening for the same location that you don't even need to address it. If the UIDs were random strings of data, the person performing the count would have to rely on the link in order to start the count. If this link was directly delivered to the counter via email, then they only way that someone else could accidentally use it would be it was shared with them. This doesn't remove the possibility of this occurring and maybe you were already planning to distribute the links in a similar fashion.

I'm guessing this is going to be a "nice to have" feature?

[wleddy]

After a conversation with a potential user, two or more counters at the same location may be a feature and not a big. He brought up the situation of extremely busy locations such as bikeway entrances and complex intersections. In these cases 2 or more counters could. Agree to divide the loc to get a more accurate count. This seems like a valid approach to me.