C/JMTK = Commercial Joint Mapping Toolkit = http://www.cjmtk.com/ SDSFIE = Spatial Data Standard for Facilities, Infrastructure & Environment = http://www.sdsfie.org

I've been working on a project using the C/JMTK, so I'm pretty familiar with it. It is basically a repacked version of ESRI's ArcGIS and ArcObjects technologies. Recently I was asked if our databases meet the SDSFIE standard, or could we work with SDSFIE-standard databases.

My question is what is the relationship between SDSFIE and C/JMTK? It seems to me after some preliminary reading that SDSFIE is a description of how the database schema is developed. Is that correct? Is it just schema or are there other requirements that restrict the underlying technology choices (e.g. geodatabase format or sql database vendor).

Can the C/JMTK (e.g. ESRI ArcGIS & ArcObjects technologies) support the SDSFIE standard?


P.S. Tried to tag this with C/JMTK and SDSFIE but I don't have enough reputation points.

2 Answers 2


As the programmatic lead for the SDSFIE standard, I recommend that you go to sdsfie.org and learn more about the standard. You can directly ingest the ESRI GDB version of SDSFIE 3.0 into CJMTK. By the way, SDSFIE is also a DoD mandate (for use on installations & environment missions as well as Civil Works) and it is registered in the DISR. We are collaborating heavily with NGA to harmonize this standard with other GEOINT standards like the NFDD/NAS.

I have a couple of quibbles with the first answer:

  1. SDSFIE has always been first and foremost a spatial data standard developed for DoD use, specifically pertaining to installations (utilities, environmental data, facility/infrastructure, etc.) and the Corps of Engineers civil works function. Other organizations have always been welcome at the table, and thier input was pretty significant during the SDSFIE 2.x phase of the standard. SDSFIE 3.0, however, is now uniquely tailored to DOD requirements. As such we still welcome broad community participation but you shouldn't expect too much "non-DoD content" in SDSFIE for the near future.

  2. SDSFIE 3.x is a logical data model (more exactly, its a logicial platform independent model). If you become a registered user on sdsfie.org, you can download an ESRI geodatabase "version" of the SDSFIE 3.0 logical model. In the transformation from logical to physical (ESRI geodatabase), the ESRI-specific format characteristics are imparted to the schema. It is incorrec to say the SDSFIE 3.0 Gold data model has any vendor-specific characteristics. It does not, but if you grab the geodatabase export of the data model it will appear to be "ESRI specific."

  3. We can also export SDSFIE 3.0 as GML, which in turn can be ingested into AutoDesk Map or Bentley or Oracle Spatial, etc.


On the surface, it seems like there should be some connection between the C/JMTK and SDSFIE.

Both of these were developed to help with either Department of Defense, or other national security initiatives. In the case of C/JMTK, the primary government agency is the NSA.

SDSFIE was developed to provide a common data model/schema for all government agencies. It started with a focus on the Navy and Marine Corps, but other agencies have definitely been involved. The latest version, 3.0, was designed from the ground up as a means of finally integrating all of the offshoots that were created by the different agencies.

SDSFIE is very comprehensive, covering data types from utilities, to environmental, to now include Levees and a Real Property Inventory. In many cases, the changes between versions were not a reduction in information being stored, but instead how it was stored.

Example: Version 2.6

Version 3.0
Wastewater_mainline - Subtype: Gravity; Forcemain

The reason I bring this up is to show that Subtypes are being used. This is a relatively ESRI specific nomenclature, and leads to my next point: While the SDSFIE data model is designed in a way that I think could be used in different database structures, it was developed using ESRI data objects and terminology. Some specific objects that are utilized are Relationship Classes, and Network Classes.

Since the C/JMTK was developed on a DoD mandate, I would imagine at some point that it is going to be set up to use data in the SDSFIE schema. It would be worth checking now, as you might be surprised to find that it already does.

If not, then there definitely won't be a software/data conflict, as they are all based on ESRI products.

The challenge that I could see you encountering in starting to use SDSFIE with your current work, would be the amount of customization and automated processes that exist in the C/JMTK software. If there are many automated processes, like assigning particular attributes when a new feature is added, or geoprocessing models that are dependent on specific fields, these would have to be modified to match the attribute fields of the SDSFIE schema.

I will say that if you have the opportunity, to try out the SDSFIE schema. From the time that I was using it, which was with the 3.0 version at the end of the development cycle, it was very comprehensive, as I said previously. If there was a feature that you needed to enter, there was likely a layer already set up, with relevant attributes and domains already defined. As well, relationships were defined between feature classes, thus allowing you to add a logical link between features, such as between an electrical sub-station and the switches that were contained within.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.