bokeefe

Park and Recreation Finder : My Experience (phase 1)

Blog Post created by bokeefe on Sep 4, 2014

I was promoted into a GIS Analyst position about a year ago. Prior to that I had spent a good 6-7 years working with GIS data in a CAD environment (Bentley Microstation / Geomedia) but I had ArcMap and Database experience previously and it wasn't that difficult of a struggle to shift gears into the new ESRI experience. I've built web-sites as well, both professionally and as a hobby for years now, so the new Web Maps that ESRI has developed practically call out to me. Prior to this position I was the Address Coordinator for my city and I dealt with the many pitfalls and challenges for a Local Government to be responsible for Addressing without having a good system in place to actually do the job.

 

In comes Adobe Local Government Model.

 

I still remember watching the Addressing videos and having to pick my jaw back up. All of that work that I would have to do to create addresses for a new Subdivision was reduced to point-and-click. And a Database and a Web Map was the end result. I almost cried. *sniff*

 

Well, now my horizon is much broader. I'm helping to develop the GIS foundation for the entire City, not just one department. This shift in focus only helped to solidify Local Government as the direction we needed to take. And that focus didn't get lost on my co-worker and boss.

 

Fast forward to this last week+ and I was encouraged to make a move on the LGDM (something that was already in my bullet journal) so I chose the simplest discipline I could think of... Parks. With roughly 5 tables/feature classes powering Parks in the LGDM I figured this process would give me a sample of what I was looking at as we moved forward into the LGDM arena.

 

But now that I've (mostly) got it up and running... I sure hope not!

 

Note: Just to clarify, I tend to differentiate between the LGDM and the LGIM. The LGIM (Local Government Information Model), to me, is the skeleton... the idea... of what ESRI has. It is the XML Workspace that shows what tables need to be where, and what relationships, etc. The LGIM is empty, and more of the map of what will be. The LGDM (Local Government Data Model) is what the LGIM is when you add data to it. So if I shift around from LGDM to LGIM that is what I am referencing.

 

The Download

Getting ahold of the ParksFinder is really the first step in the process.

 

The Park and Recreation Finder (ArcGIS 10.2) app. This page gives you a nice breakdown on what to expect from the app. What to expect, what requirements it has in order to be put into place, etc. But... buried down on this page is the most important link you can have if you plan on installing and getting this app up and running. The Release Notes has a link to the 'Online Help.'

 

Basically a Yoda page. (No, not short, green and long-eared) This page lays everything out. Just make sure you notice that there are two sections to this page... a Home and a Get Started section. This is where you will find yourself returning to as you hit your own snags and/or glitches.

 

But before you start reading, do yourself a little favor and go ahead and just download the app. Unless you are just going to use the sample data this will just get you started.

 

Data Massage

We started out massaging the data that we already had on our Parks. Basically, Polygons for each park. And we had field names as follows:

FIDPARK_NAMESITEADDRESSACRESPLAYGROUNDSPORTFIELDETC...
0ChamberlainChamberlain4940 N FRANKFORT1414...

 

Not too bad. Massaging this was the least of my issues. I would do things differently if (when) I had (have) to do it over. For instance, we had a kids pool and an adults pool option in our list, but there wasn't one in the LGDM... neither was there a Skatepark, Diskgolf, Indoorgym, etc. After I finished most of the work in getting this map to work I discovered that you can create your own columns in the GDB and just adjust the Javascript to allow for those new Activities... hindsight and that 20/20... ah well. Luckily, I can add them back in later, I just would have appreciated not having to redo that work.

 

Of course, I could have left them in. That IS one of the big selling points of the LGDM. Take their model as a skeleton and add whatever you want to it... Just don't take away from it and everything should work just fine. But... in my infinite wisdom, I went with the... let's try and maintain an LGDM as close to what ESRI has built as possible. If they don't think we need it, then maybe we don't.

 

Point learned.

 

Step 1 : Generate Centroids

So we generated centroids for each park... Simple and easy.

 

Step 2 : Append To LGIM

The next step was to get our data into the LGIM. This step was a little more interesting but not all that difficult. First we append our centroids into the Parks table (with some fairly easy field mapping).

 

DatabaseLocalGovernment
Feature DatasetLocalGovernment.SDE.ReferenceData
Feature ClassLocalGovernment.SDE.Park

 

Figuring out where to place the data was a little bit of a challenge. But not the hardest.

 

Step 3 : Apply Soothing Oils and Massage

We've got our data in the database. But now I want to see something on screen! (I know, impatience doesn't serve) But I've got to continue on.

 

In our Parks data the Activities fields don't operate on a YES/NO but rather a number system to describe how many of those Activities are available. Rather than just a YES/NO for Basketball Courts, we have a listing of how many. So I've got to convert. Field Calculator to the rescue. I'm an old VBA guy (I blame Office 95 and it's Access DB with VBA built in) so I code out some simple IF/THEN's in order to convert any number greater than 0 to a YES. But we can't forget to convert the 0's to a NO. I decided to generate a FACILITYID (Facility Identifier) by taking the first 3 letters of the NAME (Name of Facility) field and the first 3 digits of the address and combining them into something like so... CEN-102 (Centennial Park located at 1028 East 6th Street).

 

Whenever I found a field in the LGDM that we didn't have and I wasn't familiar with I would just go to the sample GDB and see what they had. For instance, SUBTYPEFIELD (Subtype Field) and FEATURECODE (Feature Code) I just set to '790' and 'Park' respectively. There were some other minor adjustments that had to be made but all in all, this wasn't the hard part... (yet). (Trust me, that yet will make sense once we find out about the Field Calculator and YES/NO fields... ugh!)

 

Alright... so our data looks right as far as parks go, the trails process was a lot less interesting. It was more of an almost straight append with some minor field mapping. And our Data Massage process is complete.

 

Map Document Time!

So now we get to open our Map Documents. There are a few in here and I'm suddenly getting this sad feeling like this app will never happen. What do I do with this GeneralPurpose.mxd? ImageryReferenceOverlay?! ACK! At this point I have given up... just a little.

 

But I shouldn't have.

 

I have the GeneralPurpose.mxd open and it's got millions of database connections to the sample GDB. It kinda hits me... oh, no... every one of these Local Government apps will have MXD's tied to the sample GDB's they offer... I have had to re-route data connections in some seriously large MXD's before and I was already daunted by the process just for this... and then Jake Skinner steps in to the rescue...

Parks and Rec Finder : Switch to SDE Connection

You can right-click on the MXD in the catalog window > Set Data Source.  The MXD that contains the hundreds of layers is actually the basemap.  This can take some time to create since you have to populate all of the feature classes in the LGIM.  If you're eager to stand up the app, what I recommend to customers is to use one of ESRI's basemaps in the application.  When your configuring the config file for the app, you can simply specify one of the basemap's REST URLs.

 

Now, you will just need to update the 2 layers in the Parks.mxd, publish this as a service, and you will be able to stand up the app.

I. Am. Floored. I mean, I've read how to do that before but it never clicked because I've never really needed it. The majority of my re-routes were single feature classes. But this was a game changer. So... ok. I get all of the MXD's re-routed to our internal SDE GBD where we have OUR copy of the Local Government Data Model. Containing ONLY the Parks data now... but it's there.

 

With a couple flickers the data suddenly populates on my screen in ArcGIS Desktop 10.2.2 and I am suddenly feeling a little more excited. We have life. It has begun. (Oh, I know I had already begun, but now I can see things on my screen!)

 

I check the Trails.mxd and it works. On a whim I check the other MXD's and step away from them very quickly. Go up to the Quote from Jake Skinner again and see the fourth sentence... "If you're eager to stand up the app, what I recommend to customers is to use one of ESRI's basemaps in the application." This is fundamental.

 

If your group doesn't have the majority of the LGDM filled with working and live data then you really want to ignore those other two MXD's. Inside of the app where you would NORMALLY reference the REST Services for those datasets just reference a relevant ESRI Basemap. This is EXACTLY what I did.

 

To the Web!

I'm done with all of this. I want to see a web map!

 

I share the Parks.mxd and Trails.mxd as webservices in a folder called LGDM.

 

I drop the app on our web server (a 10.1 Server running a 10.1 Web Adapter in a DMZ) and grab the config.js file and proxy.config and quickly add in some ESRI basemaps, an initial extent, and our services. I create a Geometry service (for good measure) and voila!

 

Stuff starts happening.

 

Now at this point I'm getting rudimentary map functionality. I can see the parks but I'm getting weird Javascript errors.

 

BUT I CAN SEE THE MAP WITH MY DATA!

Sigh... I'm going to step away from this blog entry at this point, but I did NOT get to step away from the work on this app at the time. I will try to cover the various issues we had from this. But for now I am posting to a blog for two reasons.

 

  1. To get this off of my brain

    Working through this app install / config process was a grinder. Figuring out which issues were from our data, the app itself, the browser, or our servers/webadapter was excruciatingly difficult at time. My brain got wrung out and put up to dry a few times and writing it out really helps to figure out where I can do better next time and hopefully avoid some of the rookie pitfalls I found.
  2. Help someone else

    The biggest thing I found while searching for answers on this process was that there are no answers. Not without the questions. It was almost comical as my co-worker kept searching out solutions to some of our problems and his web searches were pulling up my questions here on GeoNet instead of answers to those questions. I even posted some of my requests for help on StackExchange with little or not results. Oddly enough, the greatest breakthroughs were from the GeoNet group and some personal e-mail correspondence between me and one of the more experienced members.

My map is up. I'll cover some of the other issues and what we had to do to move past them later. For now, if you hit a snag, feel free to post on GeoNet and if I can help... I will.

 

Peace, Love and Coordinate Systems

Outcomes