Can I just make a new Feature Sub Type ?

[MartinHvidberg]

Dear all

We feel a need to save data in the NIS, for which there are no Feature Sub Type (FST) in the standard schema.

Example (EEZ):
The EEZ is a Polygon in the NIS. But we build the polygon from a Line, that is defined in our national legislation. To make sure we preserve the original data we would like to save also the EEZ Line feature in the NIS.
Esri have placed the EEZ polygon in:
"RegulatedAreasAndLimitsA (50) 'EXEZNE' Exclusive Economic Zone"
Obviously a line can not be saved in a polygon feature layer, and the other obvious option:
RegulatedAreasAndLimitsL have no FST for EEZ

Question:

Can I just invent a FSC and decide that I want to use e.g. no. 500 for it:
"RegulatedAreasAndLimitsL (500) 'EXEZNE' Exclusive Economic Zone"

If this is the way forward, could we (the Esri community) agree to always use e.g. 500-600 for 'local use', so I don't risk future conflicts?

Or, should I rather use UserDefinedFeaturesL and e.g. invent
"UserDefinedFeaturesL (2) 'EXEZNE' Exclusive Economic Zone"

Any body have any experience here? Are there any 'best practise' to be pointed out?

Best regards
Martin

[AndyOmmen]

Martin,

Although there is nothing within the Nautical solution preventing you from adding a new subtype to any of the feature classes, I think the best approach is to populate the UserDefinedFeaturesL feature class with the desired EXEZNE linear geometry. This approach will allow you to utilize the pre-configured NIS field configurations for the UserDefinedFeaturesL feature class. Also, the NIS and product geodatabase schema's will reamin in sync with one another.

Features added to the UserDefinedFeatures feature classes will be synced down to your product geodatabase and ultimately exported to S-57. If this is not the desired result then be sure to delete the linear features after you have constructed the EXEZNE polygon feature from them.

Hope this helps

Andy

[GeoffreyGomez]

Martin,

There are a couple of things at play here that should be considered and may help you determine the best path forward.

Reserved Subtype values:

• Your suggestion to set aside some number range to avoid any potential conflicts (reuse of a subtype value by COTS) down the road is a really good thought. I don�??t wish to dictate what that range should be, but seems like the 500-600 range you suggested provides ample spacing to avoid reuse. I am not sure how to formalize this convention, but it would help if both the solution team and other users were aware of this going forward. Perhaps we can look for a place to present this within help or the online blog.

Determining where to add the new subtype:

• What is the new subtype depicting and is there a natural place for it within the COTS data model? I agree with your initial mapping of the new subtype to the RegulatedAreasAndLimitsL feature class since the area EXEZNE features are stored in the RegulatedAreasAndLimitsA feature class and all the attributes are present. This brings us to the next question.


• What attributes do you wish to encode for your new subtype? Here is where your goals for this new subtype dictate the decision. If you wish to encode all the attributes needed to generate the EXEZNE area features within the new linear subtype then you have two options:




1. Add the new subtype to the RegulatedAreasAndLimitsL feature class. You will need to configure field configurations for just the new subtype since the feature class already has all the attribute fields needed for EXEZNE features.


2. Add the new subtype and all the required attributes to the UserDefinedFeaturesL feature class. In addition you will need to set field configurations for both the new subtype and any existing subtypes(to mask the new fields).


• Wherever you decide to store the new subtype you may wish to indicate that the features within this subtype are to exist only in the NIS. You can do so by setting the NIS_PRODUCTS value to 999 (none). This will keep the features from being sent down to the product databases based on arguments in the default extraction filter. I imagine this would be the desired approach with the example you provided EXEZNE (line) features.

General best practice considerations:

• Stick to COTS data models if at all possible


• When extensions to the data models must be made, consider these types of requirements prior to beginning �??live�?� production. This will remove most of the complexity of rolling out changes.


• Changes made prior to products existing will require the extended data model schema to be added to the product library as a new DMV (Data Model Version). This will ensure that new products have the latest schema changes and any replica that is registered will include the new subtype.


• Should products already exist when changes are made to the NIS schema you will need to carryout the above process as well as propagate the schema change across the replicas. For more information see the link here.


• I mentioned this above but wanted to reinforce it. When extending the data model for the NIS and products, field configuration settings must be updated. This will ensure the new linear EXEZNE subtype shows only the relevant attribution within feature manager. The extent of the update depends on where the subtype is added. (This is something we had to alter when you added your own user defined fields)


• Last but not least, the product XML ultimately controls what can be imported and exported from/to S-57. You have some flexibility on where you wish to add this new subtype, that said, you should leave the product xml's unchanged to ensure that regardless of where the features exist (NIS and/or product) you will still be exporting compliant S-57 data.

Hope this helps, it is by no means a comprehensive list of instructions more of a conversation about what to consider. If you need to have a more in-depth discussion I would be glad to pull together some people to do so.

Cheers!
Geoff