Add Stand Alone Data Catalog Like ArcCatalog to ArcGIS Pro

ArcCatalog is a powerful tool for easily managing data. I haven't seen anything like the easy data management functionality of ArcCatalog in ArcGIS Pro. And the last thing I want to do is create a whole ArcGIS Pro project folder when all I want to do is look at some data that someone just sent me in an e-mail. If the end-game really is the extinction of ArcMap 5-10 years from now, then Pro will have to have a replacement for ArcCatalog.

Asking users to use ArcGIS Pro's project pane to manage all of their data is like asking Windows users to use MS Word's Browsing window to manage all their files. A browse window is no replacement for a full-featured data management app like ArcCatalog.

I'd like for someone at ESRI to acknowledge that and tell us when it will be added to the development schedule.

I'm actually really eager to begin using Pro routinely and it's frustrating having a major stumbling block like this in the way.

As this conversation has grown over time, users who are seeing it for the first time probably won't get through all of the comments. We're placing this statement (from June 2017) here for visibility and to continue to encourage you to share your input about needed functionality in the comments.

There is no plan to create a new application in order to deliver ArcCatalog-like functionality in ArcGIS Pro.We continue to bring in “ArcCatalog” (data management) functionality into the Catalog pane and Catalog view in Pro, with much added at the 2.0 release this week and continued improvements coming to 2.1 and beyond. As mentioned in the discussion referenced above, we shouldn't consider that functionality has been taken away and you're being asked to request it back. We appreciate the user community's input to help prioritize development work. So please continue to provide focused and constructive input that will help in that process.

For this particular idea about a "stand alone" data catalog for Pro, since we've already clarified that there will be no separate application to manage data in ArcGIS Pro, we need feedback on what functionality you use most in ArcCatalog that is not possible in Pro. As newer versions of Pro are released, the number of things on that list will decrease.

I spend way more time in ArcCatalog than I do in ArcMap. Most of the time I have no need to see a map of anything. I just need to manage the data behind it so others can deal with the map part. I need a standalone data management tool with out the wasted overhead of a mapping interface.

I use ArcCatalog extensively for managing metadata. I've had a look at what ArcGIS Pro provides and find it very clunky not at all slick like ArcCatalog. Managing data, it's different views, requires a slick application like ArcCatalog. Trying to shoe-horn all that into an already one for everything application will simply not work. For GIS professionals/data managers they need a focused application to help manage data. The current model of Arcmap and ArcCatalog works well, don't throw that away!

If ESRI do produce an ArcCatalog equivalent (which I hope they do) why not look back to 9.3, with the jump to 10.0 we lost capabilities such as selecting a load of datasets from a search and copying their paths, that was very useful!

I spend most of my time in ArcCatalog developing tools that aren't tied to a project, user, or machine. My preferred end product are python add-ins toolbars/buttons, which to my knowledge are not, and will/can not be supported in Pro due to ribbon UI (although the toolbox can be accessed and used).

My use case is being able to manipulate/analysis/geoprocess data, including maps via arcpy.mapping. I know that toolboxes can still be accessed, and "tasks" are the new workflow model, but an easy interface with the ability to develop/manage data and maps programmatically is why I like and use ArcCatalog. I don't have to create a project for this, just open it up and develop, view and/or manage all my data and tools. I know ArcCatalog will be around for quite a while and so this development/management workflow will continue for my use.

On the up side for Pro, I know it does have some nice features, and running my tools written thru ArcCatalog run much faster, as long as I make them compatible with python 3.x, when necessary. Pro is solving many of the issues that many users have been asking for, for years (multi-layout, real 64-bit, etc), so that is a plus. Also, I know that trying to build some of these requests into the Desktop platform wasn't possible, practical, or cost effective -- and having them try would have caused more of an uproar from all of us, as new issues, time delays, and rising costs would most likely have happened. So, the approach of starting clean, from the ground up, and adding features in as it grows is probably a good approach, and less disruptive to those of us that are long time users of Desktop (as much as I and many others don't want to admit sometimes). It is after all still in the 1.x version (anyone else ever remember a 1.x version of any software being a completely polished product? MS Windows 1.x,). Sorry about the editorial, but I have hope for the product and ideas like this getting serious consideration and hopefully implementation.

So, for the near, and still semi-distant future, I will continue to rely more heavily on Desktop, while playing with Pro when I have time. With each release more functionality is coming out, so I'll hold judgement on 1.4+, but the "simplicity" of quickly opening a Catalog session, doing whatever, and closing down, at least so far, is not there. Also, our shop will be a mixed bag of users and what they use for a long time to come....so will always need to have the data review and management features of Catalog.

Mind you, I LIKE the way limited ArcCatalog functions have been integrated into ArcMap and ArcGIS Pro. However, that in no way justifies the extinction of a full featured data management app like ArcCatalog or some suitable successor.

Minor background: I am the GIS administrator of a USA county level government agency with an ESRI ELA. Been an ESRI only user since PC-Arc/Info in DOS in the early 90s. I have been through the changes from Unix Arc/Info workstation into NT/windows 8.0 ESRI migrations, used ArcSDE since it was called SDE 3.0, moved from ArcView Server to ArcIMS to ArcGIS Server and ArcGIS Online, times change and so have I. I want that clear on that so no one thinks this is a 'change is bad' type issue.

Our agency has been evaluating Pro in the last few months due to the tie-ins with ArcGIS online/Portal. Unfortunately ESRI has chosen to only make some of the functionality with 3D available in Pro. Right now I can see no use for Pro for myself. For new general users , Maybe. But if they are already ArcMap users I can't see the time relearning it, and if you adding new users you are asking us to support another piece of software. For our data editors, NO. Pro is missing too many key editing functions to do with relationship classes and Annotation for us to be tempted at this time. I know it is at version 1.4. Maybe at version 3+

For folk like me, the Administrators behind the scenes. I enter ArcMap less than once a month, I make zero maps, I make zero edits. I am in ArcCatalog and Python performing normal daily ArcSDE and ArcGIS Server administrative actions. There is almost NOTHING in Pro for administrators to embrace it. Think about what is involved after opening Pro to do simple tasks like move a feature class from one dataset to another, rename a feature class, or create a new topology between layers and validate it.

ESRI, if you can't convince the people who install and maintain your software to use it, it is a lost cause. I know ArcCatalog will be around for years to come. But I've heard from more than one ESRI employee (and the owner) that Pro is the future that ESRI is headed toward. If that is true and I can't see that Jack would say those things as a joke in front of thousands of users, then some version soon (very soon) the ArcCatalog-type administrative geodatabase functionality has to take a GIANT leap forward. Maybe even an entire version dedicated to it. You're asking a lot of people (and asking often) to take a leap of faith in a new direction and into a new piece of software. Even though I'm not a big ribbon fan myself, there are nice things in Pro, it is 'pretty' and will be easier for some users to pick up. But those are the casual users, the hard core users will struggle. Currently is just takes too many extra clicks to perform tasks compared to what it takes in ArcGIS Desktop.

How does ESRI evaluate the numbers of votes on our ideas? Is it just raw numbers or does ESRI do any user demographics on them?

This idea is now up to 77 up-votes and 730 points, total. That's more than some and less than others, but definitely getting some support. However, it's still not yet "Under consideration". Clearly, ESRI is not considering this an issue. Why?

Please read the use-cases that people have been writing above.

I'd be willing to bet that those votes represent a select and indispensable set of users: geospatial DBA's and those who do that job when there's no one with that title in their organization. Most GIS folks probably use ArcCatalog from time to time and what Pro offers them for this may be just fine for them. GDBA's, on the other hand use ArcCatalog intensively and may need a mapping app like ArcMap or Pro rarely, if ever. Yet, no one would deny the critical nature of the GDBA's work.

Now, GDBA's are a tiny fraction of the GIS user community; let's say 5%, at most. So, if they are the ones giving these up-votes, it's MUCH more significant that it has achieved a total of 730 points. If the GDBA population is only 1/20 of the total population, that means that the total significance of this vote could be as much as 20-times more than 730, perhaps the equivalent of 14,000 points. That would make it one of your most requested Ideas of all time and of critical importance to the geospatial DBA community.

By comparison, auto mechanics are only a small percentage of the tool-buying community. Yet, their services are critically important to the rest of us, and the tools they use, though used only by the mechanics and purchased in small numbers, are equally critical.

Like the tools used by auto mechanics, ArcCatalog, though used intensively by a small percentage of the GIS community, is critically important for the critical work that they do and to the entire GIS community which depends on the GDBA's.

David Wheelock another suggestion is open a support case with Esri Technical Support and have them possibly create a request to add this functionality. You can then provide the link to this GeoNet post in the case. That will give you something that is traceable from your side to see how progress is going.

I do know that Esri personnel do monitor these "arcgis ideas" post but having a logged request adds the ability for other Esri customers to be added and their "Use Case" included, as you mentioned in the original post.

This is just a thought; but is adds to the visibility of the request, in my opinion.

Disclaimer: I do not have any pull on how this request would go, one way or another. I also cannot speak as to how an idea is decided to be acted on or not.

If there is such a case, I would like my voice added to that. As David has indicated, the functionality found in ArcCatalog is absolutely vital to GDBA's. As the only full time employee responsible for GIS in our community I oversee all functionality for GIS in our organization. I do both the mapping and the GDBA for our organization. For mapping I am really impressed with what Pro has to offer but am quite disappointed with what it has to offer in terms of Enterprise SDE GDB administration. Luckily ArcMap and ArcCatalog will stay around for a while because if they did not our organization would be dead in the water without the Geodatabase functionality found in both applications.

