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

File Geodatabase help?

GeospatialTechnology

Hello,

I've been processing some data in a file geodatabase.

I'm finding the geodatabase to be getting very full of data and increasingly hard to navigate.

I was wondering if there was a way of creating sub folders or sub directories in the geodatabase?

Or would I just be better creating lots of seperate geodatabases depending on the area I'm studying?

Find more posts tagged with

Accepted answers

All comments

KarlWilson

Please let give me more information about the unintended consequences of using feature datasets for something they are not designed for and what you think they are designed for. My apologies I am not trying to be p*ssy I am just flummoxed.

A couple of links on the subject:
http://forums.arcgis.com/threads/43077-How-to-organize-data-in-SDE-%28feature-datasets-or-not%29
http://esriaustraliatechblog.wordpress.com/2011/10/06/can-you-use-feature-datasets-as-logical-folders-to-store-feature-classes/
http://gis.stackexchange.com/questions/11537/is-there-a-performance-hit-from-using-a-feature-dataset

The main reason for me is the feature dataset "locking" issue.

JoeBorgione

See #7 of http://forums.arcgis.com/threads/83978-How-to-join-Lines-with-Polygon

I've had problems with feature datasets before in geodatabases. That's all I gotta say.

And yeah, I think an individual database for landuse and electrical and hydro, and roads is the correct way to go. My practices have worked for me. Apparently there are others who share my view. If they don't work for you, that's okay by me.

RobertBorchert

Are Joe and Vince actually serious about saying feature datasets are a bad idea.

Feature datasets do have a specific purpose. They allow you to categorize your data for a GIS and organize it in a database.

It would be foolish for a user to have their landbase in one database, their electric or sewer or forest or mine sites etc.. dataset in another database etc..

Please let give me more information about the unintended consequences of using feature datasets for something they are not designed for and what you think they are designed for. My apologies I am not trying to be p*ssy I am just flummoxed.

Gotta go along with Vince on this. I'd much rather manage multiple databases then get bogged down in the unintended consequenses of using feature datasets for something they are not designed for.

GeospatialTechnology

Okay thanks to you both i'll go down the multiple database route!

JoeBorgione

Gotta go along with Vince on this. I'd much rather manage multiple databases then get bogged down in the unintended consequenses of using feature datasets for something they are not designed for.

VinceAngelo

Those appear to be subfolders, but they're not. They're feature datasets, which have
a very specific purpose. Using them as folders introduces a number of limitations and
unintended consequences, and is therefore not recommended. The impact is less
severe in FGDB than in ArcSDE, but it can introduce a bad habit that will be difficult
to break. Creating different FGDBs for different study areas is IMHO a much better
practice.

- V

GeospatialTechnology

Thanks rborchert! So you can create sub folders. It's funny because vangelo really sounded like he knew what he was talking about. It just goes to show you shoudn't believe everything you read on here.

Thanks also to mvolz47. That is also a good idea.

Cheers

RobertBorchert

yes a good method is to create subfolders in your file geodatabase.

In the FGD they are called Feature Dataset

Right click on your FGD and select New > Feature Dataset

Now the Feature Dataset will prompt you for a projection to use.

So you can create individual Feature Datasets and load Feature classes into it.

Example. I word in Electric Utilities. I have Feature Dataset for

Electric (all features I want in a geometric network)
Landbase
Electric2 (all electric related features I don't want in the geometric network)
MapData (datadriven pages polygons, and other features used for map production)

Anyway that should give you the idea.

However, when you do this you will have to repath all your MXD's to the new feature locations.

Hello,

I've been processing some data in a file geodatabase.

I'm finding the geodatabase to be getting very full of data and increasingly hard to navigate.

I was wondering if there was a way of creating sub folders or sub directories in the geodatabase?

Or would I just be better creating lots of seperate geodatabases depending on the area I'm studying?

MikeVolz

You might consider naming your data with schema type names (schemas are supported in RDBMSes). You could have pseudo schemas such as TRANSPORTATION where you have names such as TRANSPORTATION_AIRPORT or TRANSPORTATION_RDCL or HYDROGRAPHY where you have names such as HYDROGRAPHY_HYDRO_LINE or HYDROGRAPHY_HYDRO_LINE. I think you would be able to navigate easier with this setup and it coud prepare you for an Enterprise environment where you could import these feature classes (with their schema names) into a RDBMS. I hope this helps.

GeospatialTechnology

No not full of data. There's just a lot of files in there and it's a bit of a pain to navigate.

Don't worry it's just my obsessive compulsive disorder kicking in! 😉

I think I'll make a geodatabase for each area I'm conducting my study in.

Thanks for the help

VinceAngelo

No, there is no way to create subfolders in file geodatabase -- It's modeled on
RDBMSes, which don't support that concept either.

I've never experienced a FGDB getting "full of data" -- Do you mean tens of
thousands of tables or one table with tens of millions of rows?

- V

Join the Conversation

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

Quick Links

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