Many birders keep lists for nested regions, for example:
North America
California
San Diego County
It is not clear to me how to do this within the existing region framework. If this is not currently possible, what is the level of complexity of any extension needed for this functionality. I am an apprentice-level Java coder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regions aren't currently nested. That is, in the database table of regions, there is not a field of parent regions.
There is one thing that you can do. It works OK for sparsely nested regions but scales terribly for people who keep lists for every state or for every county. For example, if you keep San Diego County because you live there and a few others, you might try something like the following. To list all species seen in California, use region-restrictions panel to select all the counties for which you keep lists in California.
What would it take to nest regions? The answer depends on exactly what behavior you want. The basic necessities are:
- modify the database schema and provide
an upgrade path for existing users;
- provide users reasonable opportunities to
assign parentage to regions and to change
parentage;
- decide what happens when someone deletes a
region that has children and implement it;
- construct the database transactions to make
everything happen.
I suspect that the best thing to do would be to turn the table of regions in the region browser into a tree-table of regions. (I've been working on tree-tables to be able to turn the tree of trips into a tree-table of trips that provides more information and is editable.)
If the goal is to be able to query regions inclusively when creating lists of observed species, counting observations or querying ticks, the following are also needed:
- SQL for inclusive queries;
- in the region restriction panel for creating
lists, counting ticks and querying ticks,
present a tree for selection rather than a
simple list and a checkbox that allows users
to query regions inclusively or not. Also
provide persistence for the open/close state
of the tree.
Some of the things in these lists are easy, some take some thinking and planning and others are just a lot of work.
Dick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the analysis of the problem. I have started reading about database tables looking for
things I might do which are within the scope of my abilities.
Also I'll look at the code of the region browser.
LeRoy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many birders keep lists for nested regions, for example:
North America
California
San Diego County
It is not clear to me how to do this within the existing region framework. If this is not currently possible, what is the level of complexity of any extension needed for this functionality. I am an apprentice-level Java coder.
Regions aren't currently nested. That is, in the database table of regions, there is not a field of parent regions.
There is one thing that you can do. It works OK for sparsely nested regions but scales terribly for people who keep lists for every state or for every county. For example, if you keep San Diego County because you live there and a few others, you might try something like the following. To list all species seen in California, use region-restrictions panel to select all the counties for which you keep lists in California.
What would it take to nest regions? The answer depends on exactly what behavior you want. The basic necessities are:
- modify the database schema and provide
an upgrade path for existing users;
- provide users reasonable opportunities to
assign parentage to regions and to change
parentage;
- decide what happens when someone deletes a
region that has children and implement it;
- construct the database transactions to make
everything happen.
I suspect that the best thing to do would be to turn the table of regions in the region browser into a tree-table of regions. (I've been working on tree-tables to be able to turn the tree of trips into a tree-table of trips that provides more information and is editable.)
If the goal is to be able to query regions inclusively when creating lists of observed species, counting observations or querying ticks, the following are also needed:
- SQL for inclusive queries;
- in the region restriction panel for creating
lists, counting ticks and querying ticks,
present a tree for selection rather than a
simple list and a checkbox that allows users
to query regions inclusively or not. Also
provide persistence for the open/close state
of the tree.
Some of the things in these lists are easy, some take some thinking and planning and others are just a lot of work.
Dick
Thanks for the analysis of the problem. I have started reading about database tables looking for
things I might do which are within the scope of my abilities.
Also I'll look at the code of the region browser.
LeRoy