Thank you for your comment in support of this idea. As a response to the question about a case being logged, there is no one single case or enhancement request with technical support asking to create a stand-alone ArcCatalog-like application for ArcGIS Pro. Rather, there are focused functionality requests such as ENH-000104482: Add ability to rename shapefiles and other types of files through Project pane in ArcGIS Pro which is fairly equivalent to Rename Shapefiles (better data-management) in ArcGIS Pro (1.4) . Notice that the Idea is marked as In Product Plan as this functionality will be added at Pro 2.0 due out by the end of the month.

That idea serves as another good example. It asks for the functionality for a specific version (Pro 1.4). Ideas are not implemented by version, rather for the product in general. The functionality will not be added to Pro 1.4. It will be available starting at Pro 2.0.

OK, so that is to address the case issue. Stepping back and taking a bigger look at this idea in general, here is how it breaks down in my mind:

Which is essential to you? A stand-alone application, or the ability to do all the data management that you need to do in Pro? Or both?

If both, what are the reasons for needing a stand-alone application?

We've heard reasons such as not needing a map interface at all. When I open Pro using the built-in Blank template, it opens directly to the Catalog View (Pro 2.0):

There is no map at all. Data can be managed here, new databases created, database connections made, metadata edited, etc. A user could create a template to use solely for data management and call it something like Catalog - or even ArcCatalog

Now, as part of the conversation about this idea, we're hearing that you (being the user community) often have ArcCatalog open separately, or even multiple instances of ArcCatalog open, and sometimes alongside one or more instances of ArcMap, and perhaps after inspecting data, you might drag and drop it over into ArcMap. To respond to this need, the ability to open multiple instances of Pro is part of 2.0. See Run more then one instance of ArcGIS Pro.

Though I'd also wonder about the real need for this since you have the data management functionality in the same application, so after inspecting it in the Catalog View, you could add it directly to a map in the same project. But regardless, multiple instances will be available soon. What is not yet available to address the use case described is Drag & Drop Data into ArcGIS Pro. That idea is Under Consideration.

From the lively and on-going discussion around this idea, I see one more piece that seems to be relevant and that is the ability to simply open Pro, look at some data, maybe make a quick change like add a value to a domain, append data to a table, etc. (work directly on the data that doesn't require a map), and then close Pro without saving a project. The argument is that one does not need to save a project to do this type of work. We're accustomed to this workflow when using ArcCatalog - when we close ArcCatalog, there is never a need to save, there is no such thing as a catalog document. This is captured in Open ArcGIS Pro without having to Save As a workaround, you could create that "ArcCatalog" project that doesn't contain any maps, just the Catalog View. Open that to do data management and close the project without saving.

So at an application level, ifwe were able to open ArcGIS Pro without saving a project, it opens to Catalog View (no maps, scenes or layouts; though you have the ability to add those things), you have all the data management functionality that you need, you can have multiple instances of Pro open (one strictly in Catalog View), another one or more with different maps and can drag and drop from Pro's Catalog View into a different Pro project open in a separate instance, and then can close Pro without having to save, would that meet what is being requested by "Add Stand Alone Data Catalog Like ArcCatalog to ArcGIS Pro" ? David Wheelock

Now that we've reviewed the big picture and asked for further clarification from users, Shawn Beecher I want to come back to your specific requirements that lead you to be

"quite disappointed with what it has to offer in terms of Enterprise SDE GDB administration."

The ArcGIS Pro development team is working hard to meet all of your functional requirements. If you could please provide the specific Enterprise SDE GDB administration functionality that is missing, that would be most helpful. Nana Dei

I'd recommend honing in on exactly what you are unable to do in Pro, search the Ideas site to see if somebody else requires the same thing, and if the idea exists, up vote it and comment, and if it doesn't exist, submit a new idea. You can keep it "related" to this thread by referencing it in a response here.

Sorry for the long response. We've been monitoring this idea, thinking through it, seeing how it relates to a bunch of other Pro ideas, and trying to figure out how to meet the user community's data management requirements with ArcGIS Pro. You provided a good opportunity to synthesize some of the conversation. I would expect that this post will generate some response - I certainly hope that it does! And we hope that those responses are constructive and provide understandable, actionable input.

Can I just say Wow! You rock! what a well thought out and extremely well articulated response. Thank you for that. This reply will be long so I apologize. I will try and look at the ideas when I get done. I am somewhat new to Geo Net and using it for this purpose so if I didn't tag Nana Dei properly I apologize.

I don't necessarily need a stand alone product. I am not opposed to the idea of the catalog being a part of and inside of Pro. If we could pull up a catalog view inside of Pro that would be fine with me. The fact that you can open a new window and have it run side by side with a map version of Pro I think will help with any need to have a stand-alone like product. My big concern is functionality within Pro in regards to Catalog. I am still learning about Pro so maybe I may have missed something as I am learning which is entirely possible.

In ArcCatalog there is functionality that I would like to see in Pro before I can move over. Some of the functionality isn't critical and some is absolutely vital. Non-critical items would include the ability to connect to drives not just folders. I definitely want to keep the functionality in Pro to connect to folders (much like a bookmark to that folder). However, there are times I just want to go into the main drive instead of a specific folder. I can keep my connections cleaner that way.

I have attached an image here. Some of the connections are to specific folders that I use a lot. Some of the connections are just to specific drives. If I have to make a connection to every possible folder I might use my list would be huge and would take forever to sort through. I would like a true catalog view with the ability to map to drives.

The next thing that is extremely important and vital to me is the full ability to work with my databases (not just connections to the databases). A huge component in catalog is the ability to work directly with Database Servers (Microsoft SQL Server Express Instances). Much like the comment above it gives me the ability to connect directly to the instance and look at and work with all of the databases within that instance without having a connection to every single database. I will still make the connections just so that they can be used with my python scripts. But, those aren't the ones I look at when I want to manage the data. I look at the database servers because it is easier.

As you can see in the image above we are looking at one database server (Microsoft SQL Server Express Instance). This instance has 12 Databases. This is just one of 8 instances that I work with. I know some may say we are doing everything inefficiently, but we have had to make it work this way with lots of replicas because our network is so slow and no one in our organization will do anything about it, nor has anyone done anything about it for the 14 years I have been here. Things might change this year. I am crossing my fingers.

I need to get access to my databases on the database server level so that I can delete, add, view these databases from an easy viewpoint. That I have found so far that is not the case in Pro. So far the only thing I can see is the ability to make database connections to SDE data. If I need to make a change to the schema of a database that will require the ability to unregister a replica (functionality that I have yet to find in Pro), delete the child database (which will be extremely hard to do as a database connection), re-create the database (which will be extremely hard to do as a database connection), then re-create the replica (functionality that I have yet to find in Pro), currently that I can see there is no way to do that in Pro.

I guess I need full functionality to work with an enterprise geodatabase. Functionality that exists in ArcMap and ArcCatalog. The functionality that I am talking about includes: everything found under the "Administration" context menu found when you right click on an sde database (Functions such as Administer Database, Backup, Permissions, Compress Database, Geodatabase Maintenance), everything found under the "Distributed Geodatabase" context menu found when you right click on an sde database (Functions such as synchronize changes, import schema changes, export replica schema, compare replica schema, and manage replicas).

In ArcMap the 2 big functions I use all the time can be found on the Distributed Geodatabase toolbar and are the "Create Replica" and "Synchronize Changes" tools/buttons. Without all these tools and functionality I cannot move to Pro as a production tool. I need those functions in my organization to make everything work.

I am sorry that this response was such a long response but appreciate the opportunity to explain what needs we have as an organization and how those relate to Pro moving forward. I like the idea of going to Pro. I just need a few more things in order to do so. Thank you again for the wonderful response.

This is an outstanding response and very welcome. It's okay that it's long. That's good in this instance.

I'm bothered that we seem to need to request on a feature by feature basis for "Function X to be added to ArcPro". The default should be: "ArcPro can do everything that ArcMap and ArcCatalog can do (and more!), with the exception of the features below that have been excluded below because ..." {superseded by better function Z}, {rolled into Y}, {no longer needed}, {too much maintenance development to support vs usage rate}, {too buggy}, ...

ArcCatalog didn't arise out of nowhere. Years of accumulated needs, problems and solutions are incorporated into it. Every time a function is left out that accumulated wisdom is being discarded too (sometimes that's good!). The problem I see here is there aren't (apparent to us) reasons or logic put forward for why things have been left out.

...

"Which is essential to you? A stand-alone application, or the ability to do all the data management that you need to do in Pro? Or both?"

- Performance. ArcCatalog is faster than ArcMap, period. If I can do everything in Pro and it's fast and UX-efficient, Cool! But if Catalog-functions-embedded-in-Pro is slower than a stand-alone Pro-Catalog... Yuk. (However unless both are built, we'll never know. I'll settle for "Is doing management task X faster/more efficient/easier in Pro or ArcCatalog 10.x?")

- Drag and Drop - only "under consideration"? Really? How can this not be a target? DnD is used *everywhere*.

- No Save Mode - how about just allowing save to the in_memory workspace? We can start with `Pro.exe --mode="in_memory"` slap Ctrl-S on "Untitled.aprx" at the beginning of a 'Catalog' session and carry on knowing the session will be discarded on exit.

(Personally I like the Notepad++ approach: 'New' documents are saved in %temp%, and automatically loaded on next startup, no saving or naming necessary. To truly discard the work, close the document without saving. There is a command line option `-nosession ` to start cleanly.)

