On: The money spent on lotteries doesn’t go to the par...

[iudqnolq]

> the JSON responses for, say, a trailhead in National Forest in Inyo Country, CA are different from a trailhead in National Forest in Deschutes County, OR. And those are both different for the JSON response format for a trailhead in the King Range National Conservation Area. Which is different from a trailhead in any National Park.

Are you guessing here? I don't really know what you mean by the JSON response (from who to who?).

I tried to look into whether recreation.gov has per-agency or even more granular schemas. I found a manual to the Recreation.gov agency portal that suggests the answer. Note that even though it's hosted on the usfs site it has no usfs-specific branding. The section "Adding New Inventory to Recreation.gov" doesn't describe any agency-specific options explicitly, though it does have vague manual processes that could in theory involve custom development.

https://www.fs.usda.gov/Internet/FSE_DOCUMENTS/stelprd380615...

[qrohlf → iudqnolq]

You can browse the site and look at the network traffic in your browser's devtools. There are some radically different response structures for the various different land management agencies.

[iudqnolq → qrohlf]

I just did. There's a whole bunch of junk and duplication. I focused on finding the available campsites at a campground because that seems like a core feature to me. You apparently make a GET to

    https://www.recreation.gov/api/camps/availability/campground/{id}/month?start_date={date}

I tested a USFS campground in Idaho and a BLM campground in Utah. Both returned JSON in the same general shape.

USFS (Idaho): https://www.recreation.gov/api/camps/availability/campground...

  {
    "{id}": {
      "availabilities": {
        "{date}": "Available",
      },
      "campsite_id": "63045",
      "campsite_reserve_type": "Site-Specific",
      "campsite_rules": null,
      "campsite_type": "STANDARD NONELECTRIC",
      "capacity_rating": "Single",
      "loop": "LOWER",
      "max_num_people": 8,
      "min_num_people": 1,
      "quantities": {
        "{date}": 1,
      },
      "site": "012",
      "supplemental_camping": null,
      "type_of_use": "Overnight"
    }
  }

BLM (Utah): https://www.recreation.gov/api/camps/availability/campground...

  {
    "10161360": {
      "availabilities": {
        "{date}": "Not Reservable",
      },
      "campsite_id": "10161360",
      "campsite_reserve_type": "Site-Specific",
      "campsite_rules": null,
      "campsite_type": "STANDARD NONELECTRIC",
      "capacity_rating": "",
      "loop": "One",
      "max_num_people": 8,
      "min_num_people": 1,
      "quantities": {
        "date": 1,
      },
      "site": "Site 1",
      "supplemental_camping": null,
      "type_of_use": "Overnight"
    }
  }

I'll give some credit to Booz. This seems like a decent API. Plus it's nice theres no auth whatsoever. It certainly looks to me like they're using the same data model to store both examples.

This is of course just one example. There are a ton of other JSON requests in the flow of reserving one of these specific campsites, and then there are all sorts of other processes like backpacking permits.

In my personal experience I've seen two backpacking permit reservation system styles. There's one that looks like it was shoehorned into the campsite reservation model, and another where it looks like the agency gets to define a bunch of free text fields and then has a human manually review and enter into a system.

In general I get the vibe from recreation.gov that whenever there's complicated logic there's a human in the background doing the actual work. I base this on the amount of free text inputs and the fact some actions take hours to weeks.

That's it for me looking into this, but if you post an example of what you're talking about I'd be interested.