Data Structure and Data Loading Questions

[HaileyMonod]

Hello LGM Community,

I have some questions regarding the ???Facilities Streets??? feature dataset, and the ???Street Furniture??? FC. 

Historically we (I work for a small town municipal government) tracked many of those features that would be stored in the street furniture FC individually/ as separate FCs.

For instance, we have feature classes for large garbage bins, small garbage bins, recycling bins, benches, bike racks, picnic tables etc??? And within each of those FC???s we tracked additional and specific attribute information (which differs between FC???s). 

So how do we best incorporate all these old FC???s into one giant FC called Street Furniture,  and not lose all the other specific data that was tracked within each of them. Just add tons of additional columns I guess?!

Also, we were interested in making subtypes for some of the street furniture types. For example: a feature could be coded as a trash can but it could have a subtype to represent whether it is a large bin, small bin and what type of bin it is???
However, I think we can???t make subtypes on a string domain type it has to be a short integer or long integer domain type. So is it OK to change the domain type from text to short integer for the TYPE of street furniture to accommodate for subtypes??

One other thing, it appears that hydrants are tracked within the street furniture FC, but there is also a separate FC in the Water gdb for water hydrants (which seems to make more sense for grouping data).  So the types of items tracked within the street furniture feature class are optional, because at times they are tracked elsewhere as well?

Please let me know your thoughts or advice on 1. effectively combining old data and all their relevant attributes into the new feature class, 2. the potential future effects of changing the field type of a domain to create a subtype, and 3. the frequency of tracking features in two different places...


Thanks in advance!

Hailey

[Zeke]

I don't know the answer to all your questions, but you can add fields to the Local Government Model schema without harming anything. Deleting or changing the default fields may cause functionality problems if you use ESRI's maps and apps. That's probably a 'depends' situation.

[HaileyMonod]

Great, thanks for the tip 🙂
I am aware that you are can add fields. But I am wondering if I should add tons of new fields that correlate to each of the old feature classes (some of which will only be applicable to specific features) to ensure no information is lost when they are merged into one big street furniture FC. Or is there a better way to go about this?!

[AlanToms]

You may want to add separate tables for the item specific fields and use joins.  Look into how the Parks works with FacilitySitePoint feature class and the ParkRecInfo table.

Alan

[ScottOppmann]

Hailey -

If the attributes for each of these features varies widely, then moving to a subtype model would be probably the best way to go. As Alan mentions, the FacilitySite subtype model is probably one I would emulate.  Would it be possible for you to create a data dictionary (with Xray for ArcCatalog) or post an XML workspace document of the current street furniture features you have and attach it to this post?  I'd like to take a look at the attributes you have for each feature and see if we should consider amending our model to accommodate a more complex set of features.  We took a very simple approach initially and maybe we should consider evolving it in a subsequent release.

To your specific questions though; I don't think you need to reuse the TYPE field for the subtype designation.  I would probably add a field called FCODE and use that for the subtype.  Then you can reuse the TYPE field for the text domains that are specific to each feature type.

You could store some of the specific information in related tables (as Alan references below) but I might be a bit concerned the number of tables will grow as you add feature types.

If you don't mind sharing your current information model, I'd be glad to take a deeper look and provide more direction.

Scott

[HaileyMonod]

Hi Scott,

Thank you for your reply! I have emailed you our data structure, so perhaps you can provide us with further suggestions?!

Thanks again for all your help 🙂

Hailey

[PeterPalacios]

Hailey,
Did you receive any valuable advice from Scott you would not mind sharing with us? I'm in a similar situation trying to implement the LGIM for our organization and having refined exterior furnishing feature classes like you described.

-Peter

[HaileyMonod · Accepted solution]

Hi Peter,

Sorry for the delayed reply. I am sure you have figured out how to organize your data by now... but here is what came of my questions

After a brief investigation by Scott, we decided to seperate out many features into their own feature classes because there was specific attribute information that we wanted to track...

Scott did say:

"... street signs, signals and lights are not managed as street furniture because their structure and attributes are much different.  In this case, we have a single pole feature class that can have many related records (signs, lights, signals) stored in their associated tables.  This is a much more complex data structure than the furniture.

I???m a bit nervous about breaking down the furniture in to a subtype model because it would be really hard to find a unique set of domains for each of the features currently in the TYPE field.   I do think there are some things we could do to improve support for the data you have ??? ie. add attachments, add designation attribute, increate domains to support recycle bins, etc."

Hope that helps!
Thanks,

Hailey