i-Tree Streets 3.0.7 Known Issues

Issues related to i-Tree v3.x can be posted in this section. If you encounter any issues, please pass the information along to i-Tree Support.
Post Reply
User avatar
dellings
i-Tree Team
Posts: 31
Joined: Thu Aug 21, 2008 2:12 pm

i-Tree Streets 3.0.7 Known Issues

Post by dellings » Fri Dec 04, 2009 10:37 am

1. Some reports do not provide the correct standard error estimates if the project contains street segments that are used in multiple zones. The Population Summary and all Benefit reports are known to be affected.

2. The Comment panel on the Species tab of the PDA does not return to the correct position on high resolution VGA devices.

3. The i-Tree Streets PDA application may crash upon exit. No data loss from this crash has been known to occur.

Issues 2 & 3 will be corrected with i-Tree Streets 3.0.8. There are no plans to correct issue 1 at the moment since the i-Tree Streets manual indicates on page 11 that street segments must be unique within the sample. In other words, a street segment that appears in one zone should not appear in another. This issue has been present since at least Stratum 3.4.

- David
Jerry
Posts: 100
Joined: Wed Nov 28, 2007 8:11 pm

Post by Jerry » Fri Dec 04, 2009 12:26 pm

I appreciate the work you guys are doing with bugs, it really makes this a quality software product!
...the i-Tree Streets manual indicates on page 11 that street segments must be unique within the sample
This problem is interesting to me because it is not, IMHO, a problem of incompetent users. The problem comes with messy old reality, where zone lines run down the middle of streets, leaving one side in one zone and the other side in another.

Is there a chance of creating a means for the user to mark a given segment as split, and thus give a unique identifier to each half? The length might have to be reduced by half to keep the statistics right, and there may be a residual problem with the calculation of the number of segments.
azelaya
i-Tree Team
Posts: 372
Joined: Fri Jun 27, 2008 10:50 am

Splitting segments in different zones

Post by azelaya » Tue Dec 08, 2009 10:21 am

Jerry,

Thanks for the comment & suggestion. Yes, the real world can make things more complicated than what the manual specifies. We may need to look into developing better guidelines for instances such as these unless a method can be developed in the software to account for these situations in the future.
A member of the i-Tree Team
User avatar
dellings
i-Tree Team
Posts: 31
Joined: Thu Aug 21, 2008 2:12 pm

Post by dellings » Thu Dec 10, 2009 1:33 pm

Jerry,

From a statistical point of view, i-Tree Streets assumes the each street segment lies completely within the zone sampled. If this is not the case for your zones, their boundaries should be adjusted such that they only incorporate entire segments. The estimates provided by i-Tree Streets heavily rely on this assumption. Statistically speaking, a zone is nothing more than a group of street segments. Only by knowing the number of segments sampled and the total number of segments within the zone can we provide accurate estimates.

- David
Jerry
Posts: 100
Joined: Wed Nov 28, 2007 8:11 pm

Post by Jerry » Fri Dec 11, 2009 9:46 pm

Thanks, I have a pretty good grasp of the statistics involved.

My point is that "reality rules," and zone lines run right down through the middle of street segments most of the time. And if you don't incorporate this fact into the model (accepting only segments that lie completely within a zone), then it seems to me that the i-Tree sampling process will introduce a systematic bias against all zonal edge trees--undermining the very principle of sampling itself and thus calling the validity of its inferences into question.

Because most zone definitions are reality-based--frequently being actual administrative divisions--there can be no question of adjusting the zones to fit the model. Luckily, if you divide a segment in half lengthwise because of a real-world setup, you get two new segments; since no observer bias is involved, both are still legitimate statistical units. There have to be some adjustments in the zonal (but not community-wide) calculations with respect to the length of such one-sided segments, but otherwise it seems to me all will still be well.

This is admittedly a technical point, but it has a certain interest nonetheless.
User avatar
dellings
i-Tree Team
Posts: 31
Joined: Thu Aug 21, 2008 2:12 pm

Post by dellings » Mon Dec 14, 2009 1:50 pm

Jerry,

Statistically speaking, on average each segment should cover the same amount of area. Including half of a segment in your sample would adversely affect the estimates generated by i-Tree Streets. There's nothing we can do to incorporate this into the model, however you can adjust your sampling method.

One such method would be to divide every segment into two distinct, equally sized, and uniquely identifiable segments. This effectively doubles the amount of segments in your zones/community, and allows you to sample half segments where needed. Assuming that no more than two zones equally share a single segment, this method should allow you to create distinctly separate groups of segments for each zone without modifying their boundaries and without adversely affecting the estimates generated by i-Tree Streets.

Whatever you decide to do, its important to remember that standard sampling practices indicate that your samples should be uniform in size and randomly distributed.

- David
Jerry
Posts: 100
Joined: Wed Nov 28, 2007 8:11 pm

Post by Jerry » Mon Dec 14, 2009 1:57 pm

Thanks for the response, David.
Statistically speaking, on average each segment should cover the same amount of area.
I have trouble understanding what you mean by this, since 1) random segments (blocksides) are all different lengths, and 2) segments in i-Tree Streets have no reference to area at all that I can see, only line. I suspect you are thinking of i-Tree Eco, which does require plots of identical area for its statistics.

We have probably beat this topic to death by now, so I will go back to my shell. Thanks for the conversation.
Post Reply