Handle range labels better

[waldoj]

This is an actual excerpt from crow.json:

"range": {
    "statewide": {
        "season": {
            "date": {
                "starts": "2013-08-17",
                "ends": "2014-03-15"
            },
            "days": ["Monday", "Wednesday", "Friday", "Saturday"]
        }
    },
    "national_forest_lands_and_department_lands": {
        "season": {
            "date": {
                "starts": "2013-09-02",
                "ends": "2014-03-10"
            },
            "days": ["Monday", "Wednesday", "Friday", "Saturday"]
        }
    }
}

national_forest_lands_and_department_lands? That's meaningless. We should make two changes here.

The first is to move to the bear.json example, which is to simply number these ranges, rather than try to name them. The groupings are frequently not logical in a way that lends themselves to naming.

The second is to figure out how to actually represent a concept like "national forest lands and department lands." Representing "Virginia" is easy (it has a GNIS ID, after all), but there's no ID for all national forest lands and department lands.

[waldoj]

Now that I look at bear.json, it's not a good example. We arbitrarily go back and forth between using integers and labels as range identifiers.

I think there are a few questions to be answered:

1. Should ranges always be primarily identified with an integer, or is a named label OK?
2. If we provide range labels internally (that is, not as the key), how do we specify this?
3. Do we label the statewide range as "statewide" or as "Virginia"? I appreciate that the DGIF norm is the former, but I think a more useful descriptor for software is the latter.
4. Should we have "statewide" geodata? Or is it a mistake to provide geodata for what are basically catch-all rules that could be overridden on local levels? As I write this, I think we provide adequate infrastructure (in the way of exceptions, etc.) that I don't think this is a problem, and that we probably should provide GeoJSON boundaries for the entire state, and include that in the increasingly misnamed counties.json?

[waldoj]

1. Yes, they should always be identified with an integer. While there's an argument to be made that people should properly iterate over the elements, I think it's like that some people will just $i++ their way through them, and consequently miss named elements.
2. We already label ranges internally, in the form of the places elements. But that breaks down with "national forest lands and department lands" (which is a range for crows). Realistically, I think that should be treated as two places—national forest lands and DGIF lands—left devoid of GNIS IDs etc. We might need to add a comment field to allow explanation to be exposed to the user agent, e.g. "all land that is part of the national forest". Ideally, we'd specify these properly, actually listing each national forest and all DGIF lands, with geodata for each.
3. We should label statewide lands as "Virginia," since that's an actual place name with a GNIS ID, etc.
4. We do need geodata describing the whole of Virginia, at the same level of accuracy as our counties (which is to say, pretty accurate).

[waldoj]

It seems like trouble to specify place names as we're doing it right now. For example:

"places": {
    "Chesapeake": {
        "gnis_id": 1496841
    },
    "Suffolk": {
        "gnis_id": 1500187
    },
    "Virginia Beach": {
        "gnis_id": 1500261
    }
}

In most programming languages, isn't "Virginia Beach" going to be the name of a variable? Are we really giving people a variable with spaces in it? Explore whether this is going to be trouble. Even if we pretend that people don't care about the phrase "Virginia Beach," since we have a GNIS ID etc. (which I doubt is true), there are places for which we have no such identifier.

[waldoj]

On reflection, I don't think that it's a problem having spaces in these JSON labels. I'm going to play around with a bit more, but I don't think that there's any realistic way in which anybody is manipulating this data for which it's a problem.