MLRA REGION 10 NEWSLETTER--MARCH 1, 1999 EDITING TEXTURES IN NASIS In NASIS, the "Tex Mod & Class" data field in the Horizon Texture Group Table is not directly editable, but is actually calculated. To do this calculation, insert a new row in that table, then go down a table to the Horizon Texture Table. If the new texture has a modifier (such as GR), then go down one more table to the Horizon Texture Modifier Table. Insert a new row in the Horizon Texture Table, then go to the "Texture" data field and enter a texture (choice list is available). To add a textural modifier (if needed), go to the Horizon Texture Modifier Table, insert a new row, and then enter the modifier in the "Modifer" data field (choice list available). Now go back to the "Tex Mod & Class" data field in the Horizon Texture Group Table. From the top of your NASIS window, click on "Options", then "Calculate Data Elements" to open the "NASIS Calculation Manager" window; there is only one selection for this calculation, so click "Apply"; in a few seconds, the "Tex Mod & Class" data field will be populated with the texture and modifier you placed in the Horizon Texture and Horizon Texture Modifier tables. Sort of a round about way to get there, but as far as I know the only way to get there--and it works. It also ensures that the same data gets entered into all three tables. Submitted by John Handler, jfh@mn.nrcs.usda.gov ######################################################################### REMOTE PRINTER SETUPS FOR NASIS NASIS provides each office the capability to print reports on local printers. The NASIS 4.0 Getting Started Manual provides (in Appendix C) a step by step set of instructions for "Configuring a Printer". Please note that there are two major pieces to this configuration: 1. Printing to a Remote Unixware System 2. Setting up a user's printer configuration. Item #1 needs completed first before item #2. Item #1 needs to be done only once for each remote computer system; item #2 needs to be done once for each NASIS user on that system. Concerning Item #1, the verbal instructions I have received from my System Administrator is that he prefers to handle Item #1 himself in consultation with your System Administrator. While the steps in Item #1 seem fairly straight forward, there are usually nuances associated with printer setups that are not covered in the instructions in Appendix C. So, when you are ready to get your printer set up, please have your System Administrator call my System Administrator (Rich Dougherty (1-651-602-7904)). Each of them will need to access their respective systems to enter IP addresses, and printer names and ports; this should take about 15 minutes. ***** Until recently, only postscript capable printers would work with NASIS, but NASIS now supports non postscript printers. Sorry, dot matrix printers are not supported by NASIS. Submitted by John Handler, jfh@mn.nrcs.usda.gov ######################################################################### YOUR IDEAS FOR NASIS PREFERENCES ARE SOLICITED I am putting together some ideas for what we are calling "User Preferences" in NASIS for our upcoming release. I would be interested in your feedback on items that you feel are important and ideas for things that you would like to be able to change as a user for your specific environment. Going through some of the comments I have put together an intial list. There are some things that we will be able to allow users to change in their current session of NASIS. Others would have to wait until they exited NASIS and restarted it. Here is my preliminary list, please let me know the level of importance you feel each should have as well as adding additional items. Initial ideas: Nasis resources as organized by tab fields 1. General - Number of rows displayed in a table. - Button labels on toolbar icons, these can be taken off for more screen space. - Change cursors - This option is already in NASIS but not a lot of people know about it and it only lasts for the current session. We could make it more visible and work between sessions. If you have never seen how to change it now, click on the menubar with the right mouse button. You should get a dialog. - Maximum choice list items before search. Change the number of items you want to see in a choicelist before it forces you to search. The current amount is, 100. - Default database for queries and reports. Right now NASIS will bring up a users local database as the default for reports and queries, this would allow you to change this. - Change the text editor. This would allow you to change the editor used for text fields. This would be the use of VI in a Xterm window, the use of the CDE desktop editor, and the current Motif text window. Is there any others? 2. Fonts - Font used for tables. ??? - Font used for column headings. ??? - Fonts for Editors??? 3. Colors???? 4. Parameter Dialog - Option to leave Dialog up for reports - Option to leave Dialog up for queries Both of these would allow you to set a toggle in your environment to leave the dialog up after hitting "Apply" thus allowing you to run the same query or report with different parameters. You would have to hit "Cancel" for it to go away. Thanks for your input, if you have questions on any of these please let me know. From: John Miller, jmm@gonzo.itc.nrcs.usda.gov ######################################################################### DATABASE UPDATE FROM MLRA-11 (Indianapolis) 1. nasisclient is functional with some limitations. A. You can get up-to-date information from the entire country by typing nasisclient instead of nasis at the prompt. This starts a read only session directly with AMES IOWA. At this point you are connected to replicated data from 16 of the 17 MLRA-Regional offices and a regularly refreshed copy of Alaska's data. B. Reports and queries from any MLRA office can be run using naisisclient, with the following conditions. a. If reports are written autonomously with all internal scripts they will run fine. b. If reports call on properties using the derive statement they generally will not work. These reports must be run locally. (I have not done much experimentation with this, so you will need to request assistance from other more experienced users if you need to test or evaluate one of these reports.) c. As always, many reports are under construction. During construction a report may work one minute and then fail the next. In the case of MLRA-11 we plan on making backup copies of each of the major reports that we are working on. If a local report does not work, you should try the report (backup). The backup will be the last working version of the report. I will try to put a date in the name of the backup to indicate when it was made (even though there is a date field as well). d. Since nasisclient is a read only function those text fields which indicate that you may comment will not be editable. Please include a phone number in reports that are under construction, for which comments have been solicited.(MLRA-11 office only). e. If you made a report you must have had a good reason for making it. Please use the description text field to describe how to run the report and the best use of the report. This may save someone else some time by preventing them from writing their own reports. 2. FOTG reports are being written for Indiana. If other states could use these reports please review them and make suggestions. Each of the manuscript reports are being given revised headings to correspond to FOTG specifications. Note that a fixed data and initials field is being populated using the legend text note with category, initials, and subcategory FOTG heading. The note itself is 11 characters or less and is formatted HJF 1/11/99 3. Backups of all legends were created 12/5/1998. These backups belong to a group called backup and can not be edited by the states or field. These backups are for your safety and you should disregard them until you need them. Use the local query to load legends without backups if you wish to run local reports on your legends. National reports are designed so that they do not see the backup legends. 4. You can make your own backups. I have created several area types called backup (group name) . In order to make your backup you will have to add a backup area symbol and area description. I am anticipating that 100 percent of the legends shall be backed up and only .2 to .5 percent of the data mapunits (or less) will be backed up. IF anyone from another MLRA office is interested in backing up your data, or if you have data in more than one MLRA office, you must contact your own regional office to see what their policy is. Some machines may have space limitations which preclude the possibility of backing up very much data. Once again, I anticipate that less than 1 percent of our data mapunits will ever be backed up. I generally volunteer to help each project office back up the data mapunits for the 1st survey that they edit. After that they are on their own. Note that once a survey is complete and a SSURGO download has been performed, all backups of data mapunits should be removed to make room for backups of other current surveys. Also note: as MLRA, State, and Regional legends are developed, I anticipate backing up data mapunits which are being developed as the "standard" data mapunits. It is anticipated that these data mapunits will have extensive notes concerning laboratory data, investigations, and correlatons associated with them. These data mapunits will be linked to multiple soil surveys, and will be particularly difficult to recreate should they be deleted by accident. (This will be the equivalent to backing up the old S-5's) 5. Bob can print remotely. Why can't I? I have set up printers for some individual accounts for some remote offices. However, printing functions are account specific so the printer will have to be set up for each individual in the office in order for everyone to print. (Also note that directions for remote printing are provided in the NASIS help system) A very simplistic description of printer setup follows. Note that you may have to do some trouble shooting if your printer does not work right away. Also note that anyone can set up their own printer. It does not take an IRM individual to set up a printer for you. All the commands can be contained within your own home directory and there is no need to bother an IRM individual with the details. Printer setup for LAN-WAN offices with a SUN, UNIXWARE, or HP as printserver. 1. In your own personal directory you must have the following file. file name: .rhosts permissions: 6 0 0 content syntax: IP address login (on NASIS machine) IP address login (on home machine) Content example: 165.221.41.200 hferguso 199.151.42.23 henry This means that my login on the NASIS machine is hferguso and the IP address is 165.221.41.200. My login on the home machine is henry and the IP address is 199.151.42.23. Once I make a file called .rhosts and include these two simple lines, and give it the 6 0 0 permissions the home side is all set up ready to print. On the NASIS side you have to set up the printer. Directions on how to do this are in NASIS help and in the NASIS 4.0 and NASIS 3.1 manuals. Trouble shooting. Look at the xterm screen behind your nasis session. If it says request ... then your request was really sent. Look around your office. Maybe your job printed to a another printer in your office. If paper is coming out of a printer and it looks bad, you have made a poor choice of devices. You need to associate a different device with your printer port and try again. If it does not say request ... then your job never went and there may be a permission problem. You can double check your .rhosts file and verify it is 6 0 0. If the rhosts file is ok you need to contact me so that I check your permissions on the HP9000. 6. Refresher. I try to start NASIS and it will not let me in. What should I do? The most likely problem is that your password has expired or your account is disabled. You can not change your password using exceed. You must start a standard telnet session. You will be told that your password has expired and you will be asked to change it. The next most likely problem is that you may have tried to login with the caps lock on. Once you have failed several times your account is disabled. You must call your system administrator (me for MLRA-11) for your account to be enabled again. Another likely problem is that your network may be down. Try a simple telnet session to see if you get a login prompt from 165.221.41.200. 7. On-site reviews of most NASIS sites in the region have taken place. Most individuals are very satisfied with the performance of NASIS at their remote site. Some individuals will be seeing better performance as lines are upgraded within the state of Indiana. 8. Update on local plants tables. The number of duplicates has been greatly reduced in the local plants tables. We have reduced from a list of over 1100 individual plant symbols to less than 655 plant names. This should make editing of the Component existing plants, Component Potential Windbreak, and Component Trees to Manage tables much easier. The Component Forest Productivity Table will still be a problem since a hidden table makes it impossible to reduce the local plant symbol choices for this table. 9. MLRA Region 10 and 11 SDQS are continuing to develop guidelines for NASIS 4.0 text notes. This will allow soil scientists to capture and generate documentation of correlation activities for SSURGO and update soil survey activities in NASIS. 10. Please review the permissions on your legends and data mapunits. During the course of the scheduler download and subsequent editing of legends, permissions on some legends may have been changed. It is important that we maintain the proper authorities as well as keeping the correct number of legends. If you can not get into a legend that you think that you should be able to edit, DO NOT make a copy. It is very important that you track down the permission problem, resolve it, and edit the original legend rather than to make a copy. The only copies that you are encouraged to make are backups and as always, backups should never be edited. From: Henry Ferguson, hferguso@in.nrcs.usda.gov ######################################################################### OFFICIAL SERIES DESCRIPTIONS & "NATIONAL STANDARD" DISCUSSIONS Yes we will slowly lose series integrity if we don't recreate the series standards in NASIS that we had in SSSD like your MO is doing. We really need to be using the power of those 17-$70,000 computers to recreate the series standards since this was not provided for in the SSSD to NASIS conversion. I could not convince SBAAG that this was an essential issue that needed immediate action. Bill Puckett will be talking about standards to the MO leaders. You may also want to send this to everyone in your chat room so they can communicate the importance of recreating series standards in NASIS to Bill also. The MO leaders have the power to make resolving this issue a high priority. Aggregation tools to recreate series and phase datamapunits or data records and compare tools in NASIS are what we need to be able to efficiently recreate series standards. NASIS will handle series standards whether an MO wants to use them or not. I can understand why the mountainous west may have felt constrained by series standards on the soil interpretations records in SSSD in the past, and might be against a so called National Standard whatever that would have become. I am not sure a national standard is the answer either. I think each MO needs to decide what data elements in NASIS should be series criteria and be able to create and display those in an efficient manner by aggregating and comparing datamapunits of known quality. It is important we have the tools in NASIS to recreate MO Standards for soil series and phases of soil series in NASIS so soil scientists in the field can know the quality of the datamapunits they are copying and how far their components in datamapunits are outside or inside series standards. I firmly believe in populating data in the field based on what is actually on the ground but we don't have the time or the personnel to be populating each data element in NASIS by hand. We have to copy and paste datamapunits and edit them. Right now, people in the field have no good way to assess the quality of a datamapunit someone else created or edited. If they copy and paste they are doing it blind. I could be wrong, but I think we lost the capability to paste soil data with known and well advertised quality with SSSD to NASIS conversion. I was not envolved, but I believe this happened because the committees assigned to discuss a national standard for soil series could never agree whether we needed it nor how to do it. Reorganization probably was a factor also. I'll hop off of my soapbox now but this may be the only opportunity I have to give Bill some more material for his presentation. I believe this is one of the most important issues that needs to be resolved in the National Cooperative Soil Survey. It is at the heart of the quality of the data we deliver to users. If we don't resolve it soon, soil data quality will surely erode nationwide. From: Wayne J. Gabriel, MO 9, wgabriel@tx.nrcs.usda.gov To: Paul Finnell, MO 5, prf@ks.nrcs.usda.gov * * * * * Maybe it would help to dump that term "National Standard" which seems to cause such a fuss. It appears that what you are talking about is the need for some kind of data entity in NASIS which caries the data ranges for a given series (or phase if needed) and provide a base from which to judge whether a component fits the series in question. Don't get the idea that the "west" does not follow the standards in maintaining series ranges and usage. I know we maintain series integrity and am sure my neighbors do too. Every component is carefully scrutinized to make sure it fits within series concepts. That integrity is and always has been maintained. But I understand the need to have a basis to compare component usage to the growing number of data elements which may not be directly expressed on the OSD. But the SIR was an "Interpretation Record" and not really a very good database for maintaining series data. So let's move on, the SIR is gone. Let's use our new toy (NASIS) or better yet develop new tools in NASIS. We make use of spreadsheets reports from NASIS which can display the data for all components with a given series name (depends on the selected set). This enables the correlator to view the data and compare it to the OSD to be sure it is being used correctly. What may be missing is a database generated data line for the series (which could be displayed at the top) to compare all component records against. We can easily "trick" NASIS by creating a particular datamapunit by a series name and populating it with the full ranges of series data (or phase if you wish .... or both so you can compare the phase data to the series ranges as well). Any number of reports could then be developed to display this data any way you desire. But we have a misnomer because this would not be a true "datamapunit". Depending on how you want to use it, you could use that series or phase data entity for the basis of your copy/paste methodology. I would rather use actual data gathered within a survey to populate the component data. Right now, that data has to be manually aggregated to record the correct data ranges for the component in question. A concious effort by the soil survey team must be made to review all pedons and field data to determine series/component usage. Since all holes do not fit nice and pretty all the time, some hard decisions and choices have to be made (as it has always been and always will be .... this isn't rocket science, it's harder). I certainly do not intend to just copy from a "standard" and use it without further editing to reflect the actual data within the mapunit. It needs editing to truly reflect the real component data collected on the ground. The component has a more defined set of ranges than both the series or phase. Anyhow, let's dump that term "National Standard". 1) it causes unneeded heart palpatations in some soil scientists, and 2) you are right .... it is the MO which decides the ranges of data for the series not some national watchdog. Maybe just call it what it IS ... "series standard" or "series phase standard" (which readily distinguishes it apart). We are more on the same page than we think. I am cautious about data aggregation because we can never expect a machine to effectively make the decisions a skilled soil scientist can make, but some kind of tool to display the data to HELP us make these decisions would be nice. It could also be used to aggregate data from datamapunits for general soils map units or STATSGO data in the future. Thanks for the discussion. -- Kit Paris SDQS Pacific SW MLRA Soil Survey Office Davis, CA kit.paris@ca.usda.gov From: Kit Paris, MO 2, Kit.Paris@ca.usda.gov To: Paul Finnell, MO 5, prf@ks.nrcs.usda.gov ######################################################################### Last month, the following x3780 files were sent to offices having SSSD: x3780.411frig on Feb 02 (32 updated OSDs) @ x3780.412mes on Feb 03 ( 7 updated OSDs) * @ Sent to offices using soils in the frigid soil temperature regime. * Sent to offices using soils in the mesic soil temperature regime. # Sent to all offices. The above x3780s contained the following updated Official Series Descriptions, which can also be obtained at: http://www.statlab.iastate.edu/cgi-bin/osd/osdname.cgi frigid ...ahmeek...aldenlake...alstad...barto...boyerlake...branstad...brimson...cloque t...conic...cornucopia...eaglesnest...eveleth...freya...herbster...hermantown... karlsborg...lara...meenon...norgo...normanna...pence...pequaywan...perida...port wing...rollins...siren...smestad...solona...soudan...wabedo...wahlsten...wawina. .. mesic ...bilmod...bilson...merimod...merit...newlondon...onawet...reedscreek... ######################################################################## CHANGED ADDRESSES AND PHONE NUMBERS 1. Ulf Gafvert ugafvert@wiashland.fsc.usda.gov Fred Simeth fsimeth@wispooner2.fsc.usda.gov Joe Boelter jboelter@wirhinelan.fsc.usda.gov Stacy Webb swebb@wiladysmit.fsc.usda.gov Bill Fiala wfiala@wiladysmit.fsc.usda.gov Angie Elg aelg@wirhinelan.fsc.usdda.gov Jesse Turk jturk@wiashland.fsc.usda.gov Terry Kroll tkroll@wiashland.fsc.usda.gov Keith Anderson kanderso@wispooner2.fsc.usda.gov Jeff Talsky jtalsky@wispooner2.fsc.usda.gov ######################################################################### ACTIVITY SCHEDULE (through April 15--subject to change) MLRA DATE ACTIVITY LOCATION MO 10 STAFF ---- --------- ---------------------------- ----------------- ----------- 88 Apr 05-09 Final Correlation (Roseau) Roseau DesLauriers 90 Mar 22 NW 10 Meeting Ladysmith Jahnke 90 Mar 29-02 Final Correlation (Taylor) Medford Jahnke 92 Mar 30-01 Steering Committee Meeting Ashland Jahnke DesLauriers 107 Mar 09-11 Steering Committee Meeting Omaha Hempel Handler ALL Mar 04 Work Planning Conference Michigan McCloskey ALL Mar 16-18 NASIS Interpretation Trng St. Paul Walker Jahnke Hempel Giencke Handler DesLauriers ALL Apr 14-15 MO 10 Staff Meeting St. Paul All ######################################################################### CONTRIBUTIONS, IDEAS, SUGGESTIONS, AND QUESTIONS ARE WELCOME Thanks to those individuals who participated this month. It is your efforts that are making this newsletter a success. * * * * * Please submit your articles at least five days before the end of the month for inclusion in the following month's newsletter. Otherwise it will appear the following month. Occasionally, due to other workload demands, it may be an additional month before the article appears. Generally, articles are inserted in the order they are received. Articles in an electronic format can be submitted to: jfh@mn.nrcs.usda.gov It is best if electronic articles are prepared in a "text only" format. Articles in a paper format can be sent or faxed to: John Handler MLRA Region 10 Office USDA - NRCS 375 Jackson Street - Suite 600 St. Paul, Minnesota 55101-1854 FAX: 1-651-602-7914 * * * * * This newsletter is intended to be a forum to distribute information of a general nature that will benefit soil scientists in soil survey project offices. It is hoped that it will foster communications and sharing of knowledge among those soil scientists in MLRA Region 10. * * * * * The format of this newsletter is intentionally simple so that it can be received, read, and printed by the project office having the least sophisticated computer setup. #########################################################################