I'll just admit. I have slept since phase 1 was live and active. The number of issues we had with it were insane. They were frustrating and annoying and we couldn't seem to find answers. However, we were able to overcome and our ParksFinder works as expected now.
Our site is live, but not. http://maps.cityoftulsa.org/parksfinder/
You can visit it, use it, but the public has not been made aware yet because according to the Parks department they don't have the data ready for public consumption yet. Frustrating but I get it.
So why am I posting a phase 2 when I can't even remember the issues we had? Because I can remember the files that we had to adjust to get things rolling. So I wanted to share those here. I'm also going to try to break down some of the other issues we had based on my (already confessed) hazy memory of the whole thing.
The proxy file gave us several issues. This is how our final one looks now. I have redacted all sensitive information from it. I know that at one point I had TWO AGOL maps up for this. One was for an internal server (serving only to internal customers) and one was external (public facing). So I was dealing with multiple server configurations. Our internal server had different versions between the ArcGIS for Server being used and the Desktop models and the Database, etc. The external also had discrepancies. But now? Now we have a 10.2.2 environment. From our SDE DB to our Desktop. I believe that cleared up ALOT. I think the conflicting versions was causing some of the issues. I also believe that because I was trying to host the app on an Internal-Only server with an Internal-Only AGOL map as well as an External server with an External AGOL map that I might have crossed my wires a couple of times.
I know that at one point I was making updates to the Internal data and trying to refresh on the external map. It was all very confusing at various points in the process. Here's the proxy.config file in 'almost' all of its glory.
<ProxyConfig mustMatch="true" logFile="redacted">
<serverUrl url="http://maps.cityoftulsa.org/ParksFinder" matchAll="true"></serverUrl>
<serverUrl url="http://maps.cityoftulsa.org/gis/rest/services/LGDM/Parks/FeatureServer" matchAll="true"></serverUrl>
<serverUrl url="http://maps.cityoftulsa.org/gis/rest/services/LGDM/Parks/MapServer" matchAll="true"></serverUrl>
<serverUrl url="http://maps.cityoftulsa.org/gis/rest/services/LGDM/Trails/MapServer" matchAll="true"></serverUrl>
<serverUrl url="http://maps.cityoftulsa.org/gis/rest/services/Utilities/Geometry/GeometryServer" matchAll="true"></serverUrl>
<serverUrl url="http://geocode.arcgis.com/arcgis/rest/" matchAll="true"></serverUrl>
<serverUrl url="http://route.arcgis.com/arcgis/rest/" matchAll="true"
<serverUrl url="http://server.arcgisonline.com/ArcGIS/rest/" matchAll="true"></serverUrl>
<serverUrl url="http://services.arcgisonline.com/ArcGIS/rest/" matchAll="true"></serverUrl>
<serverUrl url="http://serverapi.arcgisonline.com/jsapi/" matchAll="true"></serverUrl>
We don't have the Local Government Model fleshed out with enough information to populate the basemap settings. So we compromised and used ESRIs. Jake Skinner recommended using ESRI basemaps in order to get the map up much faster than it would take if I first created the necessary layers for the LGDM... This was a tremendous recommendation. I didn't even know it was an option. I feel like this should be the default for these apps, use ESRI basemap data if yours isn't ready. But if you have URL's to your basemap then replace these fields here. Very frustrating. If not for Jake, I might have abandoned the app at this point because of a lack of understanding. (thanks Jake!)
// BASEMAP SETTINGS
// Set baseMap layers
// Please note: All base-maps need to use the same spatial reference. By default, on application start the first base-map will be loaded
FeatureServer vs MapServer
I have built quite a few maps for the web and had yet to understand the difference or the creation process for a FeatureServer service versus a MapServer service. So while building the services for the ParksFinder I would go back and forth between following the installation instructions to the T and ad-libbing just to get an updated MXD edit out there quickly during the testing phase. I went back and forth between removing the REST Service and replacing it and testing it with adjustments. Sometimes I would use FeatureServer and other times I would use the MapServer. I believe that this contributed to the problem. Alot.
The City of Tulsa parks don't have some of the features being made available in the standard ParksFinder, in fact we also have several that were NOT covered. So I got to not only make adjustments to a pre-built LGDM web app, but to the LGDM itself. Adding new and custom activities to the LGDM itself was the easiest part. Adding those fields to the web app were the harder part. Not actually hard, since it was mainly copy-n-paste, but it was time consuming. However, we have a LOT more activities we make available and quite a few that we cut out of the ParksFinder app. It was really just difficult in a time-consuming manner than in difficulty of the work.
//Activities to be displayed in info window for a feature
Alias: "Restrooms Available",
This project was a great starter-project to get oriented to the Local Government Data Model. It allowed us to see some of the expectations on our system, our databases, our coding, our data, and more. If you're looking for a simple reason to delve in and start using the LGDM then I would highly recommend this app.
The setup and configuration are pretty straight forward. The data needed can be as simple as a single park point. But I would use two.
Phase 3 : Looking to the future (ParksFinderEditor)
So with the ParksFinder just waiting on the Parks department to update their data and generate the needed photos for ALL 130+ parks, I'm already thinking to myself. I don't have the time or energy to maintain the Parks data for them. But they don't have a dedicated GIS person. So I've put together a ParksFinderEditor map that is only available on our Internal server. It allows the Parks Department to edit each park point (attributes not geometry). They can change what services are offered, opening hours, etc. But they can't move the point. They can add a new park and delete a current park.
The problem is, in order to protect this information we are using AGOL security. So each ParksFinderEditor person has to have an AGOL account. We are researching what it would take to create a ParksDepartmentAGOL account. A user account that we could give editing permissions to and only use a single AGOL account for them. Since they don't have a lot of people available for this it might work. I'm just not sure what the rules are yet for 'group' or 'management' accounts on AGOL.
But if we can get the security figured out this will revolutionize our GIS department / data by giving non-GIS oriented departments access to managing their own GIS data in a manner that everyone is familiar with... a browser based solution.
I'm already looking to the other aspects of the LGDM and the other mapping applications. I took the Community Addressing web app and have retooled it to be a web interface for our Addressing people to begin managing LGDM-based Addresses. They don't have a GIS person, but they do have GIS software... and browsers. So my dream here is to get them started with the web interface and once they get some experience try to introduce some training to get them up to speed on the Addressing plugin for LGDM and ArcGIS for Desktop.
Back to the ParksFinder...
So the ParksFinder gave me pause on several occasions. But I blame my relative inexperience with under-the-hood GIS technologies for the majority of my issues. My co-workers (a DBA w/SDE experience & a 15+ yrs experience GIS person) really did behind the scenes work to get things tweaked. Again, a lot of what we found out was version issues. We were using version X on our DB, version Y on our ArcGIS for Server, and more. Our Quarterly release goal was to standardize our versions and we have... and coincidentally, ParksFinder works like a charm too.
Whatever you do, when trying to implement the ParksFinder web app just make sure to not give up. GeoNet and StackExchange are two great resources. Use them. Ask questions. Don't stop. The issues with getting ParksFinder propped up are not as serious as you probably think. At least they weren't for me. Well, I guess that's it. I hope everyone has a great Thanksgiving for 2014!
Peace, Love and Dots and Lines...