There is no plan to create a new application in order to deliver ArcCatalog-like functionality in ArcGIS Pro.We continue to bring in “ArcCatalog” (data management) functionality into the Catalog pane and Catalog view in Pro, with much added at the 2.0 release this week and continued improvements coming to 2.1 and beyond. As mentioned in the discussion referenced above, we shouldn't consider that functionality has been taken away and you're being asked to request it back. We appreciate the user community's input to help prioritize development work. So please continue to provide focused and constructive input that will help in that process.

For this particular idea about a "stand alone" data catalog for Pro, since we've already clarified that there will be no separate application to manage data in ArcGIS Pro, we need feedback on what functionality you use most in ArcCatalog that is not possible in Pro. As newer versions of Pro are released, the number of things on that list will decrease.

What is most useful in terms of gauging priority is to determine what functionality you need, search to see if there is already a specific idea and up vote and provide your comments if there is.

If there isn't, log a new idea that is specific to what you're looking for. I'm sure you get it, but as an example, if I post an idea like:

Title: Better data management in Pro

Description: I need to be able to rename shapefiles in Pro, export data by right-clicking in the Catalog pane, rearrange fields in fields view, use interactive input with the extract data tool, save my SDE and server connections, and drag and drop data...

Let's say that this is getting a lot of votes. How do we know what part the community is voting for? Should we prioritize rearranging fields in fields view over renaming shapefiles, or renaming shapefiles over saving SDE and server connections? The more discreet and well-articulated an idea is, the more meaningful the score is. An idea that is more vague and includes a handful (or more) of ideas, is less meaningful in terms of trying to understand the impact of implementing a specific functionality.

This is a pet peeve of mine. Why can't we simply ask for all of the ArcCatalog functionality? Or have ESRI produce a list of the functionality that won't be ported to ArcGIS Pro? It shouldn't be the customer's job to keep evaluating Pro and putting in requests for the functionality that isn't there. Just my opinion...

I couldn't agree more. It's frustrating to hear the Pro is going to replace ArcMap, which will ultimately be retired, and we the end users have to spend valuable time justifying why important features, which we already advocated for in ArcMap, have to be re-justified in the replacement product.

"There is no plan to create a new application in order to deliver ArcCatalog-like functionality in ArcGIS Pro"

That is very disappointing to hear. I'm currently mucking about in Pro 2.0, with the hopes that the new version had at least some of the Arc Catalog Functionality. Unfortunately, no it does not. The deal breaker for me is that I have to create a new "Project" just to access the "catalog". 99, more like 99.999% of my time is on GIS data management. I rarely, if ever, make a map or practice cartography. With Catalog, I can have 2 or 3 instances running (without having to start a new "Project"), be looking at forestry plots in preview mode on one monitor, adding a field to a wildlife GPS collar feature class on another, and compressing a GDB in another (still have a 4th monitor free....). I can sort GDB items alphabetically or by what they are (feature or object class), two things that I cannot do in Pro 2.0 catalog (or at least I haven't figure out if I can or can't). In Pro 2.0, if an item has a long name, as items in a SDE do (e.g DBNAME.DBO.SASQUATCH.SIGHTINGS_POINTS), the (box?) with the item name is truncated, no way to resize the (is it called a description box?). And what happened to preview? The afore-mentioned forestry plots? I have 30 different projects with forestry plots. Sometimes it's quicker for me to make a data management decision based on geography (are we dealing with the one in TN or NC?) then to start looking at names, or 22 mouse clicks to get to the metadata. In Arc Catalog, I can select many (or all) GDB connections and disconnect them; in Pro 2.0, can only disconnect 1 at a time. So am I going to have to create an idea for each one of these, get 70+ comments and 2000+ votes (for each one), only to read that "There is no plan to (long list of things that work in Arc Catalog) in ArcGIS Pro" ?

Thomas, I couldn't agree with you more! I would suggest that everyone going to next week's UC stop by the ArcGIS Pro island and tell them the same thing that ArcGIS Pro must have strong ArcCatalog type functionality or create a standalone product like ArcCatalog for Pro!

And / or, bring it up at Friday's closing session. Unfortunately, I couldn't get approval for this year's UC.

I heartily agree with all that has been said on why we need a true ArcCatalog-type tool for Pro and that we should continue to promote and ask for this. However, if for some reason this is not ever going to happen, as an alternative, maybe ArcCatalog needs to remain a separate supported product (even beyond the ArcMap days), with additional support for ArcPro. That is, keep ArcCatalog as standalone. Since many of us need the data management and GP abilities of that, more than the "project oriented" needs of Pro, maybe that is an option.

Just throwing that out there. (and not trying to start an argument, maybe just a possible alternative)

I am surprised this idea hasn't come up in this thread already. From a user standpoint who cares if they create an entirely new application to run parallel to Pro? I love this idea, why not divorce ArcMap from ArcCatalog and continue to utilize the ArcCatolog for Data Management. Unless ESRI significantly changes the structure of files, there will be hardly any need to shift. I get why ESRI is switching to the 64 bit pro, but those features don't matter much for Administration.

ThanksKevin Wyckoff . I thought about posting this several times but kept backing off.

I do see there may be a few hurdles on the GP side...i.e. updating the Python version for Catalog, so to make it compatible might take a bit of work. But in the long run, as long as we can read and create compatible files that Pro can use, I think that is a step. I think a true 64-bit Catalog may require the same "from the ground up" approach. It may never be fully Pro compatible, but the more important thing is for us to be able to get the work we need done, done. IMHO

"For the item names getting truncated, you're talking about this, correct?" Yes. On that same note, what's with the (what are they called, Item Description boxes?). What happened to the Windows-Explorer-Style option (in Arc Catalog) where you could choose list, grid, or thumbnail view? As I manage 30+ SDE databases, each with an average of 200 feature classes, this very-large "box" with an icon and the feature class name, where I can only see, at most 30 "items" if I set my monitor resolution to "go blind mode", is quite frustrating.

I'll have to get back to you on the preview thing. Hunted for it for hours. Maybe because it's at the bottom now (as per your screen shot)? That's like driving a center console shift rental car when you own a column shift: when you try to go in reverse you put the blinker on......

Timothy Hales,Robert LeClair said to reach out to you. Please review the issue in this idea thread and my questions just above about evaluating the votes on ESRI's Ideas site and reply if you have any information.

David Wheelock, Thank you for your contribution to the community. We have an advocacy team that reviews ideas and prioritizes them based set of criteria. Providing use cases as you have done is a great way to build support for your idea. I will pass along the information that you have provided to the team. Thanks!

Timothy, how do you evaluate the voting numbers as described in the comment above from 11:35, yesterday? Do you just go by raw numbers or do you attempt any user segmentation by experience level or role?

David, I am not part of the customer advocacy team, so I do not know the exact details behind the evaluation of ideas. I manage the daily operation of the GeoNet community as a whole, but I did notify the team of your concerns.

I sure hope this gets implemented! I love ArcCatalog and do not like the interface given by Pro. Being a data-oriented person (as what most GIS people are), a catalog-like format needs to be included in Pro!

A new point to add to the mix: I do everything in a small GIS shop (for a larger org), from data, to managing data, to maps, to web maps to services and widgets/scripts. I understand that Pro is supposed to be part of the package along with Desktop (at least for now). However, after creating a new data set in Pro and adding metadata (in Pro); I opened the metadata in Catalog, only to have it change it. Reopened in Pro to confirm that Catalog had in fact overwritten the original metadata. This is an indication that these two programs don't play well together.

I manage analysts who use a lot of different services and SDE/DB connections. I too find Pro's project-based approach to data management insufficient when compared to Catalog. Just lending my voice to the chorus. If there is no Catalog equivalent forthcoming in Pro, I will not recommend migration for my organization, even in light of Pro's many superior features.

I echo all the comments above. I do geologic mapping - managing geology GIS data, as well as all the ancillary data that goes into our maps. I use ArcCatalog constantly, largely for the reasons I assume it was designed. It's the Esri version of Windows Explorer (and more, obviously). It's ideal for searching through data, examining a feature class geodatabase, raster, or other data - quickly, with little hassle. I also use it to create and edit metadata, for which I still use the FGDC Esri add-in (I've never liked the "Esri metadata" they've tried to get us to adopt at 10.x). Catalog also works well for copy-paste actions, and I also use it frequently for Toolbox operations. Given that much of what I do is about creation and editing of data (NOT necessarily projects), then preparing that data for archiving in addition to mapping, the last thing I want to do is create a project every time I need to copy a feature class from one gdb to another or edit a feature class' metadata. I'm sure Pro will eventually meet my map-production needs, but I am very concerned about its suitability for data management and metadata. The way it stands in Pro right now, it seems a bit like having to open a new blank document in MS-Word to look at the files in your Windows directories.

One thing related to this is the issue with deploying connection (SDE) files to users. When we install ArcGIS "non-Pro" on a new computer, we run a simple batch file that copies a set of .SDE files to their appropriate ArcCatalog location. This way, all users have the SAME NAMES for their connections, which makes support much easier. I've standardized these to be like "AerialsDB as Browser", so everyone knows that particular SDE file is a connection to our Aerials GDB as the Browser (read-only) user. Some users who have edit rights to specific GDBs get additional SDE connection files. This makes it easy to deploy changes such as moving to a new server; all we have to do is re-run the batch file which replaces the old SDE files with new ones.

So now I'm checking out Pro 1.4. OK, I'm slow. I'm horrified to see that the connections files must be created anew for every project (since the .SDE files are placed into the Project folder). This wastes time, and users will create all sorts of odd SDE file names. OR, they would have to browse to SDE files in a common network folder, which is awkward and clumsy.

I called tech support over this, and was told that since it's now project based, it has to be that way by design .. Designed by who? Apparently, someone who has never tried to deploy or use the software in a production environment. The answer isn't really correct, either, since it could feasibly be project-based AND have local lists of resources to draw from.

I can see that if the proposed Catalog Pro is allowed to exist, then the deployment of .SDE files should also be made easier.

So ESRI (In this forum) suggested to call tech support on this issue, and tech support replied, "It's not an issue", yet virtually every user of Pro is saying "This is a big issue". Remember when Coke changed their formula (New Coke)? From Wiki: "...it remains influential as a cautionary tale against tampering too extensively with a well-established and successful brand.".

That doesn't surprise me coming from ESRI. Everyone who cares about this issue and is going to the UC should make their voices heard! You can have 10 times the number of votes on this Idea and ESRI would ignore it. /rant

Granted my uses for traditional ArcCatalog also reside in ArcToolbox but I use it to manage privileges for newly loaded feature classes in SDE as well as adding/editing coded domains for feature class fields. ArcToolbox has always had an annoying lag time for displaying that dialog so it's much faster and more direct to just right-click the feature class and select the needed operation.

Thanks for getting this conversation going David. I am a technician for a small university shop. I am def open to change and have always rolled with ESRI updates as part of the GIS 'landscape.' I think Pro will get there eventually. ArcCatalog, I absolutely love and hope ESRI figures out how to include in Pro, the project pane is def not Catalog. After experimenting with Pro a few times, and I do like a majority of the features, the first thing I checked is whether or not a user can view the project file (.aprx) in the project pane: no dice. Same goes for ArcCatalog. There probably is a good reason for this, any thoughts out there?

I'll come at this from the other side of the "fence" so to speak. I spend the majority of my time as a systems and server administrator for our GIS department and handle the databases and arcgis servers support. I might use desktop only a handful of times a year. However, I do use catalog many times during the week and think it's a perfect tool for administrator tasks that works quickly and efficiently. I would hate to see it go away and the thought of duplicating some of my administrative tasks in arcpy make me cringe.

I'm in my agency's central IT group and function at the Spatial Data Administrator. Unless I'm publishing map services I spent the whole day in ArcCatalog only. In AC it's so easy to view feature classes and table when all you want to do it check a feature classes geographic extent or see a list of fields.

Often, I've got two ArcCatalog windows open. I've built a large number for models to do my data management tasks including a tool that compares the table schema of two different feature classes before doing a truncate / append. With two AC windows open I can drag in target feature class from one geodatabase and a source feature class from a different geodatabase with no need to navigate between the two in one ArcCatalog session. This saves me a lot of time doing data updating and management tasks.

I've got other use cases but if the programmers behind ArcGIS Pro don't management data they will have no clue what ArcCatalog is even for. Users like me will only migrate over to Pro if Pro did do everything ArcGIS Desktop can do. I'm reminded of the ArcInfo Workstation to ArcGIS Desktop migration. It wasn't until version 9 came out that I was able to do the same job in Desktop that I could do in Workstation! Back then I needed scripted geoprocessing in order to leave AML behind and ArcGIS Desktop 8 did not cut it.

Your emotion exemplifies the frustration that nearly all serious data managers feel in this situation. We NEED a fully equipped geodata management tool like ArcCatalog in Pro. As GDBA's we're a minority in the GIS community compared to regular users, so the number at the top is not huge, but it's not small, at all. At 1520 right now, this idea is 103 out of 12,105 ideas to date. That's in the TOP 1% and DEFINITELY getting a lot of support.

I will add a word in ESRI's defense here, by way of example. I had a terrible time with ArcMap 10.0 crashing and having all kinds of problems that only I seemed to have. Now, when I upgraded to 10.0, my habit was to copy all of the old config files from the previous X.X version of ArcGIS. I wondered if the problems were related to copying in incompatible configuration settings from 9.3.1. So, when I upgraded from 10.0 to 10.3.1, rather than doing a mass configuration copy, I have individually made each setting, recreating data connections, etc., and ONLY as needed. 10.3.1 has been very stable for me. So my goal was to only add the settings and features that I need and do it through the front door rather than doing a back-door mass copy. This keeps my 10.3.1 where it only has the features that I know I need.

Yes, it's been kind of a pain in the %%%. But my 10.3.1 has been very reliable.

I think ESRI is following the same strategy, here, with Pro. There's a ton of stuff in ArcMap and ArcCatalog and ESRI is trying to only bring over the features that are really needed. Yes, it's a HUGE pain and I feel it, too. Pro, desparately needs a data catalog, multiple instances open at the same time, drag and drop addition of layers, clip data frame to shape and much more.

I'm not sure where the middle ground lies, but I sure hope ESRI finds it soon.

As many others have stated, I also use ArcCatalog extensively. I haven't used Pro that much and I didn't know it does not have an equivalent to Catalog. Frankly, I CAN'T BELIEVE there is no Catalog!! Without Catalog, Pro is almost useless.

I'm in the same boat. I'm an administrator and not an analyst and I prefer Catalog over using a full blown Map application to efficiently do my daily tasks. ESRI can put Catalog into Pro, but I won't use it. I would like an updated Pro "version" of Catalog that stands outside of Pro. Why on earth do I need such a click intensive full blown app like Pro to do admin management when Catalog does quite well on it's own. So I agree with you 100%!

I want to backup what others are saying above. I am the only member of our staff working solely on geospatial projects, so I need the ability to quickly shift gears from editing to administrative work. We have two main enterprise geodatabases, but utilize several file geodatabases for a variety of projects. ArcCatalog is an amazing product for administering those disparate data sources. It would be a major detriment to my workflow to lose the functionality found in ArcCatalog.

I have python adding (ArcCatalog). I know the addin is not supported in Pro, but the Toolbox/tools in theory are (with some upgrading for Python 3.x.) However, I would like to maintain my toolbox/script/custom-mods folder structure. This would most likely be on a network(UNC) drive, in a folder that I use for development (or a clone of it, but not installed on each user machine, since it is not an addin).

The issues I am having right now in trying to test this

I have to open up a project (just a saved empty on) to debug in the ArcGIS Pro python environment

Using the ArcGIS Pro GP environment for debugging is not helpful

:Main issue: I haven't figure out how to reference my modules that are in my folder structure (do not want to install in the python folders for a number of reasons) Note: it looks like if you could set the arcpy.env.scriptWorkspace variable, this might have potential, but it mixes-up the "\" "/" path syntax (maybe a bug)

edit 5/10/2017: I'm getting closer to figuring out the loading of mods out my mods..fwiw.

One thought that hasn't been brought up yet....I know that ArcGIS Desktop is on the virtual chopping-block for 5or so years from now, but even if ArcMap gets phased our for Pro, why can't Catalog live on, with the added capabilities to handle any new format? Granted it may never be true 64-bit, but at least we can still carry on with administration and non-visual/interactive geoprocessing tasks. Not a perfect solution, and would still take esri development to add/maintain tools, but I would rather use an older, reliable platform, than have the overhead of Pro for GP/dev work. IMHO

I want to share an insight that occurred to me as my organization is shopping for an Enterprise Content Management System. We have explored several platforms for managing content of all types and the strongest contender thus far have had a structure similar to ArcCatalog. These platforms aren't considered strong because they are familiar, they are strong because they are straight forward. Cheers to ESRI for creating such a strong data management application. And curses to ESRI if they lose sight of the gem they created and roll forward without this component.

The majority of use cases that apply to me have already been described well. A number of people have pointed out that the group asking for this is small in numbers, but I am sure we have outsized influence in our organizations. The programmer in me likes new and shiny. I applaud ESRI for starting from scratch with Pro and see where there are nice improvements. But if Pro is missing key workflows for my analysts AND makes it hard for me to effectively manage our enterprise data, then why would I promote its use?

Yes it is 1.x software and we still have ArcMap, but it isn't being developed in a vacuum. Right now, ESRI still owns the desktop. There are lots of interesting alternatives for the rest of the GIS stack. With non trivial costs to retraining staff and migrating projects to Pro, it opens the door to potentially reevaluate our software choices.

Like so many others, thanks for making this comment!! I am also like others out there -- I do all of my data management in ArcCatalog and my mapping in ArcMap. The ability to access the Catalog tree from inside an MXD is nice, but definitely not my default way of managing data. I'd prefer to see an option in Pro to open "Data Manager" instead of a "Project". Also, there are members of my organization that rarely, if ever, make maps -- their role is much more closely tied to and focused on data management. Their needs are specifically centered around ArcCatalog.

The fact that such a fundamental and simple data management operation took over 2 years to implement, not counting the time before that in pre-release, does not bode well for our other ArcCatalog concerns. I hope you can appreciate our reticence in jumping on board with this as evidence before us.

I have a number of data validation scripts that I run using ArcCatalog, because some of them have problems with data locks if they run in ArcMap. I've also found that processing complex datasets is faster and more reliable in ArcCatalog because it lacks the overhead of drawing the map.

We can't use Pro for our day-to-day workflow, though we have experimented with it to familiarize ourselves. Our primary data format is personal geodatabases, Pro still lacks several of the geoprocessing tools we use on a regular basis, and our scripts are going to need significant work to migrate to 3.x (I've checked), and I'm the only developer on the team. My comment is based on my experience with using Desktop; the Catalog tree inside ArcMap is not a satisfactory replacement for ArcCatalog. It's slower than ArcCatalog, I can't select multiple items, and even if I pause drawing in ArcMap, tools take longer to run, they take more memory, and the results are inconsistent.

