-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add creel and length limits for fish #29
Comments
Should units—the container and the contents—be plural, or singular? That is, do we use |
Figure out how to represent that there are no limits for either |
Wait, do we really need this level of granularity? This is going to be a lot of work to encode, to very little potential benefit. I'm dubious that we're going to see user agents allowing sorting or searching by lengths, especially given how complex lengths can be. (For example, one can catch bass in Briery Creek Lake, but the bass must either be less than 16 inches or more than 24 inches, and if they’re more than 24 inches, only one per day is permitted. Better idea: Allow the use of a simple |
On reflection, that's totally the way to do it. Granularity down to stand-alone units is just silly. |
Simplifying creel and length limits is proving difficult. For each fish, there are optional sub-types (e.g., channel catfish versus blue catfish) or locations (e.g., "below the fall line in tidal rivers of the Chesapeake Bay"), and then creel and length limits for each of those subtypes. Then, for each of those subtype limits, there can be one or more geographic exceptions, with new creel and length limits for those exceptions. Bass are stupid-complicated, but most are rather easier. Emulating existing practices doesn't go particularly well, because the places named aren't often municipalities, or even individual bodies of water. Instead, the descriptions are much more nebulous, such as this striking example:
Short of GeoJSON, there's no way that we're going to represent that as structured data. Realistically, I think that means that we need a structure like this: "limits": {
"description": "25 per day in the aggregate (combined black and white crappie). No statewide length limits.",
"exceptions": {
"1": {
"place": "Gaston and Buggs Island (Kerr) reservoirs and that portion of the New River from the VA–NC state line downstream to the confluence of the New and Little rivers in Grayson County",
"description": "no daily limit"
},
"2": {
"place": "",
"description": "No crappie less than 10 inches"
}
"3": {
"place": "South Holston Reservoir",
"description": "15 per day in the aggregate (combined black and white crappie)"
}
}
} Although, now that I look at that, even that isn't enough, because there's only one The solution is probably to allow |
Oh, right—and there needs to be some separation of description and subtypes and locations. |
These are all fish for which no special restrictions exist, so we use the generic statewide restrictions for unclassified fish. Per #29.
I have no idea what this means: 6 per day, 7" minimum size. Got it. Wait, there's also no minimum size limit? How can there be both a 7" minimum and no minimum? And there's no minimum size, except in South Holston? And there's a limit of 6 per day, with no limits for the exceptions...but there's a limit of 7 per day in South Holston, which is somehow not one of the exceptions? I think somebody's made a mistake here. Either that, or I deeply misunderstand how this data table works. |
What do we do about fish that aren't one of the named species in the "Fish Identification and Fishing Information" section? American shad, hickory shad, red drum, spotted sea trout, grey trout, and southern flounder are omitted from the ID guide, meaning that we lack basic information about them. Seems like either a) we leave them out entirely or b) we include them, but without |
I'll ask the person who created the table, to make sure. As for fish that aren't listed, I'll ask our fish biologists if they can generate the information to add those species. All of the images we use currently are from the USFWS collection; I'll need to check and see if they have images for those species. If not, we might have a photo of actual specimens that could be used. |
Thank you, David!
Oh, good call—I can just grab those from the USFWS website and from other state agencies that have USFWS images. I found red drum, and spotted sea trout without any trouble. I can take care of that! |
The USFWS image library has the American shad, too. That's as far as I got before you replied. ;) |
So, @waldoj, here's what I got from the person working on this:
So it seems that the 6 per day, 7-inch minimum size limit pertains statewide (with exceptions not listed in the table—see below), but at South Holston Reservoir, there is a 7 per day (w/up to 2 lake trout) creel limit with no size limit. That was my original interpretation, and it's also how I read the explanation from our fisheries biologist. At a minimum, I do think the "No minimum size limit" should be removed from the first "Creek and Length Limit" column, because that column usually seems to apply either statewide or to the original geographic locations listed under "Sub-type or locations," not the exceptions... and besides, it's already listed along with the exception as you'd expect, anyway. It's more complicated than that, though, because the "See Trout Waters, pgs. 18–25" refers to additional exceptions/restrictions that apply to various waters (the digest puts it this way: "There are a number of exceptions found below for certain areas and waters (i.e, heritage, urban, special area, special regulation, and fee fishing waters), so please study the sections following for fishing times, dates, and limits"—page 18). (Side note, but your question also brought to light that the table needs to specify that this particular exception applies to South Holston Reservoir, and not the river of the same name.) |
OK, that totally makes sense, @davidmurr—thanks so much for that. I was unlikely to come up with that on my own. :) The whole "Special Regulation Trout Waters" section is so complicated that y'all have decided to render in in prose, rather than as tabular data, and at this point, I'm inclined to do the same. Ultimately, that'll have to be rendered as GIS data to be made viable as machine-readable data. |
We've got lots of data, but not those two crucial pieces of data.
The text was updated successfully, but these errors were encountered: