During the course of our project work, we encountered limitations that prevented us from achieving some goals that we originally planned to conquer. Problems pertaining to the geodatabase, user interface and ArcIMS viewers were all present during the course of our project. These three stages of our project will be discussed on an individual basis.
The first major problem encountered was the data conversion out of the Beyond 20/20 software. Many of the tables are quite large, such as that of Labour Market Activities at the Enumeration Areas level. Due to a 64 megabyte size, it took approximately 4 hours to convert this data to either a .csv or a .dbf file. This became a major hinderance based on the fact that data conversion was a regular routine to accomodate database structure changes.
During the conversion process, more problems arose. Fields names were truncated, which was caused by the limits of the .dbf file type that can only handle up to 12 characters. Field names were then changed to Col_1 , Col_2 etc. using Excel templates. The creation of look up tables was then required so that the user may be able to identify the original field names. Conversion in and out of programs caused additional problems regarding the size of our database. Data types converted often defaulted to Double, which is the largest storage type, using 8 bytes. This worked to double the size of our database which then poses time hinderances on any future user of the database.
Size once again became a problem as we discovered limits of software that we were using. Categories which contained more than 256 fields exceeded limits of Microsoft Access and the reduction of our database into multiple datasets was needed. These subsidiary components were then agglomerated at a later time in ArcCatalog. If Oracle or SQL server were available to us during the duration of our project, this particular problem could have been avoided.
Lastly, the Census Tract level of agglomeration posed a rather obscure problem during geodatabase construction. Many of the unique identifiers within the attribute data did not match those in the spatial data. The ID field as a result had to be concatenated with the CMA ID field. This was achieved by writing scripts in Microsoft Access.
There were some drawbacks that took place as interface design proceeded, particularly related to the ArcObjects environment. Limted programming skills in an object-oriented environment resulted in the limited use of ArcObjects. The software offers a multitude of functionality for querying spatial data, extraction and creating complex functionality. These factors led to the use of Visual Basic functionality for ADO objects.
anchor
Three major problems came to the forefront as the ArcIMS portion of our project began to develop. The first problem was the excessive number of Enumeration Areas that exist in British Columbia, Quebec and Ontario. JavaScript errors were encountered by the Internet browser when loading of these three provinces was attempted. The shapefiles seem to be a hinderance in terms of data type and do not load efficiently even with current computing power. Loading these shapefiles through a direct ArcSDE connection was attempted but with no improvement. This problem could possibly be rectified with the conversion of census spatial data to ArcSDE coverages. This was not tested due to time constraints and the potential for no return on an excessive amount of work. "Splicing" the shapefiles into quadrants was another possibility but did not seem feasible due to the extremely close proximity of one EA to the next. Therefore, creating four shapefiles for each problem province did not seem like an efficient solution to this problem.
The second hinderance we encountered with our web mapping extension was the linking of our census maps directly to our VB interface. Shortly after the completion of our census area maps we realized that the process of facilitating user-specified data download directly from IMS was a formidable task. The lack of formal experience with virtual Extract servers and the ArcSDE connection added to this frustration.
Lastly, as we got to know ArcIMS and its capabilities through everyday use, it became clear that the software itself has many limitations. Many features that one would assume are inherent within a web-based GIS were not present. Examples of this include the option for an Internet-based open menu or an easier implementation of hyperlinking within the Java Viewer. In hindsight, it seems as though ESRI has made up for many limitations in ArcIMS with the ease of customization to realize many additional functions.