With regard specifically to ArcMap's Catalog pane "can't select multiple items": you can with Toggle Contents Panel and then using the lower panel. (Standalone ArcCatalog still preferred for many other situations).

During one of the sessions at the 2017 User Conference, one of the presenters mentioned that Personal Geodatabases will no longer work in one of the future releases. Hopefully an Esri staff can comment and provide more specifics about the planned deprecation for PGDBs, so users can start planning on migrating PGDBs to something else.

If you have many, many data sets from which to choose (e.g., extensive robust statewide GIS database), and you want to be able to preview data sets or most importantly take a look at the attributes, an ArcCatalog equivalent is a MUIST!

Fully agree with the folks on this thread wanting a standalone catalog application or some equivalent "mode" in the ArcGIS Pro world. In the name of providing constructive feedback, here are a couple of issues that I don't see previously noted in this thread:

In ArcCatalog, one could enable additional "standard columns" to be shown in "Details View". This wasn't so reliable for enterprise databases, but was invaluable for file geodatabases - I personally rely on Size and Modified date daily. There doesn't appear to be any equivalent in Pro today.

In Pro, it's possible to enable "Catalog" as a Pane or a View, but if one enables both in the same project - to try to approximate the look and feel of ArcCatalog, browsing isn't linked - selecting an element in the Pane does not bring that element into the View or vice versa. This simple combination of treeview and pane view is central to the navigation expectations of this user community, and all the UI elements are there, yet the UX is broken. This seems like an easy win.

I'm used to dragging and dropping feature classes and tables from the ArcCatalog view into GP tools or the Python window when I need to use them. If we've already browsed to our data, why force us back to a new browse tree when we want to use those data in a tool?

Something in your comments sparked a thought that might make me move to Pro, if it was developed for Pro....the old GeoDatabase toolset (GDBT) with the graphic "version lineage". It still works with ArcCatalog, although you have to trick the OS a bit to get it installed. If this was somehow a new supported feature in Pro....might make me take second look...but changes are it will not be ported, so another plus for keeping ArcCatalog.

As with most things, people tend to take different paths to get the same job done based on their personal preference. I like using ArcCatalog for browsing, checking and previewing data and tools side by side and separate to ArcMap. Whilst the Catalog and Add Data windows in ArcMap are handy for exactly that, they are limited in the data management functionality (only single selections in the Catalog window). The Catalog window also interacts with the Map layout which is not always a desirable feature.

Like others in this thread, I use ArcCatalog more so than the mapping applications themselves for the data management side of things. Or to do a whole bunch of conversions and what not. I absolutely hate having to launch PRO up right now to do anything.

Thank you, David, for raising the flag on this one! I don't have an in-depth use case at the ready, but I'm adding my voice to the growing demand for the full functionality of ArcCatalog to be available in the long term. It is essential that users can continue to browse data and work on data processing, scripts, models, etc. outside of the main mapping environment. I'm not a Pro user yet, but as a Desktop user I can go days without opening ArcMap. I'm in ArcCatalog every day. Just being able to view lists of feature classes rather than the larger "cards" shown in a screen grab in a previous post is a huge bonus.

-To browse large .gdbs and access and update the metadata. Often similar datasets will have similar metadata entries, it is easy to copy / paste and flick back and forth when updating metadata in Catalog.

-To carry out various data management techniques on incoming data and mitigating the data into our company structure. I usually get .gbs of data and I can't see how just working within Pro will help me carry out this task.

-Often I need to quick assess the extents (geometry) and the attributes to ascertain its final location in our company structure and its correct naming convention. e.g. site roads v regional roads etc

I need Arc Catalog functionality for pro as well... That being said, if Esri doesn't want to make a separate program I have a compromise.

Put all of the Catalog functionality into this giant waste of space... preview and details are nice but they do not do anything. Imagine being able to right click and create a new feature class, oh how wonderful it would be. Everything we have ever learned about data management in a user friendly box that currently takes up 70% of the window and is currently unusable. I am very passionate about this and feel that this could be a great place to put the Arc Catalog functionality we are all wishing for.

I like change when it's good and progressive. That's why I am trying ArcGIS Pro again. I tried it once at Version 1.0 and couldn't deal with it. The lure of [potential] speed, and some of what I'll call the pretty business intelligence features brought me back. 64 bit is the future, but not when it has less functionality than it's 32 bit predecessor ArcMap. Smooth and buttery display and ribbons may attract surficial Arc "users", but hardcore analysts need hardcore functionality. I am an analyst who also manages the data. I keep the Catalog pane open on a separate monitor while working in ArcMap, ArcScene, or ArcGlobe. The workflow makes analyzing and managing data very seamless and efficient. Please integrate ArcCatalog with ArcGIS Pro. As it currently exists, ArcGIS Pro is simply another App in the suite that needs more development before it can play with the big boys.

What's more, maybe it's a software development requirement, but a new file geodatabase and toolbox for every Project seems a bit cluttery and disjointed. Can't Projects just be a file extension like maps, scenes, and globes; and the data and tools continue to reside in their respective structure in ArcCatalog and ArcToolbox?

For the workflow of having Catalog open on one monitor and ArcMap, etc on a second monitor, I wanted to make sure that you were aware of the Catalog View (not just the Catalog Pane). Since you can have multiple instances open in Pro 2.0, you could create a project called Catalog, and use that in a way similar to ArcCatalog. Open it up, have it on one monitor, and work on a different Pro project on a second monitor.

Alternatively, you could open the Catalog View in your working project and tear that tab away, placing it on the second monitor. This experience would be a bit different, as the contextual ribbon, even when the Catalog View is in focus, remains on the main monitor. Just throwing some different workflows out there.

For the issue with projects creating new gdbs and toolboxes, that is the default but you can easily set up your projects to always point to the same default database and toolbox.

I changed all my defaults in ArcPro, per the Help, to not create new folder, and point to default toolbox and default file geodatabase on my hard drive. Yet for every new Project, I still have to spend 5 minutes remapping the default catalog that contains decades of well-organized data in folders and geodatabases... the one where ESRI told us to put everything originally. I then spend another 10-20 minutes finding URL addresses and passwords to any necessary server/service connections. EVERY TIME!!! When the CEO wants something on the spot for a board meeting, I don't have 20 minutes just to get TO the data. I spend time connecting ONCE, so I can be efficient going forward, not do it all over again when I need a different map. The more I use Pro the worse my experience gets. The time "saved" with 64 bit environment is quickly negated with these terrible workflows and the qwerky interface. I couldn't care less how "slick" it feels. Slick doesn't get work done. After over month of pushing myself almost exclusively on Pro, I am officially downgrading it to be used only for heavy processing where multi-threading can be utilized.

