[Babase] FPSAMPS Kidcontact and Kidsuckle blanks
Karl O. Pinc
babase@www.eco.princeton.edu
Tue, 12 Oct 2004 15:29:19 -0500
On 2004.10.12 13:43 Daphne A. Onderdonk wrote:
> Hi all,
>
> Trying to catch up on the onslaught of Babase emails from the
> weekend... As far as this issue is concerned, I think it would make
> more sense for me to look at it since I feel like I have intimate
> knowledge of the Psion data after doing all that old clean-up (lucky
> me!). And I know from some of the querying we've done on the point
> samples that there are definitely juveniles that ended up in FPsamps,
> and adult females that ended up in JPsamps. Cleaning up the point
> samples is on my list of things to do (the female/juv issue, and some
> mistakes that got through before Robert put more checks in on the
> collection end), but I haven't gotten there yet. Is that something
> that needs to happen before the conversion? When we/I get to it, we
> will need to make some decisions about what to do with the data
> that's in the wrong place (the problem being that it's not just in
> the wrong place, but that it is collected slightly differently for
> females vs. juveniles).
Perhaps only those 8 need to be cleaned before conversion as I don't
think they'll go in. Otherwise, all the Psion rows will be going into
the same tables (POINTS and NEIGHBORS) with only the extra columns
that's
in the female point samples (Kidcontact, Kidsuckle) going into
FPOINTS. There is a flag that says whether the point sample is
juvenile or female point sample, and you'll want to get that
right but it need not be done for the conversion.
This all presumes that the data that goes into the corresponding
columns of FPSAMPS and JPSAMPS are encoded the same way. For
example the two Foodcode columns should have the same codes for
the same food. If not let me know and we'll figure out a way
to deal with this.
As far as "bad data" goes, the database is not checking for bad
data. It probably should, but I don't know what good data looks like,
I just rely on the Psion to get the data right. We do want the
ability to make manual corrections (right?) in which case the
database should be checking. That would mean the bad data would
need cleaning before the conversion. However, AFIK, there's
no description of each column as the other tables have so I've
nothing to go on to write the rules. Comment anybody?
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein