Data management stratigies for small organizations: FGDB, Portal Data Store, AGOL

Question

Hello,

I will be setting up an ArcGIS Enterprise Server sometime in the near future for a small organization of about a dozen users.  I would like recommendations as to if I should store data in a File Geodatabase, a Portal Datastore or a combination of the two.

Questions:

* Is there any use case for storing data in a FGDB or should I only use a portal data-store?
* How do users host land ownership parcels that are updated nightly?
* What format do you recommend to author "traditional" ArcGIS Server maps?
* Can we use a FGDB to publish any data to Portal or are we required to use a data-store?
* When do you recommend using ArcGIS Online, vs Portal?
* Do you have any other recommendations for storing data that will be consumed within our organization, a "traditional" ArcGIS Server map, and ArcGIS Portal?

Thank You

I would like to know is more

how I should store our GIS data.  My objective is to maximize performance on our server while keeping our data simple and easy to maintain.

Please let me know when you think it is more appropriate to use a File Geodatabase, a Portal Datastore or a combination of the two.

Are File Geodatabases relevant anymore or should I use a data store for everything?  I would like to maximize performance while maintaining a simple and easy to maintain data setup.

* Would you FGDB or a data-store or larger dataset such as elevation contours?
* Can you use a FGDB to share data to Portal or are we required to use data-stores?
* How do people share datasets such as parcels that are updated nightly?
* What use cases

Brian_Wilson · Answer

Some things that were not clear to me (and some that are still hazy)

I think of the "ArcGIS Data Store" component only as storage for our online services.  Things only go into it as hosted data and then are read-only.  They get refreshed as things change. Close to having something automated, currently it's a bunch of scripts.

We keep the working GIS data in SQL Server and since our IT group manages the server it's not my problem to do the boring parts (upgrades, capacity planning, backups, uptime...) Personally I'd use PostgreSQL if I was forced to do that part. That is just a matter of comfort for you, they both work fine.

My understanding of Parcel Fabric is you can use File Geodatabases if you are not using versioning, that means no multi-user access. If you use versioning then you have to use the new versioning which means you have to run all access through Portal. Personally I hate this idea but no one asked me 🙂 Our cartographers will probably not transition to Pro until well after I retire so it's mostly a moot point for me.

We keep our public web services on our Portal, it's not a problem for our small county. We keep a kind of emergency backup on AGOL that uses almost no storage and gets no traffic ordinarily so low credit use.

So,,, direct answers to your questions........

Questions:

* Is there any use case for storing data in a FGDB or should I only use a portal data-store?
* How do users host land ownership parcels that are updated nightly?
* What format do you recommend to author "traditional" ArcGIS Server maps?
* Can we use a FGDB to publish any data to Portal or are we required to use a data-store?
* When do you recommend using ArcGIS Online, vs Portal?
* Do you have any other recommendations for storing data that will be consumed within our organization, a "traditional" ArcGIS Server map, and ArcGIS Portal?

Thank You

I would like to know is more

how I should store our GIS data.  My objective is to maximize performance on our server while keeping our data simple and easy to maintain.

Please let me know when you think it is more appropriate to use a File Geodatabase, a Portal Datastore or a combination of the two.

Are File Geodatabases relevant anymore or should I use a data store for everything?  I would like to maximize performance while maintaining a simple and easy to maintain data setup.

* Would you FGDB or a data-store for larger dataset such as elevation contours?

I would keep contours as vector data (polylines) in the enterprise GDB and then publish them as vector tiles and store them in the Datastore, because they change very slowly and vector tiles render fastest.

* Can you use a FGDB to share data to Portal or are we required to use data-stores?

You can register as many FGDBs in your Portal as you want, but they will be basically read-only since they cannot be versioned. If you have one person own them or you know only one person needs to edit at a time that works but why bother? It's work initially to set up a database engine (Postgres or SQL Server) but easier in the long run than keeping track of a bunch of shared FGDBs.

* How do people share datasets such as parcels that are updated nightly

We keep them in the SQL Server currently and publish them out as a Feature Layer in Portal. They use traditional versioning because the maintainers use ArcMap. I want to have a workflow to publish them out as a vector tile layer for speed in my web maps but I don't have that going yet

We moved directly from shapefiles and FGDBs to SQL Server about 5 years ago, then have been slowly sorting out which services should be "hosted" and vector tiles and what changes slowly vs what needs to be live data, your examples of parcels and contours being great examples of the extremes.

I generate a new "base map" about once a month with roads, parks, water features, etc and the process reprojects everything into Web Mercator into a local FGDB as a workspace and then produces output as Vector Tiles and a Map Image Layer for queries (pop ups) into the data store as "hosted" data.

I have most of a workflow in place to do this with parcels and taxmaps but not quite. Currently the taxlots paint too slowly on the web site but I am the only one who notices so fixing it is not a priority for anyone else.

(It can be used an actual "basemap" but gets put on top of aerial photos in practice.)

You are welcome to look at the public map at https://delta.co.clatsop.or.us/apps/ClatsopCounty/

I can't remember exactly which services are vector tiles (contours?) other than the base layers; I am all about speed and aesthetics and my supervisor is all about getting things done easily and she is comfortable with those slow registered feature services that just work. We are very complementary, she is all about clicking buttons and I write code. Not sure what happens next year when I retire. They will need someone willing to code but not greedy. Why would anyone choose that? Other than me? 🙂

jcarlson · Answer

Oh, definitely. PostgreSQL is all we use over here, and it works great. I highly recommend it. And if you create your databases using the built-in st_geometry types instead of the Esri-specific ones, you'll be able to query your features and visualize them right in tools like pgAdmin and the like.

LyonMNGIS · Answer

Josh,

I forgot to ask about SQL Enterprise Databases.  I will not have access the full version of Microsoft SQL Server.  Do you think it is worthwhile to use SQL Express? Alternatively can I use a PostGRES Enterprise Geodatabase along side a Portal Data Store that also uses PostGRES?

Thanks!