Modify public data source editor

[lbross]

Add a data layer type (required). Valid values are: temperature, slope, elevation, precipitation, other. Dropdown in alphabetical order. No longer need unit type on interface or checkbox. Move data layer type above name. No default value but data cannot be saved without a value. Unit dropdown depends on data layer type and position below Source:

[lbross]

Also have jh_coef data type. If this is selected display 4 radio buttons for Jul min/max, Aug min/max. Determine fixed layer names for each role. Code that catches duplicate names will catch duplicate functions.

[lbross]

1. JH_Coef_Aug_Tmax
2. JH_Coef_Aug_Tmin
3. JH_Coef_Jul_Tmax
4. JH_Coef_Jul_Tmin

[lbross]

I still plan on making the changes but noticed yesterday that the units tags were already in an older set of jh data that I had. If the units tags are applied to the jh data layers before the data bin is distributed, it would be one less thing for the users to do.

[lbross]

We already have a LayerType property in the DataSource object to indicate raster/vector. We will call this new field: LayerRole. Can a dataSource with a LayerRole of "other" have units? If yes, how do we filter the available units since Unit Type is to be removed?

[jdduh]

If a source data layer in the databin has predefined unit type and unit, then the data manager GUI should correctly reflect the layer's tags while still allowing users to update the tags. Now that we will use the predetermined layer names to find the JH_Coef temperature layers, then we can go back to our original unit types (layer type) design. Ignore the "other" layer type. I think we decided to provide predetermined layer names for JH_Coef temp layers, BUT still allow users to change the name(?)

[lbross]

So we should keep the current gui but add fields so that the user can specify the JH_Coef temperature layers? Do you want to move the positions of anything on the form? Like put the unit type or jh_coef controls closer to the top? And yes, we did decide to pre-fill the layer names but allow the user to change. I will be using a separate property when calculating the JH_Coef.

The current form:

[lbross]

Proposed UI changes:

[jdduh]

How about this?

[lbross]

This could work. The phrasing seems awkward for one of the measurement units: depth. But that is a small detail. I'll post a screenshot later.

[lbross]

How does this look? Need more details on warning message. Do you mean we warn the user that we are changing the name to the standard name for a jh_coeff layer?

[jdduh]

Or we can grey out the Name and Description fields if any of the 4 JH_Coef temp option is selected. We need to provide default text for the descriptions. The description shown in the screenshot looks good. I still prefer placing the name below Unit and above Description. This guides the user to make a decision on the data type before they start typing the name.

[lbross]

Missed that the name was between Unit and Description in your mock-up. I will fix that.

The important question is if the user should be able to modify the Name and Description for JH_Coef data sources. If the answer is yes, then a warning that we changed what they might have typed is a better way to go. If a field is greyed-out, that means it is read-only. Note that only those with the admin password can change these fields.

[lbross]

What do we do if someone changes from one of the JH layer types to other temperature? Do we change the layer name of descr so it doesn't reference JH?

[jdduh]

How about just clear the name and description fields? This forces the user to type a new name.

An issue (un)related to the admin interface is that when users try to edit the data manager entries with the non-admin interface, they don't have the ability to modify (or view) the unit information. Please allow modification when editing the entries.

[lbross]

In the updated UI, the non-admins can view the unit information. Do you want them to be able to edit it as well?

Also, still need to know if admin users should be able to modify the Name and Description for JH_Coef data sources

[jdduh]

Make the unit setting editable only when users select a new data source. Please keep the original unit values as the default values.

Admin users cannot edit the name and description fields for JH_Coef data sources.

[lbross]

Still not clear on what access non-admins should have to the unit information. Non-admins do not have the capability to create a new data source so we can't add this capability to new data sources. Are you requesting that they be able to add units if they are missing from a data source? Note that this only applies to the public data manager. Unit information is not available at the aoi level.

[jdduh]

Ok, keep the data type and unit locked for the non-admin interface. We must let the users know that if they try to use a new dataset that has a different unit, then they need to use admin interface to replace the dataset. The non-admin interface is only for "correcting" errors.

