Revision 1293
Added by Aaron Marcuse-Kubitza almost 13 years ago
VegBIEN.organisms.csv | ||
---|---|---|
18 | 18 |
stem_dbh,/aggregateoccurrence/*_id/plantobservation/stemobservation/diameterbreastheight, |
19 | 19 |
ht_first_branch_m,/aggregateoccurrence/*_id/plantobservation/stemobservation/heightfirstbranch,Brad: Incorrect for VegBank. This is a measurement applied to a single tree. Check with Bob |
20 | 20 |
stem_height_first_branch_m,/aggregateoccurrence/*_id/plantobservation/stemobservation/heightfirstbranch,"Brad: Should also be userDefined for VegBank. Same as for ht_first_branch_m, but applies to individuals stems, not trees. Rare." |
21 |
stem_tag1,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true](/tag)","Brad: Same as tag1 & tag2, but applied to individual stems. I'm still not clear how to distinguish between methods which tag only individuals trees, and those which tag individual stems.; Quotes sort it before tag2"
|
|
22 |
stem_tag2,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true](/tag)",Brad: see above; Quotes sort it before tag2
|
|
23 |
tag1,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true](/tag)","Brad: Another type of code, typically a number, used by the original data provider to indicate an individual tree. These are numbers on physical tags attached to the tree. Tag2 Is the same thing, only used if the first tag was lost. Obviously not a good system as it's possible a tree tag could be lost and changed more than once.; Quotes sort it before tag2"
|
|
24 |
tag2,/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[iscurrent=true]:[../stemtag?[iscurrent/_alt/2=true]/iscurrent/_alt/1=false](/tag),"Brad: See commend for tag1. Your mapping for tag2 looks correct. Probably both values would go here, only nested, with one superceding the other."
|
|
21 |
stem_tag1,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true]/tag","Brad: Same as tag1 & tag2, but applied to individual stems. I'm still not clear how to distinguish between methods which tag only individuals trees, and those which tag individual stems.; Quotes sort it before tag2"
|
|
22 |
stem_tag2,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true]/tag",Brad: see above; Quotes sort it before tag2
|
|
23 |
tag1,"/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[""""/iscurrent/_alt/2=true]/tag","Brad: Another type of code, typically a number, used by the original data provider to indicate an individual tree. These are numbers on physical tags attached to the tree. Tag2 Is the same thing, only used if the first tag was lost. Obviously not a good system as it's possible a tree tag could be lost and changed more than once.; Quotes sort it before tag2"
|
|
24 |
tag2,/aggregateoccurrence/*_id/plantobservation/stemobservation/stemtag[iscurrent=true]:[../stemtag?[iscurrent/_alt/2=true]/iscurrent/_alt/1=false]/tag,"Brad: See commend for tag1. Your mapping for tag2 looks correct. Probably both values would go here, only nested, with one superceding the other."
|
|
25 | 25 |
x_position,/aggregateoccurrence/*_id/plantobservation/stemobservation/xposition,"Brad: Correct for VegBank. I'm not so sure for VegX. Let's ask Nick about this. These are important, fundamental values of many tree plots, and should be accommodated within VegX." |
26 | 26 |
y_position,/aggregateoccurrence/*_id/plantobservation/stemobservation/yposition,Brad: See comment above for x_position |
27 | 27 |
no_of_individuals,/aggregateoccurrence/count,"Brad: Incorrect for VegX. This is a count of number of indiiduals for an *aggregate* observation. For VegBank, I'm not sure. Not exactly the same as stemCount. An individual tree could have 3 stems but would still only count as 1. We need to check with Bob on this." |
Also available in: Unified diff
mappings/VegX-VegBIEN.organisms.csv: Removed unneeded lookahead assertions from stemtag mappings. They relied on a bug ("feature"?) in the XPath engine that made the value of the lookahead assertion's path the same as the value of the main path, even though the value is set after the path is parsed.