Using FOIA Data and Unix to halve major source of parking tickets
41–50 of 248 posts
Re: Using FOIA Data and Unix to halve major source of parking tickets
#42Earlier quoted context omitted.
You could have these hobbies!
I'm kind of on a negative streak these days, so forgive me, reader, but...why in god's green earth aren't these the government's hobbies?!
Re: Using FOIA Data and Unix to halve major source of parking tickets
#43Earlier quoted context omitted.
That is scary, thanks for sharing. And for those here who don't seem to be worried about the safety aspect, note that this means any corporation with a lot of your personal info (insurance, Equifax, etc.) could just submit a FOIA request to get the license plate number of anyone in Illinois (and likely other states) who's parked anywhere illegally, whether intentionally or accidentally... and then strike a deal to ga…
I think, because he glossed over it in the post, that you are underestimating how much work Matt does to get the data & how much the governments he works with try to hinder & redact it. In some cases that is a very good thing. In other cases it’s just them trying to obfuscate and block transparency.
Re: Using FOIA Data and Unix to halve major source of parking tickets
#44Re: Using FOIA Data and Unix to halve major source of parking tickets
#45$190 million?! What does the architecture consist of? A database, some forms and some integrations/api? I'm 90% sure they could have done that with free software and a good support contract with a UNIX provider for far less :/
Re: Using FOIA Data and Unix to halve major source of parking tickets
#46404 error? (page not found)
Re: Using FOIA Data and Unix to halve major source of parking tickets
#47Matt's schtick is automated, large-scale FOIA requesting; he obtains huge collections of data from cities and then tries to do interesting stuff with it. Here, he apparently managed to get all the tickets in Chicago for several years running, and then used that data to fix the parking signs. This, to me, is so neat.
Hey! Thanks for posting this, and the kind words. Interesting note about getting data like this - Illinois FOIA allows a requester to submit a SQL as part of their request.. so long as they know the tables and columns within the database ;)
Re: Using FOIA Data and Unix to halve major source of parking tickets
#48Earlier quoted context omitted.
I'm kind of on a negative streak these days, so forgive me, reader, but...why in god's green earth aren't these the government's hobbies?!
Because different people have different priorities. Remember, you're part of the government.
This is a really important idea, and I don't think I've seen it expressed so clearly before. Thank you.
Re: Using FOIA Data and Unix to halve major source of parking tickets
#49Earlier quoted context omitted.
The TL;DR is: "any criminal records is public information". Fundamentally, even if it's very minor, it's public information until expunged, cleared, or sealed. I think most people are generally fine with this, it's only really a problem if you consistently are committing offenses.
I wouldn't be that generous. You park 15 mins longer than permitted once outside your workplace, and now your violent ex knows where you now work.
Re: Using FOIA Data and Unix to halve major source of parking tickets
#50$190 million?! What does the architecture consist of? A database, some forms and some integrations/api? I'm 90% sure they could have done that with free software and a good support contract with a UNIX provider for far less :/
You're correct that a simple DB with some forms would be cheap.
But integration tends to be crazy expense. For this sort of system, other things that also need to be covered: 1. Billing integration. Including changes to billing codes, bill (fine) printing, testing. 2. Audit integration. Because whenever money is handled, audit follows. 3. Customer support integration. Including UI for customer service, training, testing. This is often a very complex item because customer service already have a zillion systems they have to use and their training requirements are ongoing and expensive, so they want you to integrate with their existing systems instead of giving them a brand new thing, and integrate with their existing training processes, etc etc. 4. Integrate with all those hand-held readers. inc vendor compliance, testing etc. 5. Contract management. You have a contract with the government and they'd like to know that you did what you claim you did. So there's teams of people to deal with on an ongoing basis. 6. Project management. There's more than one person working on this, and a lot of complex integration requiring changes in other systems => extensive project management. 7. Ongoing changes to requirements, often conflicting. All the integration points above are moving targets, so expect that they'll have to be re-done a few times both before and after launch. 8. Arse covering. You now have a large contract with the US Government. You will sued and they will get sued (typically by whomever didn't win the contract). Vast amounts of documentation covering _everything_, including documenting the process by which documents are written => tech writers galore, plus lawyers plus lawyers.
Honestly, this is barely scratching the surface. I haven't even touched the (expensive) work before the contract is even signed.
$190M doesn't go very far!