| Author |
Messages |
|
jswilkerson
 |
| 12/21/2006 4:28 PM |
 Alert
|
As usual, I don't know if this is the right place to post something, but here goes. I am unsure what to do with multiple datasets that reflect the same class name in SDSFIE. I ran across this when the client had maintained a copy of elevation contours that were clipped to the installation boundary, and then the same level of contours farther out. I only kept the contours that went farther out as they would also reflect what was available inside the installation. I wonder what I would have done if I had one set of contours at 5m, one at 10ft resolution, etc. Now I am faced with something similar, in that the client has road centerlines for the roads within its installation, and ones for the State of California, the regional area, the county area, etc. These are from different origins and of different resolutions (spatial and temporal). So, what do you do with these. I don't want (I think) to add them all under "road_centerline" (trvehrcl) as they are different resolutions, but I don't see where else to add them. Is it acceptable to have a "road_centerline" for the installation, and a "road_centerline_california" for the state? I think having these different views is a hold over from having slower systems (hard drives, bus speeds) and slower networks, but that may still be an issue in places. Also, it may be necessary to have the larger road networks available when you are working on more regional mapping. My only thought is that the networks could all be combined somehow, with the best resolution being the default in those areas where it exists. This could be pretty difficult in some instances however. Anybody have any ideas?
|
|
|
|
bschimpf
|
| 12/23/2006 10:32 AM |
Alert
|
Let me offer a couple of ideas. I have been associated with GIS and the SDSFIE probably as long as anyone, but I must emphasize that although this is posted under a forum called policy, the reply is much less policy as it is my thoughts on the topic.
First, there is really no current policy that covers your situation. So, we are free to innovate a little. Second, the purpose of the SDSFIE is to facilitate the sharing of data, both upline and across installations, so as long as we keep that in mind, we may actually move in the direction of policy.
Generally, what you are describing is sort of "installation and surrounds"; e.g. where you have a dataset for your detailed area of interest that is either presented on a map or connected to a network that is the vicinity of your detailed area of interest. For sake of clarity, lets call these INTERNAL; e.g. inside your specific area of interest, and EXTERNAL; outside your specific area of interest. In most cases (although not all) your EXTERNAL datasets are probably obtained from another source. This means that you probably do not actively maintain these datasets but periodically refresh them from that source, or they are really not maintained at all. Again, generally, your INTERNAL datasets are the ones that you maintain. Therefore, you add value in that maintenance, and those are the ones that are of interest both upline and across. These are the ones that are of primary concern to the SDSFIE. These should be named in accordance with the SDSFIE naming conventions and/or have attribution consistent with the SDSFIE.
Other datasets can be kept in other repositories. I would put these in places (perhaps Geodatabase Personals, other Oracle Spatial Owner, or GeoWorkspaces) where they could be used on maps but are not kept as a part of the "official" installation dataset. They can retain their original names and structures, since they can be changed in the legend of your map. If others are interested in this data, they would probably be better going to your source, since you are really not adding value. If you are adding value, then you would want to consider bringing that data into your INTERNAL dataset, keeping it in the same Feature Class as your INTERNAL data.
Hope this helps. |
|
|
|
Jacaruso
|
| 01/19/2007 5:07 PM |
Alert
|
In response to a previously posted message concerning loading multiple features into the same feature class. I ran into this a while back and was also unsure how to handle it. We had surveyed a number of ecology_reef_habitat_areas for one project in the northern portion of the district. Later that same year we surveyed several more ecology_reef_habitat_areas in the southern portion of the district. As I said before, I was unsure how to handle this, when suddenly a light bulb came on....this is Enterprise GIS! This is operating in a single data model!
I loaded the second data set into the same standard feature class and added the project_id field. I populated the project_id field with the appropriate P2 project number. I then created layer files (.lyr files) for each data set by using a definition query for the project_id and date_surv. The layer files are stored in a directory structure that uses SDSFIE naming conventions. The layer file names reflect a combination of SDSFIE naming and project/survey date. We populate the metadata and publish it to our metadata service so that it can be discovered by geographic location, content theme or keyword as well.
But the main point is this. Store all of the data you collect and maintain in an SDSFIE compliant geodatabase and use layer files and definition queries to extract individual features stored in the same feature class. Doing this insures your data model remains consistant as your data stores grow.
Note: I did not invent this technique. I'm just passing on some lessons learned. |
|
|
|
sancho
|
| 04/18/2007 1:38 PM |
Alert
|
| This technique also works well for overlapping geometries within the same layer/feature class. For example, when modeling airfield imaginary surfaces in SDSFIE, the graded area and primary surface at each end of a runway overlap. Presenting this in a web service or printed map posed problems as you would have no control over the order they were overlayed or rendered. By using definition queries/layer files I was able to ensure that the graded area always rendered on top of the primary surface. |
|
|
|
jswilkerson
|
| 04/18/2007 4:08 PM |
Alert
|
| I think there have been some good responses to my original question, and I wish to thank all who have taken the time to reply. When I look at the structure of say TRVEHRCL though, there doesn't seem to be a field to record data accuracy, whether temporal or spatial. One could use the User_Flag field I suppose, but that seems more of a surrender than a solution. Even when I look at the lfhypcnt definition (Elevation Contour), there is really no field to record the accuracy of the data, except for placing it into the user_flag field. In the case of who maintains the data, the State vs. the installation for example, I can see how it would be best to not save a copy of the data locally, but access the external data whenever it is needed. I can also see where this would not always be feasible (network problems, NMCI access limitations, software limitations, knowledge of data locations and access procedures, etc.) and it would be beneficial to have a local copy, whether it be out of date or not. I can also see where this data should all be integrated, called out in the geodatabase by a specific value(s) in a specific field(s) (but hopefully in something better than "user_flag"). I can also see where this is logically leading, to having individual entities maintain there own data, allowing access through a Web Feature Service (WFS) per chance, with security controlled via the access protocol. This mean that we wouldn't have to know if it was the most recent, it always would be. We would know who was maintaining it and its spatial accuracy before we accessed it, and there would never be a need to store it locally. If the network never went down, and the access allways worked, and the speed was fast enough, and we all used the same specifications (SDSFIE?), etc. |
|
|
|
dcakins
|
| 06/26/2007 5:36 PM |
Alert
|
We still have the original problem of how to store datasets that overlap spatially. In our case, we have area A that has a class 2 survey with 2 foot elevation contour lines. Now we have area B that is completely contained within area A that has class 1 survey with 1 foot contour lines. We cannot store them both with an SDSFIE compliant name because SDE won't allow it. We cannot cut out the class 2 surveyed area and replace with class 1 survey at a different scale.
Now suppose we have a class 2 survey from two years ago on area A. Today we have a class 2 survey on area B that is adjacent to area A. We can merge the contours into a common dataset, but now we cannot store appropriate metadata becuse we have a single feature class and can no longer spatially seperate the metadata files. We cannot store both datasets and still be SDSFIE compliant. We cannot store both datasets with an SDSFIE compliant name in different feature datasets either because SDE won't allow it.
Suggestions? |
|
|
|
|