[lbross]

There is code in place, when a data source is added, to check for measurement unit conflicts. If BAGIS-P is used to edit settings.xml, it "should" be impossible to add a new dataset with a different unit. I updated the message that checks for this to reference the administrator interface.

This was a complex enhancement so I am not closing until it is tested. I am also holding the changes on a branch called issue_8. I will merge into master when it is working as desired. New version of add-in posted under release 1.8.0.

[jdduh]

In non-admin interface, data manager doesn't show the correct data type when editing the JH_Coef PRISM temperature records. The data type shows undefined for these records.

[lbross]

The data manager for non-admins does show the correct data type when editing the JH_Coef records in release 1.9. Note that a prerequisite for correctly displaying the data type is that the client is connected to the data bin. The units are stored in the data layer itself so if ArcMap doesn't have access to the data, for example on an external or mapped drive, the data type will show as undefined.

Also note that jh_coef layers have to be expressly identified as such using the radio buttons. Although they currently have a read-only standardized name, the design saves a jh_coef role in the data source definition and updates it using the radio buttons. This means the names could be user-defined at a later time, if the requirements change.

[jdduh]

This turns out to be a bug. With 1.9, non-admin interface, when specifying the source of JH_Coef layers without the capability to change its type to one of the four predetermined types, then these layers are not valid for JH_Coef calculation when clipped to the AOI. The only work-around is to use Admin interface to reconnect the PRISM data sources.

[lbross]

Earlier on this thread, you requested to leave the non-admin interface locked and indicated that they would need to use the admin interface to replace the dataset. It sounds like this is not working well in practice.

Please confirm that you would like non-admins to be able to change the data type, unit, and jh_coeff role. Note that this means there would be no difference between admins and non-admins when using the data source editor. However, non-admins will still be unable to add or delete data sources.

[lbross]

I think I just saw part of the problem. When the path to the data layer is changed, BAGIS-P doesn't query the new metadata to set the data type and unit. If we fix this and want to assume that if the data is temperature data we want to maintain the existing jh_coef role for the layer, than we may not need to let non-admins edit anything besides the path on the data source. This will allow them to fix the path from their machine which may be the problem. Thoughts?

[jdduh]

That's exactly the software behavior I tried to describe. It looks like we need to record the datatype information in the settings.xml file to achieve this.

[lbross]

No. We just need to query the metadata of the data layer that the user selects for the data type and unit which we weren't doing previously. We chose to store this information in the metadata rather than in an external file (settings.xml) so that it could be accessed by both BAGIS-H and BAGIS-P. I have fixed this in the code and it will be part of the next BAGIS-P release.

The updated code also carries forward the jh_coef role from the old data source definition if the newly selected layer is a temperature layer.

[jdduh]

If we have a new databin with new PRISM layers, then the datatype information won't be stored in the metadata of the data layers. In this case, users must have the ability to update the datatype information when linking the data source to its definition.

[lbross]

But the new databin should come from PSU, or an NWCC administrator. If the datatype information is stored in the metadata BEFORE the databin is distributed, the users shouldn't have to update the datatype information. It will be easier for them.

I can remove the non-administrator version of the data editor, if needed. Given the new information we received on the aoi jh_coeff if we no longer need the jh_coeff radio buttons, I'd prefer to make all the changes at the same time.

[jdduh]

Let's wait until I get the additional ET and solar radiation data from George. Each dataset has 12 monthly layers.

[lbross]

I would like to publish a new version of BAGIS-P that includes the fix for querying the metadata (units) when the user picks a new path for an existing data source. Before doing this, can you tell me if you prefer the scrolling status bar or spinning graphic as the processing indicator on the Export Parameters screen?

There are currently 2 versions of the add-in on the releases page for v 1.9.1 to demonstrate each option: https://github.com/PSU-CSAR/vb-bagis-p/releases/tag/1.9.1

[lbross]

This is done. There is another issue for for the PE and OBS tool.