Different ways to manage layers in an organization

2043
10
08-23-2016 05:39 AM
SvivaManager
Occasional Contributor II

Hello,

There is a problem I keep experiencing repeatedly when it comes to serve customers in my organization.

I find it very confusing to balance the way our geographic data is managed and then published to different needs.

Three common stored data types for layers we use are:

- File system based - inside FGDB files.

- SQL based - SDE layers.

- Portal based - an internal Mongo DB data which is unmanagable at this point.

So we decided to have all of our business data, which is considered to be more dynamic than other layers, to be stored inside our SDE.

Some layers we receive once a year from an external source and they are all stored in an FGDB.

From time to time, some employers request different geographic analysis and as an output, they receive a "temp" layer which is stored in our Portal.

We published a few map services which were divided into different information groups to represent different data layers and when applications are made to customers, the layers can be consumed either through those "chuck" services that holds the required layer, or as an individual layer through the Portal after linking it to a layer item.

So each time a client request a few layers from the DB the same question rise..

Should we publish another service to hold he's layers all together and consum a lot of valuable CPU resources and duplications beteween services??

Should we just gather seperated layers as items from the Portal to a Webmap without having them sorted as groups??

Should some of them be consumed as an FGDB file??

Is there a clear way to manage the data and avoid duplications?

Are there any other organizations that experiencing this and can share their wisdom?

Thanks,

Shay.

10 Replies
SvivaManager
Occasional Contributor II

Thanks a lot Paul  valuable information.

0 Kudos