Previous posts have touched the problems that traditionally face those wanting some geospatial consistency in data collection, data presentation, and data understanding. These issues drive much of the continual interest and push for increased Metadata and many of the “Use Liability” clauses that are attached to current datasets. After all, if you don’t really know what the feature is, or what many of the attributes really mean, geospatial data is of considerably reduced value.
Background: While many organizations see the clear advantages of establishing and using geospatial data standards, obtaining compliance from constituents continues to be a frustrating, and costly, problem. Users are frequently reluctant to adopt a new standard given the potential cost of modifying applications that use an existing, custom schema or simply having a ‘not invented here’ mentality. This was true within the Department of Defense (DoD) Installation Geospatial Information and Services (IGI&S) community, even though a standard had existed from more than 10 years. As a part of 2006 Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) initiative, Zekiah developed a data standardization concept intended to provide flexibility in schema naming conventions and organization without compromising ease of data sharing, conversion, and information understanding.
On my current project I was tasked with exporting our map layers to Google Earth. This was simple for the ESRI ArcGIS Server layers, since Server has out-of-the-box support for KML. However, as would be the case, we don’t use ArcGIS Server for all of our layers. We also use ESRI Graphic Layers for rendering user markup and data from various data sources. This presented a challenge to export these layers to Google Earth. Specifically, we wanted to maintain the same rendering and symbology that we used on our Silverlight maps in Google Earth.
Read More »
Update 9/15/18 – Arc2Earth no longer offers subscriptions or services.
Zekiah supports many organizations, especially in the federal government, that have a need to run ArcGIS Server on networks that are not connected to the internet. Oftentimes, these organizations use tiled basemaps that are built from data or services that are available (whether free or by subscription) from the internet. While ArcGIS Server can produce these tile caches, organizations with production servers on disconnected networks can find it impractical to do so. Although the cost of running two ArcGIS Servers is sometimes a factor, we find more often that IT and information security policies make it difficult for these organizations to stand up servers on internet-connected networks. In such situations, a desktop solution is preferable.
One of the more critical, and somewhat confusing, concepts in the SDSFIE 3.0 is the notion of what constitutes a ‘compliant’ data set. SDSFIE 3.0 offers considerably more flexibility in schema options than earlier releases. This capability was created to permit individual DoD users some naming options to accommodate existing legacy applications that use geospatial data. But the capability comes with a risk… namely compromising the very nature of a standard.
Many new DoD contracts are being awarded with a clause stating that the data deliverables are to be submitted compliant with SDSFIE. Given the flexibility in schema naming and content, what does that really mean and how is that consistent with an absolute standard.
The Spatial Data Standards for Facilities, Infrastructure and Environment (SDSFIE) is the single Department of Defense spatial data standard that supports common implementation and interoperability for installations, environment, and civil works missions.
SDSFIE is being managed by the Defense Installations Spatial Data Infrastructure (DISDI) Group. The DISDI Group is a formal governance group reporting to the Department of Defense’s Installations & Environment Investment Review Board.
Note: The project described in this post also makes use of ArcGIS Server. If you intend to use the Esri ArcGIS API for Silverlight/WPF without ArcGIS Server, you should review the license agreement.
If you have spent much time with the Esri ArcGIS API for Silverlight, you know it provides a lot of capabilities and offers a flexible API for adding data to a map. Esri has provided some simple out of the box solutions for putting data on a map, such as ArcGISDynamicLayer and GraphicsLayer. These are simple to use and provide an easy way to visualize data on a map. However these may not always meet your needs, and you may need to extend the Esri Silverlight API.
Read More »
We specialize in software development, systems engineering, and geospatial technologies and serve clients in the D.C., Maryland, and Virginia area.