XML, KML and ENVI 5.1

At the moment I am beta testing ENVI 5.1 and have been working with the new Region of Interest (ROI) tool. The new tool looks good with some interesting features and one or two radical changes. One of these is the use of XML to store the Region Of Interest (ROI, see example at the bottom of this Post). Previously ENVI stored ROI data in a dedicated format that couldn’t be read by a text reader. In switching to XML Exelisvis, the makers of ENVI, are taking a giant step towards open standards. This is not a trivial shift. The SARScape synthetic aperture radar (SAR) Add-on package makes use of a SML files (an XML variant) allowing the user to review and edit [meta]data. I find this particularly useful because it allows me to process data outside of ENVI/SARScape and then ‘spoof’ an SML file with the image geometry to then geocode my product. This means I can use some of the excellent features of the Radar Tools (RAT) freeware and then geocode them using the rigorous routine implemented in SARScape.

Assuming the ROI currently in beta testing is launched with ENVI 5.1 later this year, this means users will have easy access to the data describing ROIs. Vertices can be easily edited, new polygons added from GPS or other positioning data, names manually changed etc. Your data will be liberated from the tyranny of proprietary formats (okay, I may be getting a little carried away here). Of course Exelisvis and Sarmap (makers of SARScape) aren’t the first to do this. Shapefiles have been an open standard, the Geographic Markup Language (GML) preceded it’s better known Google cousin, Keyhole Markup Language (KML), all of which can be easily read and edited. That said, it has been suggested to me that Google is not likely to develop Google Earth further and is disappointed that KML hasn’t been more widely adopted. Still many programs, including ENVI and SARScape enable the user to export data to Google Earth using KML and Google helped promote markup languages in the wider community.

Regardless, I look forward to seeing more open standards in ENVI. It may be pressure from open source alternatives, a desire to simplify standards or acknowledgement that such standards improve the user experience that is driving this change; we’ll probably never know. It is worth noting Exelisvis is now referring to ENVI as a ‘platform’ and clearly plan to offer an increasing range of add-ons and further integration with programs such as ArcGIS: standards such as XML make this easier for programmers, developers and not least, customers or users.

An example of an XML ROI file:

<?xml version="1.0" encoding="UTF-8"?>
<RegionsOfInterest version="1.0">
<Region name="Region #1" color="255,0,0">
</Region>
<Region name="AVICENNIA (Land_cover_classes)" color="255,0,0">
<GeometryDef>
<CoordSysStr>PROJCS["WGS_1984_UTM_Zone_37S",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",10000000.0],PARAMETER["Central_Meridian",39.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]</CoordSysStr>
<Polygon>
<Exterior>
<LinearRing>
<Coordinates>
532414.408 9138010.905 532664.408 9138010.905 532664.408 9137985.905 532689.408 9137985.905....
0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments