| Author |
Messages |
|
tiptuffer
 |
| 07/07/2008 2:27 PM |
 Alert
|
Alright, here's the deal. We're trying to create a flora dataset for forest management. The SDSFIE standards for the fauna entity set are lacking considerably for this application.
Background info: All these SDSFIE standards are new to me because I am supposed to be the lowly intern, but 2 weeks after I was brought in, my boss quit. Now, I have to figure out all of these things for myself.
Now, my forester comes in, and he thought that I could add fields to the entity types (which I am confused on why they are not called feature classes) because he swears the previous GIS manager had done it. So, I've been researching it and trying different things with the browser, and I tell him that you can't because they are STANDARDS. Am I right?
The reason that we need to add some fields is that he is interested in not only the dominant species but also the codominant species. He also needs the heights of poles, pines, hardwoods, and saw timber. Also needed is the volume measurements by timber products not in a percent. The SDSFIE includes the overstory and the midstory, but he needs the ground cover species as well. These are just a few examples that are nowhere to be found in the standards, and I don't know what to tell him. We need this data for forest management, but we need it to comply with SDSFIE standards, so I feel that we are stuck.
Am I right? Are we going to be able to do this with SDSFIE standards? |
|
|
|
bschimpf
|
| 07/08/2008 5:06 AM |
Alert
|
While I sympathize with your situation, my focus will be strictly on the SDSFIE. The content of the SDSFIE; e.g. the Features, Attributes, and Values are intended to be 1] vendor neutral, and 2] provide fundamental GIS data capability to most users. So, to begin...
The use of the term Entity Types dates from 1993 and represents the third level in the hierarchy
Entity Sets - broad theme categorizations (utilities)
Entity Classes - sub-categories of Features (utilities - water)
Entity Types - feature types themselves (water_line)
The term "Feature Classes" has evolved since GIS systems gained the ability to classify features within a single dataset; e.g. Geodatabase, Geodataset. Broad usage started with ESRI, with the beginning of ArcGIS.
What you are actually addressing is called the "extension" of the Standard. There are several reasons for a Standard. The two most commonly quoted are "Data Sharing" and "Standardized tools and Training". In the earlier versions of the SDSFIE, extension was not forbidden, but was discouraged, because tools were not sophisticated enough to accommodate the flexibility required for extension.
Without knowing more, I would suggest this.
1 - Get a clear picture of the requirement,
2 - Determine whether the data you desire can be accommodated with other Entity Types; e.g. if you want to know what is on the ground in the forest, maybe you use another class, map that, and then take intersections of polygons to get what you want.
3 - Extend the SDSFIE
The SDSFIE is a DoD Standard. Details of implementation for DoD are on the basis of the Service Lead, who determines the policy for implementation. Outside of DoD, users are on their own for policy.
Help Desk |
|
|
|
tiptuffer
|
| 08/04/2008 7:17 AM |
Alert
|
| Ok, follow up question. What I am going to need to do is to create seperate tables to link the information not included in the SDSFIE standards to the shapefiles in the geodatabase. Now, in the past it appears that they have just added these tables to the geodatabase. Is this acceptable or unacceptable? Should I place this table inside or outside the SDSFIE compliant database? |
|
|
|
bschimpf
|
| 08/14/2008 12:29 PM |
Alert
|
Keep in mind that we are 'between' Release 2.6X0 and 3.0. If you are doing this in Release 2.6X0, you can put the 'extension' tables inside the geodatabase. That way you can create Relationship Classes and, using the Primary Key, link them. This makes the two table potentially appear as one in ArcMAP. It is called a "view".
In 3.0, you could add the attributes you want to the base SDSFIE tables, provided you 'registered' them on the SDSFIE.org web site. Over time, as we see who is adding what to what, we can make more intelligent decisions about what should become an "official" part of the standard. |
|
|
|
|