search

hiten4github / tamt

Automatically exported from code.google.com/p/tamt
0 stars 0 forks source link

All reports by Tag should include Default and user-defined zone tags #67

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
in all the reports generated from the Analysis page by tag, the results for the 
 Default and user-defined zone tags should also be included, not just the 
road-tags

Original issue reported on code.google.com by jarogers...@gmail.com on 13 Apr 2011 at 10:22

GoogleCodeExporter commented 9 years ago 
Probably because of this the queries failed. See screen shots

Original comment by jarogers...@gmail.com on 13 Apr 2011 at 10:25

Attachments:

GoogleCodeExporter commented 9 years ago 
Need steps to reproduce so that we know the reported UI error is created by the 
reported workflow problem

Original comment by stuartmo...@gmail.com on 18 Jun 2011 at 12:56

GoogleCodeExporter commented 9 years ago

Original comment by stuartmo...@gmail.com on 18 Jun 2011 at 1:48

GoogleCodeExporter commented 9 years ago 
After some homework in looking at this issue, I have to categorize this as a 
feature request, not a defect. It may still be critical to have in the final 
release, but it is a significant departure in how we integrate traffic flow and 
speed distribution, which are the cornerstone of all subsequent analyses.

This is cross-cutting, meaning it affects more than a single part of the 
system. While it is not global (like logging might be), it affects enough parts 
of the system to merit a significant amount of development and testing time.

On Monday we'll need to discuss a) the design, b) changes to the data model, c) 
the impact on the system and d) the impact on the schedule for the next week.

Original comment by stuartmo...@gmail.com on 19 Jun 2011 at 1:44

GoogleCodeExporter commented 9 years ago 
Stuart,
This has always been a requirement of the system and is needed (essential)
I think it involves:
Hardwire three tags that will already be included whenever you create
a new project. These are secondary street tags for Residential,
Industrial and Commercial areas.
One of these three is chosen by the user as default (we are already
doing this), the other two are sub-zones.
The length of each of these three tags is calculated from the area
they include (square km) divided by the average block size (in km)
In the routine where you assign each GPS point to a tag you add an
else clause that captures only those points not assigned to road tags.
If that GPS point lies in one of the sub-zones it is assigned to that
sub-zone secondary street tag. If it is still unassigned, it is
assigned to the default zone secondary street tag.
If you pre-populate the Tags list with these three names of your own
choosing then the user cannot assign these to anything else.

Original comment by jarogers...@gmail.com on 19 Jun 2011 at 11:23

GoogleCodeExporter commented 9 years ago 
I understand that the 3 defaults were always part of the spec, but they had 
limited application to act as a proxy for block length in user-defined zones. 
They are hardwired when we create a new study region, and yes, a default is 
always chosen. You are also correct in that during GPS import, each point is 
tagged with a default in the case that it is not near a user-defined road or in 
a user-defined zone. And, yes, the tag creation prevents users from creating 
tags with these reserved names (#RES, #IND, #COM). 

The problem arises when we are trying to populate the traffic count report as a 
precursor to all of the subsequent speed bin calculations (speed dist, speed 
dist x traffic flow, and the aggregates by daytype and tag). Traffic counts are 
inserted by the user, and must be tagged by the user with user-defined tags. 
Therefore, there are no traffic counts for any zone types (i.e. #RES, #IND, or 
#COM, which are analogous to user-defined road tags) or for the default study 
region zone type.

Because they are no traffic counts for any zone types, they are not part of the 
subsequent calculations for "speed distribution x traffic flow", and are 
therefore omitted in the aggregate calculations that get us to the final table.

As for classifying this as essential, I can't really argue with that. However, 
my classifying it as a feature request rather than a defect points to the fact 
that there is a new design here. It's not just that there is a planned design 
that is broken, it is that there is a new design: using default zone types as 
part of the analysis beyond the initial design of using them as a proxy lengths.

Original comment by stuartmo...@gmail.com on 20 Jun 2011 at 12:51

GoogleCodeExporter commented 9 years ago 
We'll discuss
If you make #RES, #IND, or #COM visible them the user will put the
traffic counts in.

Original comment by jarogers...@gmail.com on 20 Jun 2011 at 1:22

GoogleCodeExporter commented 9 years ago 
I should specifically note that the zone types (#RES, #IND, #COM) and the 
default zone type are already being used in the calculation of a later stage of 
the "speed dist x traffic flow" table (i.e. 
speeddistributiontrafficflowvehiclespeed) where we are removing tag from the 
matrix. This is where they are used as proxies for blocklength. In this case, 
these zone types are invisibly embedded in at least of the intermediate tables. 
But they are not explicitly part of the table (i.e., they don't hold there own 
rows in the table as distinct tags).

Again, we likely need to talk this through over a skype call.

Original comment by stuartmo...@gmail.com on 20 Jun 2011 at 1:25

GoogleCodeExporter commented 9 years ago 
Part 1:
- on study region creation; add 3 default zone types as tags assoc with new 
study region (so that getTags returns all three + UDFs)
- we can show on the traffic count input page
- supress them on the road creation screen

Part 2:
- double check the SP for how the look up is done by tag to make sure we are 
doing the right thing.

Original comment by stuartmo...@gmail.com on 20 Jun 2011 at 3:55

GoogleCodeExporter commented 9 years ago 
Notes:

- user cannot define #RES, #COM, #IND tags (defined by system)

Scenario A:
- no zones
- study region: default zone = res
- user adds traffic count, tags it as res
- backend system must calculate reserved word tags as 

differences between udf and reserved
- user doesn't type them in
- user cannot assign road segment to reserved word
- road length calculation is different (based on area/blocklength for all zones 
with same type)
- assign gps points: if not on road, then it goes to zonal tag () -- already 
implemented.
- use labels: "Residential", "Commercial", "Zones" but tie them to a specific 
study region

Original comment by stuartmo...@gmail.com on 22 Jun 2011 at 7:18

GoogleCodeExporter commented 9 years ago 
Part 1 fix is in Revision 044cd72dac72

- On study region creation, add 3 reserved-word tags to the region
- In UI, don't show reserved-word tags on Tag>Tags or Tag>Roads, but allow
reserved-word tags to show up in Analysis>VehicleFlow>TrafficCount so that user
can tag a traffic count with reserved-word tags

This Part 1 fix does NOT address any calculations using these new studyregion-
specific reserved word tags. Watch for those in a subsequent fix.

Original comment by stuartmo...@gmail.com on 22 Jun 2011 at 9:20

GoogleCodeExporter commented 9 years ago 
Notes for debugging and eventual fix. Cleaning up debugging and checking in 
changes shortly.

Original comment by stuartmo...@gmail.com on 23 Jun 2011 at 9:14

Attachments:

GoogleCodeExporter commented 9 years ago 
This is "Part 2" of this defect. The changes have been made to the stored 
procedures and the divide-by-zero defect while updating the 
speeddisttrafficflow table has been taken care of. No remaining work on this 
defect.

Fixed and checked in to Revision f2893544f5a0.

Original comment by stuartmo...@gmail.com on 23 Jun 2011 at 9:30