A little background about the architecture and reasoning behind this (as far as my understanding goes; i.e. I'm not the product engineer:) ). In ArcMap/ArcCatalog, if I'm working on a map for a city in Oregon, I'll probably have data specific to that project. It could be a certain server or servers I'm connecting to, enterprise database, and/or one or more folders containing data that is needed for that project. So when I make those connections, they're always there. Which is a good thing if I'm always working on that project and with that data.

But then say I go to work on a project in New York. And I add all of my folder, server and database connections for that project. Now, when I open ArcMap to work on my New York project, I get a list of connections to everything I've ever worked on. We've all seen how this can quickly lead to a long list of folder connections, server connections and database connections in ArcCatalog, or the Catalog window in ArcMap.

In ArcGIS Pro, under that same scenario, you would set up an Oregon project with only the connections you need, and a separate New York project with only the connections needed for that project. You might say, well, I often have some general connections that I like to have handy for ad hoc work - that I can throw in any project whenever. This would be a good time to add those generic connections to your Favorites, but not necessarily add them to every new project. That way, if you're working in a project and want to quickly grab something from there, just go to your Favorites and add that connection to the project and work with it.

So you might have your 200 various connections from ArcCatalog in your Favorites, but you don't have to add those to every project you're working on in order to have quick access.

You then say, well, all my work is in the same place and I pretty much need all of the same connections for everything I do. Great - add those to Favorites and make sure to mark the items as Add To New Projects. Now any project you open in Pro will have all of your connections made.

Please let us know if this helps to explain the workflow and reasoning. And as you set this up and work with it, let us know where you think it can be improved.

Woah, wait a second- My understanding has always been that Arcmap tries to verify connections to only the data layers present in the MXD but you seem to be implying that Arcmap verifies *ALL* entries listed in under the Folder Connections (even data paths not being used in that MXD). So which is it?

Thank you for requesting clarification. I checked with the product engineer and confirmed that we only validate when a connection is expanded (in ArcMap and ArcGIS Pro) for performance reasons. I've edited the post above to remove any implication that all connections are validated on startup. Hope this helps!

After using favorites, I find that duplicates are being made of certain things. Parentheses are put around numbers...eg (1), (2), (3), just like ArcCatalog used to when a copy was made. And it's very difficult and/or confusing to understand exactly where these duplicates are coming from, being created, or going to. In the original ArcCatalog things are easy to understand and track down. Everything is in one place. A new instance of Catalog is not the same solution, and the new way of "organizing" does not appear organized or even resource-efficient at all. It's like a data bomb exploded and sent files in infinite directions, and it's up to the analyst to figure out where they exist... parallel to maintaining a daily workload.

Also, after changing settings, and removing new auto-generated geodatabases and toolboxes that were created under the former default settings, they come back, like I'm not deleting all of the files. This is not surprising, as the former ArcCatalog workflow involved going to one location and "deleting". Under the new system, you have to perform a treasure hunt under all the ribbon tabs, and the items you find may or may be the actual "data".

Kory Kramer I completely support this! Just today, I was working on the SQL backend of our SDE Geodatabase and I was running a SQL Query to determine duplicates and to determine where one field didn't match part of another.

I was working with our parcel fabric and I was unsure of what the name of the layer way within the database and I instantly went to ArcCatalog because it was a database administration function not a project or mapping function.

I understand the need for Projects and I love the projects ability to have multiple layouts. A Project in my mind works on one issue. So for me I have a Street Index Map Project that contains all my print layouts and formatting for our Street Index Map. But there needs to be a way to administer a database (which touches all projects).

After talking this over with Kory Kramer I feel that this issue will be resolved with the implementation of the following idea: Open ArcGIS Pro without having to Save. By doing this, we will be able to use the Catalog that is contained within ArcGIS Pro but not have to create a project for doing database management. At least in my view, the idea of having the standalone ArcCatalog application only serves one purpose and that is to do database management. If we can solve that by allowing Pro to have the functionality that ArcCatalog has and more, then I would be ok with only having 1 application.

As a note, Esri seems to be moving in the direction of having a single GIS application rather than having ArcMap, ArcScene, ArcGlobe, and ArcCatalog. While I agree that ArcGIS Pro at the inception did not have the functionality to support this direction of the software, they have now enabled us as users to have multiple instances of ArcGIS Pro running at the same time as well as having the Catalog within ArcGIS Pro. Therefore once I am able to open ArcGIS Pro without having to create a project I should have no more issues with the above idea and in my mind, while it wasn't implemented, it has been resolved through other development efforts.

As part of the ongoing discussion around data management capabilities in ArcGIS Pro, I wanted to make sure that anybody following this thread, or those who might discover it are aware of how to best manage connections. Favorites was new at Pro 2.0 - this blog gives a couple of examples of how Favorites can be effectively used.

I found another reason for justifying Arc Catalog functionality in ArcGIS pro. I attempted to edit Aliases of field from a file geodatabase in the Fields Design view from the catalog window (not to be confused with the fields design view from the map view which is identical but has a different purpose). If you type one word in proper case with no spaces, hit enter, and save the word does not save. If you add a space after the word it saves. I have a entered a support request with Esri support so we will see what happens. My point is, that this is something Arc Catalog can do very well, and this is something that ArcGIS Pro needs to be able to do. Thank you for everything and have a delightful day.

Kory Kramer Is there a reason why the Alias does not allow for spaces now? That was one of the nice things about Aliases is that I could design my database with something like "PedID" but have the alias say "Pedestal ID" so the field crews know what the fields are.

Kory Kramer I promise you I wasn't lying. I am Using ArcGIS Pro 2.0.1... The only thing different from my experiment versus what you did, is the field name was the same. For example, the field was named EASTING and I changed the alias to Easting. The current layer does say Data Source. After I made my original post I switched to Arc Catalog because I need to get this done. Once I saw your response I went back into Pro and it is working, at least for now. The only other thing I can think of is, I was doing a full feature class at a time, so sometimes 20+ fields. That was when I was seeing the save not saving more consistently. If I can recreate the problem I will try to take some screen shots.

I promise I was beating my head on this for a while before I posted and now it seams to be working... Maybe threatening to use Arc Catalog made Pro start to behave (that was a joke, please laugh).

As Requested, the result was a bug. BUG-000109063 -> Field aliases are not maintained when modified from design view in ArcGIS Pro. My previous point stands. This is basic functionality of ArcCatalog and should be included in ArcGIS Pro. Thank you for everything and have a delightful day.

"Metadata updates are not permanent until the project has been saved. Metadata for project items is stored within the project."

This is a huge problem for me and I suspect pretty much everyone.

The layers / features themselves need to be 100% independent of the project. I need to be able to enter metadata for a feature and subsequently be able to view that metadata for that feature regardless of what ArcGIS project I am viewing it from, or even what platform I am viewing it from (other GIS applications, viewing the xml directly via a browser or other application).

I want to be able to open and view it / call on it from a web browser, text editor etc, just I am able to with metadata generated in ArcCatalogue (my primary application).

When I export it (to be consumed in another application) I want that metadata to persist (I beleive thats another discussion though as ESRI metadata is by design, not designed to play nice with other apps)

"the geoprocessing tools that support managing metadata in ArcMap are not yet available in ArcGIS Pro. Importing, exporting, and validating metadata must be managed using other applications in the ArcGIS platform. For example, after authoring valid metadata for a specific standard or profile, export this content to a standard XML format that can be published to a metadata catalog using ArcCatalog or ArcMap."

TLDR - Don't use ArcGIS Pro until we have everything ported over from ArcGIS for Desktop platform ;/

Based on my experience with ArcGIS Pro so far and everything i've read on this topic; this idea should have an Under Implementation status. Upvote this!

Ryan - you're right that this area of ArcGIS Pro is being actively developed. The reason this is not marked as Under Consideration is that the idea is asking for a "stand-alone data catalog like ArcCatalog".

We commented in June:

There is no plan to create a new application in order to deliver ArcCatalog-like functionality in ArcGIS Pro.We continue to bring in “ArcCatalog” (data management) functionality into the Catalog pane and Catalog view in Pro, with much added at the 2.0 release this week and continued improvements coming to 2.1 and beyond. As mentioned in the discussion referenced above, we shouldn't consider that functionality has been taken away and you're being asked to request it back. We appreciate the user community's input to help prioritize development work. So please continue to provide focused and constructive input that will help in that process.

For this particular idea about a "stand alone" data catalog for Pro, since we've already clarified that there will be no separate application to manage data in ArcGIS Pro, we need feedback on what functionality you use most in ArcCatalog that is not possible in Pro. As newer versions of Pro are released, the number of things on that list will decrease.

Thank you again for helping in the development of Pro.

BUT, we don't want to mark the idea as Not In Current Product Plan - I think we've clearly stated the intent in the quote above. With that in mind, please continue to share functionality that is important to your work that you don't yet see in ArcGIS Pro.

Kory, I just wanted to say thank you for your great communication on this thread. I came into it wanting a stand-alone analog to Catalog, but after reading your comments I now understand much better why that's not necessary. I do hope the missing features requested elsewhere in this thread are implemented, but until then it helps a good deal to know what already is available.

The statement that the ESRI Pro development team simply won't develop an equivalent to ArcCatalog separate from or within ArcGIS Pro is very unfortunate. I teach multiple GIS courses each semester. ArcCatalog provides an efficient way for me to quickly access student project files (and data). Doing this in ArcGIS Pro takes 2 to 3x as long. Plus--when navigating in the ArcGIS Pro "Catalog" tab you can not "preview" a .aprx project file (at least as far as I can figure out). In terms of database management Pro 2.0 is clearly not ready for prime time--in my view.

When you refer to "quickly access student project files (and data)" can you provide some more details? What kind of "project files" are you browsing from students in ArcCatalog? Are you just browsing, and then what, previewing? Previewing the tables or previewing geography, or both?

Understanding more precisely what you are not able to accomplish in Pro would be helpful.

Arc Catalog: Can resize things in any manner I need to display the massive amounts of content I manage. There are no "Giant Boxes" forcing me to scroll forever. I can see everything "above the fold" in a single glance.

The "preview" function in Pro is on average, 5-50 times slower than it is in Arc Catalog. Why? Because it's throwing a web-hosted base map underneath the preview. Why? I don't want or need a basemap, I'm previewing the feature class, in fact, the basemap makes it harder for me to see what I'm previewing. There's an option to turn off base map you say? How does one make this option permanent? Speaking of the Pro "Preview", what happened to the Identify tool that was in the Arc Catalog version of preview? Table view?

"is noted" means that the idea is marked as Reviewed and I'll have to check with the team that owns that functionality to get an update on its status. Depending on what I hear back, we'll update the status accordingly.

Kory Kramer some time ago you mentioned "...As a workaround, you could create that "ArcCatalog" project that doesn't contain any maps, just the Catalog View. Open that to do data management and close the project without saving.". I'm really rolling up my sleeves and trying hard to find a reason to move a major GIS operation over to Pro, and I'm finding nothing but barriers, and nothing that will help me do my job the way Arc Does. I've even opened up a few Pro cases, solved a Pro Py issue someone was having, maybe I'll get some things fixed/upgraded that help everyone out.

Referring back to the quote, when I "...As a workaround, you could create that "ArcCatalog" project that doesn't contain any maps, just the Catalog View. Open that to do data management and close the project without saving."., I can't "drag" things (content? items?) from that so-called "Catalog Project to one, or several, instances of Pro. Let's say I have 4 Pro projects open, and I need to add data to each one of them. For each one, I have to drill/navigate through Catalog, with these giant "boxes" that force me to scroll/pan forever, to find the content I need (4 times). I can't drag layers from one Pro map to another Pro map, which is something I, and most of the users I support, do on a daily basis in Arc. Most of us have "Base Maps" saved to My Documents, with commonly used layers symbolized and labeled the way they want. They typically keep this map open all of the time, and drag what they want to a new project-specific map.

So yesterday, I had a pretty massive map production deadline, 14 maps, all different places/data/themes. I had one Arc Catalog open, open/start the first map, drag my data over, send the map to production (plotter), while that hampster was running, open start the next map....whoa...look at this...Arc Catalog is still open, and still pointing to the data sources I need. And what's this?!?!?! I can drag things from 1 Arc Catalog to many Arc Map MXD's? Without having to restart Arc Catalog each time I start a new .MXD? I actually tested this workflow in both products, took 45 minutes in Arc, I gave up after 2 hours and 6 maps in Pro...my post-carpal-tunnel-wrist just wasn't liking it.

Very, very, very many users in this thread have expressed frustration at the workflow and data management limitations imposed by Pro. Most of these same users have clarified how and why the Arc Map -> Catalog workflow works, and works well. Broken record here, but if it works well in Arc, why is the functionality not being ported over to Pro? Why was the functionality not present in Pro 1.0? That's like Ford releasing a new car, but with no tires or engine: "We just wanted to see if everyone likes the way the doors opened first before we actually produce something that drives". Imagine their surprise when drivers complained....about the doors that open in the opposite direction that everyone is used to....

Frankly, I wouldn't care about this. If Arc Map was going to be around (and supported) for the next 20 years, I wouldn't even be able to tell you what Pro is or does. But when you add "eventually going away" to the mix, and not only do I have to suffer through a new tool, in a few years, the only tool, that doesn't meet my business requirements, AND, support dozens/hundreds of other folks that are also wondering why something that worked well for them last year has been removed from their workstation and replaced with something that doesn't, well....I'm going to make my opinion heard.

I cut my GIS teeth on Arc Info and Arc View 3.x. I distinctly remember all of the howling and and hair pulling over the transition to the 8.-9.x series. But the howling was limited to "Oh my god I have to learn something new!!!", as opposed to "This replacement doesn't do half the things that the previous version did".

Well said, Mr. Colson! Thank you for providing such a detailed use case for keeping ArcCatalog functionality in future Esri product releases. I too am a veteran of the transitions from Arc/INFO and Librarian through ArcView 3.x to ArcGIS Desktop, and in each of those cases there were significant net benefits, despite the hassle of learning new tools in a new environment. None of those major changes resulted in a loss of as much functionality as the loss of ArcCatalog in ArcGIS Pro.

My organization hasn't rolled out Pro yet, for a wide variety of reasons which I won't list here. However, the inability to perform simple operations such as drag/drop layers from ArcCatalog or from one map document to another would be very high on such a list. Keep in mind as well that many GIS administrators use ArcCatalog exclusively - they have no need or desire for a base map or to see data "in context" and rarely open ArcMap at all. Why is this being forced in Pro?

Please, Esri, listen to your users. ArcCatalog is a valuable tool. Eliminating that functionality from ArcGIS Pro will handicap many GIS professionals and seriously hinder migration to ArcGIS Pro for many organizations.

A sincere thank you for staying the course with us on this one. Your detailed explanation of how you use ArcCatalog side by side with multiple mxds is very useful. At Pro 2.0 we were able to open multiple instances. At Pro 2.1 you'll (I'm pretty sure) be very happy that you can drag from either the Catalog View or Catalog Pane and drop into a map or scene (either in the same project or in a separate instance!). Also, there will be a new display type called Columns which will get around the "giant boxes" you're talking about.

