We are currently working through an ArcGIS v9.3 to ArcGIS v10.1 migration of our Regulatory GIS Support System (RegGSS) and have run into a problem when applying a layer file to a data set.
There are two approaches in applying a layer file to a data set either load the layer file directly or load the data set first and then apply the layer file to the data set. In the past, we had run into problems loading the layer files directly where some properties would not get set (especially label properties) so we decided to go with the second option where we would load a data set and apply a layer file. The main difference is that in the first case the layer file cannot have any broken links while the second method does not care about broken links.
At ArcGIS 10.1 however, this approach stopped working. RegGSS uses close to 800 layers files and checking/fixing each one by hand would have been a monumental task in both effort and time. Our solution was to created a C# script to check every layer file for broken links and repair those that were broken or flag them as not-repairable so they could be repaired manually. The general logic is as follows:
- Cycle through all layer files used by RegGSS one at a time and check if the layer file is valid or not by using the Valid property on the ILayer interface of ArcObjects
- If layer file is not valid, read the SDE server name, reset the connection parameters and re-save the layer file.
- Re-check the validity of the re-saved layer file and if it still has a broken link, write out the layer file name to a text file so it can be fixed manually.
You can check out the main procedures here on GitHub.
Carlos Piccirillo, Senior Geographer, Regulation GIS, SFWMD
Juan Tobar, Supervising Geographer, Regulation GIS, SFWMD
This is the 2nd post on building a geospatial data library. Other posts on this topic:
1. Structured Searches in a Geospatial Data Library (with Video)
2. Keyword Searches in a Geospatial Data Library (with Video)
So to recap…
We run into problems when we try to implement any naming conventions on source data:
- More than likely you will run into system imposed limits on the length of the name. For example SDE Feature Classes in ORACLE can be no longer than 38 characters including the instance name.
- Usually, source names are not user friendly and trying to find a particular one from a list of 800 or more can test anyones patience especially if you are not a GIS professional.
- Once a source has been named it is very difficult to rename. Customers will quickly link applications and maps thus modifying a source name become a destabilizing event.
The solution to these issues is to implement standards in a look-up table rather than directly on the source data. In principal, such a system would consist of a parent table containing source information (SDE, services, layers, shapes, covers, etc…) and a daughter table containing your classification schema. A graphical user interface would then provide users with access to the information in the daughter table while a backend uses the parent table to retrieve the data.
The image below is of a geospatial data library my unit implemented at SFWMD. The system was written in C# as an extension to ArcMap. In the video the structured searches are occuring through the daughter table.