Gnats 4315: Name Map priorities aren't sufficiently distinct [URGWOM]

Subject: Gnats 4315: Name Map priorities aren't sufficiently distinct [URGWOM]
Date: Thu, 07 Oct 2010 13:13 -0600
From: Phil Weinstein

I'll need someone else to make the determination of whether or not the relative uniqueness of the automatically computed RootSelection "precision estimate" numbers is now sufficient -- for use in prioritizing Name Map RootSelection items.

These had been improved for this bug (in RW 4.9.2), but I don't know enough about how this is used to know if these are sufficiently unique.

IN MY OWN AREA, I've ADDED two columns of information to show the actual "precision estimate" numbers, and the RootSelection "auto names" which characterize the properties from which those numbers are computed. (They are most interesting in the case of RootSelections with "wildcarded" parts).

SEE this data for an URGWOM Name Map from the (recovered) bug model ... FOUR PAGES:

http://cadswes2.colorado.edu/~philw/2010/bugs/4315/

.. on the fourth page, you can see that the two cases David mentioned in the bug report are now unique ...

CropArea5West (GW5WEST) ... 209C.0000.0000.3E11 ... WaterUser[Name=*West*Area5*]
WaterUserGeneral (GENERAL) ... 200E.0000.0000.3E11 ... WaterUser[Name=*]

But are the generated Priority Codes (RootSelection Precision Estimates) sufficiently unique in general?

My modification to show these additional columns is in this file (not checked in):

/projects/riverware/staff/philw/Four/DbDmi/NameMapDlg.cpp

The recovered bug model is:
Directory: /projects/riverware/builds/models/bugs/Originals.Jan2009/
File: bug4315.mdl.gz

FWIW, the RootSelection "Precision Estimate" numbers are implemented in Sim/RootSelection and Sim/SelectionPart subclasses, in these methods:

RootSelection.cpp: int64 RootSelection::precisionEstimate() const
SelectionPart.Account.cpp: int SelectionPart_Account::precisionEstimate() const
SelectionPart.SimObj.cpp: int SelectionPart_SimObj::precisionEstimate() const
SelectionPart.Slot.cpp: int SelectionPart_Slot::precisionEstimate() const

If the current RootSelection Precision Estimates are suffiently unique, this bug can just be closed without changes. Could someone else make this determination?

A seperate question: Should we provide these additional columns of information, possibly optionally (based on a checkbox menu item), in the actual release?

---