Hi

I am now facing the problem of trying to report on taxa within one or two vice counties. In the report wizard there is no variable available for selection for 'Vice county number'. I then saw that when using the wizard I could select Taxon records and 'Restrict to one or more administrative areas' and find that when the latter is ticked no data are selected.

I import all my data from spreadsheet, so had assumed that if R6 assigns the data according to the location names and vice counties given on import that they ought to be related for reporting purposes. That they appear not to be is a serious flaw and needs to be sorted as quickly as possible.

Is there a means of selecting Taxon records by vice county that I have overlooked?

If not, is there a possibility of making a crucial reporting system available in the very near future?

Cheers, Ian

In the report wizard using ‘Restrict report to one or more Admin Areas’ includes records linked to locations that have the required Admin Area, e.g. vice county, listed on the Administrative Areas tab on the Geo Info tab. If records aren’t linked to locations in the location hierarchy they won’t appear in this type of report. The alternative is to use the VC polygons available from the NBN (http://www.nbn.org.uk/temp/tools.html). The VC CD they supply allows you to generate the VC boundaries you require in a format that can be imported into Recorder. You will then be able to use the ‘Restrict to one or more Polygons’ option in the report wizard, although the test for whether something is in the polygon is done on the south west corner of the grid square in versions up to v6.10.4.120. In the new version currently in production, you will be able to select whether to include or exclude overlapping grid squares in report results.

Warning - what follows might 'mush' the brain.

Can I try to summarise the system then, as I 'understand' it.

A location can be assigned both Administrative Areas and Grid squares, as well as having an implicit grid reference.

IF a location is assigned EDEN as an Admin area then a report run on Cumbria (of which Eden is a subset) the Location SHOULD be reported because EDEN is related to CUMBRIA as defined in the Admin relation table?

On that basis, one shouldnt need to specify all the sub - admin areas of Cumbria in the report wizard...?

Also One would only need to associate a locations parish as all other admin areas are specified in the relationships table.

HOWEVER this type of report wont report any loose observations that are not assigned to a Location, OR report any locations that dont have the admin areas associated.

If this is correct - then the appropriate thing to do is endeavour to ensure that all ones locations are assigned the appropraite Admin Areas.?

Can this be done in batch form - GIS_ID'ng the appropriate keys for each location and adding them directly to a single table (LOCATION_ADMIN_AREAS)?

The same uncertainty applies to the Grid squares for a location, though these behave differently...?

A location has a 1km square associated but not the 10km square.

If you report (through the Report>Run) on the 1km square - you wont return the location that has only the 10km square associated (quite right).

If you report on the 10km square, despite it not being specifically identified in the first location - it should be reported because the 1km square is related to the 10km square through its bounding box.

This query also returns all the loose grid reference observations I suspect..? But maybe this type of query works on the locations gfrid reference rather than associated squares?

Grid square queries would be mathematical rather than the text relationships of the admin araes.

If what I say is true - why do we have the Grid Squares associated with a location - is this for validation purposes rather than reporting?

If one has a vague loaction which one specifies a 10km grid reference for, then one reports on a 1km square within that - I suspect that the locations observations will not be reported - because they are associted with a 10km reference.

WHAT IF, after associating them with this 10km location, you define a 100m reference that falls inside the aforementioned 1km query - will this observation be reported? Is it looking for loaction or grid reference?

There is a lot of stuff here, and Im not sure it can be quickly unravelled - but it illustrates my personal confusion of the reporting of 'location' in the broad and strict senses.
What I would like is some documentation on how the various reporting methods query the data, so that I can understand what each thing is supposed to do.
Maybe its already out there...?

I know there are 'get around' queries in 6.13 but I dont know if the structure that creates all of the above confusion has actually been simplified...!

If you have got to this sentence and your ears are not bleeding - you have done well and deserve a certificate. Well done you.

MAtt:/

Good to see you are keeping the structure running and up-to-date Darwyn. Very glad to see it seems to be working for you.

As you know - rECOrd runs a similar Location/Site hierarchy and it works well for us though Stuart was once heard to say that it was the most complex site structure he had ever seen. Oh well, whatever works I say.

Cheers

Steve  :D