B1C14

AI

Lucky number 13! Finally, AI was helpful in writing a chapter.

Specifically, the part of the text that is customized to your location, i.e.,

The players were running all over the insane streets of [your city]

and

The players were splashing around in the [nearby water body] trying to get the ball.

I spent maybe an hour trying to find a dataset or API where I could plug in latitude and longitude coordinates and get back the nearest water body. I found a bunch of scientific datasets like this but all of them seemed too detailed and complicated for what I wanted to do. Finally, after an hour on the struggle bus, I realized that this was a perfect question to ask Claude, so I did.

Immediately, Claude figured out that I should use the OpenStreetMap API and wrote me the code I needed.

Except... it didn't work. I think the initial solution got me 75% of the way to the answer, and I especially appreciate that it automated the tedious work of reading API documentation to write the correct query.

Claude and I had to go back and forth a little bit to get to a function that worked for me.

  1. To find the city name, the initial code looked for only the city data field associated with the latitude and longitude. Unfortunately, addresses are complicated and different states and countries handle them in different ways, so the city data field doesn't always exist. The relevant place name might instead be a suburb or hamlet or village or county or admin_level_8.
  2. The initial code looked for all water bodies within 1 km. However, there isn't always a water body within 1 km. Once I pointed this out to Claude, it added code that looks for a water body within 2.5 km if the first query fails, and one within 5 km if the next query fails, and one within 10 km if the next query fails. This pattern of increasingly larger searches is really common in code and also really tedious to write, so I'm glad Claude did it for me.
  3. The initial code looked for any water body nearby, but I only wanted named water bodies, not random ones like backyard pools. This was a pretty easy fix for Claude.

Once I had a function that consistently gave me the city and nearest water body for different coordinates, I added it to my webpage. I wrote this code by hand, which took about an hour (but I was pretty distracted). I could have asked Claude to do it, but didn't trust Claude to not start editing the other code on my page.

Overall, this was a pretty positive experience using AI to save a lot of time. I think it saved me at least 5 hours of work, mostly in finding the right data source and reading API documentation.

However, I don't think Claude's code was particularly high quality:

  1. The current API calls are serviceable, but I have low confidence that they are optimal.
    1. The nearest water body API call uses the query parameter "natural"="water" but later on the code filters the results using element.tags.water. Why not just query on "tags"="water" in the first place? Seems like it might be more efficient.
    2. The nearest water body API query has two parts: way["natural"="water"] and relation["natural"="water"]. I don't know why both of these are needed.
    3. The city API query is to a different endpoint than the nearest water body API query. Is there a way to combine these to get a faster result? If not, is there a way to run these in parallel?
  2. The comments just generally seem haphazard. There are comments for some pretty self-explanatory lines like // Process results and // Make request to Overpass API, but none for the more obscure bits mentioned above. There are also comments that are incorrect, like // Sort by distance and get closest for code that doesn't do any sorting.
  3. Claude also didn't mention to me that OpenStreetMap recommends using the API endpoint only if I have less than 10k queries a day. I wouldn't have known this if I hadn't looked through the documentation myself.
  4. Similarly, Claude suggested looking for the nearest water body within 50 km if all previous queries failed. This seems like a pretty large number, and I have no idea if a query this large is okay to run against a free, open-source endpoint. I ended up going with 10 km as my largest number.
  5. I would have LOVED it if Claude asked me some questions before jumping into writing the code, like:
    1. How should the output be structured?
    2. What should happen if no information is found?
    3. What should happen if only some information can be found? Are partial results helpful?
    4. How much do you care about the speed vs accuracy tradeoff?
    5. Are you willing to pay for a faster API?
    6. Do you want me to add logging statements?

People

Thank you to 17776 for being such a gem of internet fiction. I've been trying to read more interactive/online fiction for inspiration (and anti-inspiration) but nothing even comes close to 17776. It is, as far as I know, sui generis. I am incredibly grateful it exists. The football references in this chapter pay tribute to it.

Thank you to OpenStreetMap volunteers. It is so insane and incredible to me that you all have mapped out even the private swimming pools in my neighborhood. Wikipedia gets a lot of glory for being a volunteer-run information-gathering organization, but OpenStreetMap is also doing amazing work for a fraction of the credit. I am humbled to think of the volunteers in my neighborhood who keep the local maps updated and get basically nothing in return. It is a reminder that there are ordinary heroes all around me who work hard to make the world a more beautiful place.