I'll be posting a blog this week about Catalog View which will provide some tips, some comparisons, and give a preview of a few of these things that are coming in 2.1.

Your pattern of doing the work you need to do in ArcMap/ArcCatalog, trying to do it in ArcGIS Pro, and reporting what you don't like, what doesn't work well, what could be better, is incredibly helpful to us. We're listening and we continue to make improvements so that Pro will meet our users' requirements. So keep it coming! As we get some of the big functionality covered, my guess is that this specific thread will fade in importance and feedback on focused functionality will be gathered and tracked through individual ideas. That will likely work best.

I'll share my blog to this thread as soon as it is published. Feedback welcome (even if I didn't say that, I'm sure we'll get feedback:) )

For your first scenario, yes, if you click on Databases in the Contents Pane, you'll see a list of databases in that Project:

For the question about clicking into a feature dataset, or folder, the subsequent clicks are within the view, not the Contents Pane.

Continuing with the above screenshot, clicking on Databases in the Contents pane doesn't do anything else - I can already see the databases in my project. If I want to drill into one of those, I can double-click it.

I think the functionality should be continued throughout the process similar to ArcCatalog. The double click to drill is an extra click and ArcCatalog is more intuitive in that regard. I was on the phone with an Esri professional about a support case and that person didn't even know about the double click. It is my belief that if this functionality was set up like ArcCatalog the user experience would be more friendly. Thank you for everything and have a delightful day.

The indexing thing could be something that the team knows about - but I couldn't find anything logged through technical support, so if you can grab some shots of it happening while you have it turned off in Pro, please share the case through support to get it logged.

I think Hannah does a good job giving some examples of when you might want connections only in one project vs. adding to all projects. Bottom line, if you want to add all of the connections you have ever made to every project you ever create, you can do it.

Hope this helps. I'll try to find time to look at those screenshots you sent.

Thats seems like a step in the right direction but to me still implies that:

A) the lack of any metadata in the 'fresh layer' itself is prioritized over the source metadata.

I can see a desire to have project specific notes/comments for a feature so I guess I understand why this has been done... I don't think it is necessarily intuitive to prioritize metadata for the layer over the feature / hide the metadata for the feature.

The metadata for the feature is what should be being displayed for the layer in the metadata tab.

If the user wants to have any Project specific notes / leave it in the project where it belongs/ not with the feature.

b) (States its read only) That editing the metadata right there still isn't saved with the feature?

Without an ArcCatalog application, where are we supposed to edit the metadata for the feature?

Kory in the blog is what I believe to be a preview of the sort function in 2.1? I notice you don’t mention the ability to sort on feature type, (feature class, object class, feature dataset). In arc it is possible to sort this way. In a SDE with thousands of features and tables and hundreds of feature datasets this is critical. What was the reasoning for not porting the full arc catlog sort functionality to Pro?

Thomas, yes, you'll be able to sort by type in the columns display in ArcGIS Pro 2.1. That should look the same as what you're used to seeing in ArcCatalog. I believe the development team is also looking at providing filter functionality (not for 2.1). Can you filter in ArcCatalog?

If you’re implying that perhaps I can filter on...say...only show me point features classes? Even better, feature classes in a particular projection? APR. files created after a certain date? That would be.....handy.....

I think the largest issue with most folks is at this that we are all used to "INSTANT GRATIFICATION"... I say keep up the great work and folks allow the software to continue to mature and grow into what you need it to be. Find new ways to produce the same or better products; change old habitats and evolve with the software; as you never know what you might find out there...

Patience is a virtue true and through... I have been through all of the transitions of 3.x to 8.x to 9.x to 10.x desktop and server/internet based ESRI products and now to PRO. I mean who would have thought you would be able to live edit a Hosted Feature Service and more!!!

I am still really impressed with the leaps and bounds that the software suites ESRI produces and continues to provide to it's users.

No disrespect intended but I disagree. It's not about "instant gratification" but replacing one product with another that doesn't include all the functionality of the one it's replacing! I know it's a totally new product from the ground up but

ArcGIS Pro is still missing functionality and ESRI is requiring users/clients to ask for that functionality back through their ArcGIS Ideas site.

FYI, I have been a user since 1989 and I too love ESRI products, but as a SDE database administrator, I live in ArcCatalog and ArcGIS Pro just isn't ready to replace it yet and it's been out for a couple years.

Randy (also with no disrespect), Esri has placed no requirement on you to ask for functionality "back".

ArcGIS Pro has not replaced ArcMap, so if there are equivalencies not in Pro yet, continue to use ArcMap.

Our development teams are working very hard at every release, with ArcMap equivalency as a main driver. I encourage you to continue to check on Pro functionality as releases keep coming - if you choose to share with us pieces of functionality and equivalency issues you find that affect your specific work, please do so (but again, you are under no obligation to do so).

That said, have you checked out 2.1 beta yet? Or if you're interested in sharing what you're looking for in terms of data management, let us know here, or we can set up a call.

While ESRI has placed no requirement per se, that is EXACTLY how users feel. It's hard to feel otherwise when the user community says, 'Hey- feature X is now missing' and ESRI's response is to suggest an alternative workflow that typically has MORE steps than the previous method (running a GP tool/script vs right-click->Calculate Geometry).

My personal takeaway from your last update post was that ESRI is STILL not agreeing/committing to a standalone ArcCatalog product no matter how much activity this thread gets or use case examples are offered.

Mike is correct, it is amazing that editing a live hosted service is even possible, let alone accessible. Kudos all 'round to those who envisaged and brought that through to reality.

That's where our ideas part company though. My complaints are not about instant gratification and that ArcPro doesn't do all the cool new things as well as all the cool old things right now. My complaint is that if we don't speak up and agitate and build a community around each of the things we like and rely on in the "old thing" that there's a good chance it will not be implemented in the mainstream product.

Esri has placed no requirement on you to ask for functionality "back". ArcGIS Pro has not replaced ArcMap, so if there are equivalencies not in Proyet, continue to use ArcMap.

ArcGIS Pro has not replaced ArcMap [yet]. ... continue to use ArcMap [while you can].

Esri has clearly signaled ArcPro is where future desktop development efforts will be concentrated and that ArcMap & ArcCatalog development is stopped. ArcMap/Catalog maintenance has been promised for a very long time, but we're not likely to see new features land there. Sooner or later the distance will become too great to straddle and we'll need to choose which boat to remain on. The new boat is pretty spiffy but it's not big enough for all of our crew and supplies.

