Lab 7: Volunteered Geographic Information (VGI)
Goal
The goal of this lab exercise was to introduce students to creating a volunteer geographic information application that allows the general public to upload features. The lab exercise gave students experience in setting domains and subtypes for geodatabase features, creating a feature template for the types of VGI data that the end-users are supposed to collect, creating feature editing services for the data to be collected, and developing a multi-device responsive interface for the VGI application using the ArcGIS API for JavaScript. The application created should allow the end-user to crowdsource data from the public in Eau Claire, regarding the condition of infrastructure during a one week period.
Methods
In part 1, students were instructed to create a map document that would support the feature services and web editing capabilities. The first step was to set the domains and subtypes for the fire hydrant, sidewalk, and green space features. Domains are rules applied to the feature classes in the geodatabase that make the collecting of the features much easier through the use of coded values, etc. Then, the next step was to create feature templates for the features to be collected. This way, the user can simply select which feature they would like to collect, and place it on the map. Then, students had to create feature attachments. Once these are set up, the user is able to add attachments to the features they collect, such as images of the feature in question. Then the symbology was set for the features, to make it easier on the end user, since the symbols are already selected for them. The map document was now prepared (figure 1).
The next step was to prepare the enterprise geodatabase feature template for publishing. The key for this step was to publish a map service with feature acces enabled. With feature access enabled, the end-users can edit and add features in the application.
The final part of this lab exercise was to consume the feature service in a web GIS application, which involved the use of the ArcGIS API. To access the feature templates in the application, they had to be referenced in the JavaScript by their URL, as can be seen in figure 3. The JavaScript was then referenced in the index HTML document (figure 2) along with the css stylesheet (figure 4). Using JavaScript, a panel was created which held the feature templates that could be added to the map, and that panel was styled in the css document.
The next section involved fine tuning the template picker panel. When the VGI application was launched on a smartphone, the panel took up the majority of the screen, making the application almost useless. This step meant creating a toggler widget, which would toggle the template picker panel between being visible and invisible, so that when the feature is being created on a mobile platform, the user can use the entire screen. The coding for this section was mostly the same, except for some minor changes to account for the toggler widget (figures 5, 6, 7, 8).
This VGI application allows the end-user to crowdsource their data from the general public. Assuming that the public is willing to participate, this method of data collection can be faster and much more cost effective than doing it yourself or hiring someone to collect the data. When the budget is tight, VGI can be the way to save money while still accomplishing the desired goal for data collection.
The goal of this lab exercise was to introduce students to creating a volunteer geographic information application that allows the general public to upload features. The lab exercise gave students experience in setting domains and subtypes for geodatabase features, creating a feature template for the types of VGI data that the end-users are supposed to collect, creating feature editing services for the data to be collected, and developing a multi-device responsive interface for the VGI application using the ArcGIS API for JavaScript. The application created should allow the end-user to crowdsource data from the public in Eau Claire, regarding the condition of infrastructure during a one week period.
Methods
In part 1, students were instructed to create a map document that would support the feature services and web editing capabilities. The first step was to set the domains and subtypes for the fire hydrant, sidewalk, and green space features. Domains are rules applied to the feature classes in the geodatabase that make the collecting of the features much easier through the use of coded values, etc. Then, the next step was to create feature templates for the features to be collected. This way, the user can simply select which feature they would like to collect, and place it on the map. Then, students had to create feature attachments. Once these are set up, the user is able to add attachments to the features they collect, such as images of the feature in question. Then the symbology was set for the features, to make it easier on the end user, since the symbols are already selected for them. The map document was now prepared (figure 1).
 |
| Figure 1. The ArcMap document that would support the adding of features in the web GIS application. |
The next step was to prepare the enterprise geodatabase feature template for publishing. The key for this step was to publish a map service with feature acces enabled. With feature access enabled, the end-users can edit and add features in the application.
The final part of this lab exercise was to consume the feature service in a web GIS application, which involved the use of the ArcGIS API. To access the feature templates in the application, they had to be referenced in the JavaScript by their URL, as can be seen in figure 3. The JavaScript was then referenced in the index HTML document (figure 2) along with the css stylesheet (figure 4). Using JavaScript, a panel was created which held the feature templates that could be added to the map, and that panel was styled in the css document.
 |
| Figure 2. The HTML document for the VGI application. |
 |
| Figure 3. The JavaScript document referenced in the VGI HTML document. |
 |
| Figure 4. The css document referenced in the VGI HTML document. |
The next section involved fine tuning the template picker panel. When the VGI application was launched on a smartphone, the panel took up the majority of the screen, making the application almost useless. This step meant creating a toggler widget, which would toggle the template picker panel between being visible and invisible, so that when the feature is being created on a mobile platform, the user can use the entire screen. The coding for this section was mostly the same, except for some minor changes to account for the toggler widget (figures 5, 6, 7, 8).
 |
| Figure 5. The script for the toggler widget. |
 |
| Figure 6. The HTML document for the VGI application using the toggler widget. |
 |
| Figure 7. The JavaScript code for the VGI application using the toggler widget. |
 |
| Figure 8. The toggler widget for the VGI application using the toggler widget. |
Results
 |
| Figure 9. The VGI application from the first part, with no toggler widget to hide the template picker panel. |
 |
| Figure 10. The toggler widget can be seen in the upper right hand corner of this VGI application. https://gis14.uwec.edu/f17geog455/STRUMBBJ2408/Lab_7/BJS_index2.html |
This VGI application allows the end-user to crowdsource their data from the general public. Assuming that the public is willing to participate, this method of data collection can be faster and much more cost effective than doing it yourself or hiring someone to collect the data. When the budget is tight, VGI can be the way to save money while still accomplishing the desired goal for data collection.
Comments
Post a Comment