J
26 days ago
ugh so geoclient API says its valid but 311 doesnt accept?
11 replies
jeff
25 days ago
ah not exactly. what happens is we use google places to resolve the lat/lng into an actual address with a building number (eg 123 main stret) as that is required for geoclient (and 311, which uses geoclient). usually this works on the first attempt but when google responds with nothing usable then thecode tries again but with a slightly different lat/lng, like a nudge in the location. it ping pongs this 10x and after th 10th attempt, whch could potentially be pretty far from the original location, it fails but my shitty code will just continue with the submission ... which then gets caught at the step in 311's form whre you pick an address and since the last one it found never actually succeeded in geoclient, it fails in the webform. and just blocks the queue until i step in and put in something that sorta works.
jeff
25 days ago
not a great flow but also it doenst happen that much
jeff
25 days ago
and when it does, i generaly attempt to resolve it so something gets through to 311 rather than reject it back to the user
jeff
25 days ago
311 needs to accept lat lng
:point_up:
1
Joseph Frazier
18 days ago
I'm trying to think about what the alternatives are, to having the 311 form submission fail and block the queue:
Skip the submission entirely? This would probably be the least work to implement and it would eliminate the manual work of having to resolve the address yourself, but it wouldn't be great for users, whose submissions wouldn't go through, with no indication why.
Skip the submission temporarily, but attempt to reprocess it the next time the script runs? This would have the effect of failing submissions building up over time and being retried and refailed until they get manually fixed, meaning that the queue wouldn't be blocked, but it might get slower until you go through a batch of fixing failed submissions.
Skip the submission temporarily, but mark it in a way so it gets ignored by subsequent script runs until manually fixed. This is like the previous idea, but without making the queue slower in the mean time.
jeff
18 days ago
This is something that has been nagging me a little bit also recently. I think I just need to update the code to reject the submission entirely if the lat long doesn’t validate in Geo client. Right now it’s just incorrectly implemented where it attempts 10 times and I think just picks the last attempt as the succeeding one even if it fails.
jeff
18 days ago
But it sure would help if you could run it through your process, validator on the web submission and straight up, reject it if it comes back unsuccessful
jeff
18 days ago
For reference, this is probably one in 500 submissions that I even see this. So it’s so low frequency that just directly rejecting it won’t really impact that many users and honestly will give them a better expectation.
Joseph Frazier
18 days ago
But it sure would help if you could run it through your process, validator on the web submission and straight up, reject it if it comes back unsuccessful
Hmm, this sounds familiar, so I did a little searching and found that we had talked about this idea previously (quoting it so we can still see it when slack auto-deletes the original): https://reportedcab.slack.com/archives/C9VNM3DL4/p1677969946066369?thread_ts=1676288095.715499&cid=C9VNM3DL4
ok, so on my laptop, I tried a few more lat/long pairs from location column in the list of Finding Address submissions, and got the following results:
(40.84503055555556, -73.84670277777778): resolves to 1741 Colden Avenue, Bronx, NY 10462
(41.9993331, -88.30642759999999): does not resolve, but that's expected as that location is in Illinois
(40.8450756, -73.8466127): resolves to 1741 Colden Avenue, Bronx, NY 10462
this is the same as the first item, not sure if it was a duplicate submission
Given that 2/3 of these submissions, as well as the previous 2 I tried, do in fact work with google/geoclient (at least, on my laptop), my guess as to why Finding Address gets submitted is that when process_validation runs from the webapp, it sometimes gets rate-limited or blocked or something, so the webapp can't find a street address. However, I expect that the backend submission process for these reports should still work, unless
@jeff
's laptop gets the same rate-limiting/blocking as the webapp (but that should have nothing to do with the particular lat/long).
@jeff
, does that make sense to you? Essentially, it seems like the problem isn't as bad as the back4app database makes it look, so I'm curious how often you encounter issues with coordinates that legitimately cannot be found.
One thing I could do is outright prevent submissions with coordinates that definitely lie outside of NYC, like that one from Illinois above. That could be a simple bounding-box check, or something more sophisticated using a GeoJSON file that has polygons for each borough (I already have this for electric-citibike-finding purposes)
Saved for later • in 3 days
Joseph Frazier
18 days ago
so, I think this is what we need to do:
This is something that has been nagging me a little bit also recently. I think I just need to update the code to reject the submission entirely if the lat long doesn’t validate in Geo client. Right now it’s just incorrectly implemented where it attempts 10 times and I think just picks the last attempt as the succeeding one even if it fails.
I might take a look and see if it's straightforward to me
From https://reportedcab.slack.com/archives/C802R14UX/p1684720999501709: