nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Local Government Information Model Implementation and Starting Point

StevenE

I recently started working for a small municipality that has an opensource web map created from SDF files, but uses Arcmap as well when needed. I was recently hired to help transition the GIS to industry standards, but am struggling to game plan for the best route to take. We are currently exploring the options to either get an Esri Enterprise account and set up ArcGIS Server, or just transition to using ArcGIS Online and having local .mxd document to maintain and update. I have downloaded the Local Government Information Model and am wanting to import our shapefiles into this model, but as the formatting of some of the data is inconsistent, I am wondering the best way to go about this. I am looking for advice regarding a starting point for importing existing data into the Local Government Information Model and establishing consistent data standards, and eventually publishing this data as a web map. Do I need an enterprise account and ArcSDE before I can do this successfully? Can anyone help with a starting point for this? Thanks!

Find more posts tagged with

Local

Accepted answers

ScottOppmann

Steve -

With the emergence of ArcGIS organizations (online and on premise), we have been pivoting away from a single data model for local governments. We never intended the LGIM to be a “standard” for local governments. GIS professionals can configure the LGIM to fit their unique organizational needs. The information model is a living data model that evolves as new maps and apps are added to the ArcGIS for Local Government solution; and ArcGIS evolves in ways that simplify the deployment of these solution offerings.

The LGIM has historically been supplied as a geodatabase schema. At the time of the LGIM’s inception, this was the most popular way for local governments to store data in ArcGIS. Delivering the LGIM as a geodabase also provided a foundation for the ArcGIS for Local Government solutions and helped you organize your data so you could quickly deploy the solution offerings. But with today’s popularity of hybrid WebGIS implementations, local governments are frequently using both geodatabases and hosted feature services. Now, many of the ArcGIS for Local Government solutions use hosted feature services solely and we are sharing these feature layer designs in the ArcGIS for Local Government Service Catalogs so they can be used to create new hosted feature services in your ArcGIS organization. And with the release of the ArcGIS Solutions Deployment Tool, many ArcGIS for Local Government maps and apps can be now be quickly deployed in your organization without having to construct the solution offering manually.

So I would suggest you start with the ArcGIS for Local Government solutions you'd like to deploy in your organization and work your way back in to the management and storage of the spatial data that drives the solution offering. Peeling the model apart (layers and feature classes) and focusing on the solutions first will simplify your project and allow you to deliver quick wins to users in your organization.

Finally, the Local Government Information Model isn't going anywhere. We still plan on maintaining it and evolving the content included as we add new maps and apps to the ArcGIS for Local Government solution. But you will see (the March 2017 release was the first step) us start to refine the content included in the model so it generally includes content that would naturally be managed / used / analyzed in ArcGIS Desktop.

Hope this helps.

Scott

All comments

PhilLarkin1

It would be really nice if the LGIM was still published as a complete data model that could be examined in a geodatabase

This download is current as of March 2017. It includes the model as an XML document that you can import to a fGDB.

Esri Accounts

bfausel

It would be really nice if the LGIM was still published as a complete data model that could be examined in a geodatabase, even as more components shift to AGOL-only. The Solutions Deployment Tool in Pro works really well if you don't have to modify the table schema and don't have existing data to contend with. However, it is easier to use a geodatabase as a reference if you have large amounts of schema changes and/or legacy data to import...At least until I learn more about the data management tools in Pro (or as more tools are developed).

Here is a quick example of a dilemma I recently encountered with the Solutions Deployment tool as compared to using the local GDB schema:

We had to extend the "Owned By" domain to include more entities than the LGIM includes after the feature services were created. "Private", "Other" and "Our Agency" are the defaults -- we had to add other local government and utility units to the domain.
When you use the Solutions Deployment Tool in Pro, numerous hosted feature services are automatically created in AGOL - we tested Poles, Streetlights, Signals, and Signal Control Boxes -- this created 4 hosted feature services.
If you want to modify the "Owned By" domain, you have to do it for each of the feature services using the Solutions Deployment tool. Back in the geodatabase world: you only had to modify the domain once, it updated for all layers, and then you published from there to AGOL.
Sidenote: There appears to be no way to sort domain values in AGOL at this time. This was possible with ArcCatalog and geodatabase.

We have been using the LGIM model as a starting point for most new layers. That said, many of the new solutions are simply using the modern Esri COTS apps (Collector, Explorer, Web AppBuilder, etc) rather than the individual custom web apps / MXDs that were used when the LGIM was started. Therefore I can see why the underlying data model is less important. But we would still find the full LGIM model useful, provided we can easily decipher their design in a geodatabase.

ScottOppmann

Steve -

Hope this helps.

Scott

SallieVaughn

Echoing what Joe said, the LGIM is a great starting point. If the data you currently have is in terrible shape, the LGIM is a good place to go. I did a similar thing with my current organization (transitioning from multiple copies of the same data, all with different levels and qualities of attribution) to the LGIM. The task was not easy and took quite a bit of time.

To manage the task, I made a series of Excel spreadsheets showing the schema of each layer in the LGIM. For layers we were planning on using, I placed that schema along side the LGIM schema and drew lines from our existing fields to the LGIM fields. That way, when I was working on the project and got interrupted, I'd know where I was, what I was doing, and where to go back to when I had free time again. I'm happy to share those spreadsheets with you.

Since this time, I've appended/added to the LGIM to work better for our organization in terms of additional columns in some layers as well as additional layers.

Also, downloading the sample data from Naperville really helped me understand what sort of data went into each layer and how the data is used by other LGIM products. That would be a great starting point.

JoeBorgione

Ahhh... A data standards thread. As I usually say, "The thing about standards is there are so many to choose from..."

I was hired by a county to examine the use of the LGIM and it's okay, but trying to stuff an incrediably broad range of data and data-uses into a one-size fits all model isn't just challenging, it's pretty much next to impossible. Hence my opening quote.

On the other hand, LGIM may be Heaven sent in your case. How data-rich and mature is your organization? Are there established workflows that experienced GIS analysts have used and would like to continue to use? Do you share data with other agencies or obtain data from agencies? If so, what model or standards are used?

It sounds more like your situation could use a standard and since the LGIM is avaialble, why not use it? Consider also that you can use the LGIM as guide rather than a hard-fast model. Use the components that work for you, and disregard those that don't. There are number of ESRI tools that were developed to dovetail into the LGIM, so consider them as well.

As far as migrating your exisiting data into the LGIM or any other model: take your time. Examine your absolute bare bones needs, add what-ever fluff would be nice and then build or use a cross-walk like the Simple Data Loader or the Append tool that map your existing fields to the target feature class.

JohnMellor__GISP

Have you compared the LGIM data dictionary to your shapefiles?

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.