If "...ArcMap equivalency as a main driver." is the focus of the development team, then why is there even an ideas site? Kory, all you need to do is post an announcement that say, by Jan 1 2019, Pro will have all of the functionality that Arc does. There's no need for the end users to have to type paragraph after paragraph of why every single tool or function is needed...if it already exists....right? Am I missing something? I must be, because the common denominator for most of these Pro ideas starts with "In Arc Map I can do this, but Pro I can't....". In a previous life as a software QA engineer, a release or a service pack wasn't allowed to go out the door until we had completed exhaustive functionality testing, then brought users in for acceptance testing. Does the new version not include any of the functionality that the old version had? Do the end users agree with our interpretation of how the software functions according to their needs? With a background in software development, I'm struggling to understand how major software package that has been labeled as the eventual replacement for the current software lacks most of the functionality the current package has. It would be helpful if the development team took a step back and made an honest, bona-fide assessment of how current users use the current tool, Arc, and turn those into development targets (Think: Agile Method). Heck, send them out to the field to watch actual customers struggle through the day in the life of a GIS analyst.

Myself, and other folks in this forum are being quite vocal on this topic because, contrary to the statement "Well, keep using Arc then if Pro doesn't meet your needs" doesn't work in reality. IT people pay close attention to https://support.esri.com/en/Products/Desktop/arcgis-desktop/arcmap/10-5-1#product-support and the day after the last version of ArcMap hits extended or mature support, the GIS people will come to work on a Monday and find Arc gone, and Pro installed. It is actually a security policy in many organizations that installed software may not be more than 1 version out. Having software in extended or mature support status exposes them to security vulnerabilities when a security hole is found, and tech support is saying "The vulnerability doesn't exist in Pro so we're not going to fix it". I believe one of the Arc versions had some issue with xml, or Active X, that caused the security people to flip out, and "Well the latest version of Arc has this bug so we can't use it" fell on deaf ears. I myself am heavily dependent upon addins and custom tools developed by another agency. Every new version of Arc breaks the tools. I don't see them migrating those tools to Pro for many years, if ever. And we've all had that tech support case where the conclusion was "We're not going to issue a hot fix because the latest version fixes it" despite the unheard response that the latest version also breaks 10 other things. Example: "ArcGIS Pro meets your requirement for 64-bit desktop"...."But......I can't publish services to ArcGIS Server with it!!!!"......

I'll end this with something positive...I am a big fan of Vector Tiles, which you can only do in Pro, and I can't crank out VT services fast enough.

Some are concerned here about how popular an idea is, how many votes it has received, the number of views, the rate at which the score is rising. Let's see if ESRI will provide users with some performance graphs for ArcGIS Ideas so that we can see how an idea is progressing over time.

I have been working with one of the ESRI Instructors on several AGP issues and had them check in with the Pro Team at UC this week regarding some of the problems we had with Pro. Here is and update from the AGP team regarding Arc Catalog:

"there is no plan for an AGP equivalent for AC but in 2.3 they are implementing the start of AGP in “Untitled” mode meaning you don’t have to create a *.aprx initially just to start using AGP. So theoretically one could start AGP in Untitled mode, use the Catalog Pane to manage data, and close AGP without saving."

My use case scenario for an ArcCatalog external to Pro is the continued ability to troubleshoot and/or repair/remove corrupted projects/maps/layouts/layers via Catalog. Currently .APRX files do not show up in Catalog within Pro and there is no discernible way to get a behind the scenes look at them as you can with .APR arcmap files. I'm not sure if adding the ability to access catalog without opening a project file will change this, but maybe?

I confirm that at 2.3.0 (it may have been earlier) when you start Pro along with blank templates you have the option 'Catalog' from the templates.

If data management is your primary focus, consider pinning this project to the start page or opening it automatically when you startArcGIS Pro.

You can also "Start without a template (you can save it later)" to just have a blank, empty, unsaved project and after a moment it will open with your Favourites in Catalog and any items you previous set "Add to new Projects" under Catalog - Project - Databases, Servers, etc.

As Kory Kramer mentioned earlier this can be your 'ArcCatalog' substitute if you like as you can* run multiple ArcGIS Pros. You can also set it up with all the things you would need, then save it as 'ArcCatalog'. As long as you keep updating your favourites, all new items will propagate to new projects, automatically if set 'Add to new projects'.

I believe you can now also set Pro to open a set project by default when started. If you like this could be your Catalog project. Or if freestylin's your thing, you can set "Start ArcGIS Pro without a default project" as described above, automatically.

One problem with the poorly implemented "Catalog View" in Pro is, if you pop out a Catalog View in another tab as suggested by ESRI to get the "equivalent" experience of Arc Catalog on another monitor, you can't drag layers over to a map like you can in AM. When the focus is in your Catalog View in the second monitor, in the first monitor (Pro UI), the contents pane for catalog is activated, and you can't drag the layer into the map table of contents in the order you need. I'm setting up Pro for a demonstration this morning to some state gov't folks, lots of layers, got a bunch of groups in the TOC, each layer I drag over to the map goes to the top of the TOC and I have to then drag them once more into the proper place in the TOC. Lots of extra and unnecessary steps. I'll be doing the demo in AM, I don't have all morning for "workarounds". I'm baffled as to how this is considered "more efficient".

What we've suggested as a good workflow currently is to have a separate "catalog" project. This acts as your data management project and you can drag/drop into a map in another project. That is more analogous to having ArcCatalog open at the same time as having ArcMap open. It would look like this:

Will this include the ability to drill through folders in something similar to the Catalog Tree, see contents in the "Contents Pane", then drag over to the Map? This is the workflow we're struggling with the most. In Pro, clicking on a folder in Catalog Pane or View does not "explode" things and show their contents on the right like Arc Catalog does, making looking for things a much more arduous task, especially when you have lots of things.

Below, see how I can expand paths on the "left", and need only click on something (e.g a feature data set, folder) to see its contents on the "right".

In Pro, if I want to see what's in a folder, FGDB, or feature data set, more double-clicking, less real-estate is showing me all of the other folders or "containers". Where is the preview or display on the "right" of what I'm click-click-clicking on the "left"? Also note the very slight delay in opening up "most" folders and FGDB's (the spinning circle of dots): Slight enough to add up when you spend most of your day managing data. Definitely not as fast, or efficient, as Arc Catalog. This is on a dual Xeon, SSD machine, so it's not hardware.

I like the suggestions being made by Kory Kramer for workflows in Pro given the lack of Catalog, if we are indeed to lose the standalone application once ArcMap is deprecated, but the left/right database/dataset/feature class previews from Catalog that Thomas Colson is talking about I would like to see added to Pro. Scroll on the left, view contents and data tables on the right. This is bread and butter to a GIS professional/data manager using ESRI, and as a very efficient data management and QA tool. Please do replicate this functionality in Pro, if Catalog is to go.

At 2.3.0 (at least) yes, you can pop out the Catalog view pane and use that with a map present. As you say, as soon as you focus the Catalog, you lose the Map TOC. You can still drag a layer to the map though (just as with ArcMap) and it will be added at the top of the TOC, which will become active.

I'd like to see the functionality to copy and paste toolboxes in the Catalog pane in ArcGIS Pro. I have been working on a couple-month project to create a rather complicated set of tools within a toolbox, and as such, I have made different versions of the toolbox. Every time I wanted to create a new draft version of the toolbox, I had to go to ArcCatalog to create a new copy of the toolbox. Kory Kramer am I correct that this is a function currently not in Pro? I'd like to create an idea for it on Geonet but would rather have someone confirm first that I didn't miss something.

Andrew Quee, I don't really see the workaround in the thread. SQL is still the RDBMS in the examples there, which is supported by esri. We are using the OLE DB to connect to databases with ODBC connection set in Windows. The databases are not the native SQL/Oracle/etc. that esri natively supports.

I didn't know what databases you're using, so I didn't want to say it was a solution. It does answer the question posed about OLE connections - to Access (via Data Interoperability) and MySQL (via SQL Server view). If you can set up the workaround you I think should be able to use ODBC for SQL Server to get Pro to talk to your database via the middleman.

I don't use OLE DBs much myself, I was just highlighting some forums where you could pursue that specific issue and vote it up. I think you'll get far more traction with Esri from an Idea rather than just a reply.

We use Safe's FME Workbench (this is essentially what Interoperability ETL tools is) as one of our core tools and can confirm it's a great 'swiss-knife' tool for getting anything from anywhere and then processing it and putting it somewhere else. Expensive and ETL not OLE, but it 'just works'.

Now that I am getting used to the workflows, there is little I cannot do in Pro that can be done in ArcCatalog. The catalog tab provides all the functionality we need. The only reason I have not 100% converted to ArcPro is to do with unique circumstances requiring us to use the Distributed Database tools in ArcMap. I applaud ESRI for solving this problem without a seperate application.

ArcCatalog allowed users to see python files this needs to be added to the to the ArcGIS Pro Catalog functionality.

Make it easier to connect to drives not mapped to a drive letter. I view, data and maps from about 30 network drives on 8 servers where I have different profiles. I do not map the drives locally but add them as connections in ArcCatalog by simply typing in the fully qualified domain names (FQDN). Currently this is not possible in ArcGIS Pro 2.4.1. The work around is to modify the the Favorites.json which I have done but is far from convenient. It is important to map to the fully qualified domain names and not to a drive letter, it allows me to work seamlessly other GIS users in our organization.