Ian Dees

The error from the AWS Batch job looks like: ``` TypeError: Body is unusable -- at specConsumeBody (node:internal/deps/undici/undici:6466:15) at Response.text (node:internal/deps/undici/undici:6366:18) at run (file:///usr/local/src/batch/node_modules/@openaddresses/lib/src/run.js:58:59) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async OA.cmd...

Sorry, I haven't been able to figure out what's going wrong here. @ingalls it would help a lot if you could take a look.

What the heck. CSV isn't that hard. Why can't they just use it! 😭

Streetid seems to be the ID into another table, not the actual street name. Needs a little kore investigation into how to resolve that.

We would have to make some changes in https://github.com/openaddresses/batch-machine to support the mapped names. It could be done, but isn't supported right now.

If they have an existing GIS website, there's no need to reach out to them, since you can pull what they have posted. You can look through the maps they...

I wonder if you could grab the original data and see if it's flipped as well? There was an issue when we updated our data processing software a while back...

Why is it bad? Those imported types aren't being used anywhere. The auto detector should import the spiders in its file, shouldn't it?

Is Liberecky a valid state misapplied to this single item? Is the `addr:state` wrong across multiple rows? If it's specific to this one row, it's likely a bad reverse geocode...

The latitude and longitude are available elsewhere on the page in a single big JSON blob. It's probably worth digging those out.