Without post-compression With GZIP post-compression

Copyright © 2011 Open Geospatial Consortium 36 … 5.3.2 CC++ based

5.3.2.1 CWXML

CubeWerck’s binary XML is very like Fast Info Set, except it doesn’t offer a PER encoding allowing a bit stream as output. The output is byte aligned and then offers a good entry point for deflate. CWXML use its own linking with Zlib to invoke deflate. CWXML uses dictionary to store strings like elements name and has a special feature to guess what is a floating point number when it encounters one and convert it to IEEE 754.

5.3.2.1.1 Without post-compression

Without deflate post-compression, CWXML can only take advantage of element name repetition and IEEE 754 serialization of floats doubles. The configuration is in: exi-ttfmsconfigpropertycompactioncompaction-native.xml … driver name=CWXML neither param name=libraryPath value={japex.exi.ttfms.candidatesDir}ccwxml param name=libraryName value=cwxml param name=org.w3c.exi.ttf.applicationClass value=neither param name=description value=CWXML neither driver …

5.3.2.1.2 With GZIP post-compression

With deflate used as post-compression, the output is processed through a second pass trying to reduce redundancy. The configuration is in: exi-ttfmsconfigpropertycompactioncompaction-native.xml … driver name=CWXML document param name=libraryPath value={japex.exi.ttfms.candidatesDir}ccwxml param name=libraryName value=cwxml param name=org.w3c.exi.ttf.applicationClass value=document param name=description value=CWXML document driver Copyright © 2011 Open Geospatial Consortium 37 … 6 AIXM input files All the test cases, used for this benchmarking campaign use AIXM 5.1 input files, except some “technical files” which can be simple XML and are just here to compare algorithm when dealing with a specific aspect formatting, autoclosing tags… In order to get a relevant sample set of AIXM data, we processed data from various sources mostly Snowflake, Comsoft, Luciad WFS servers, but also D-NOTAMs from Eurocontrol to identify characteristics from AIXM feature by feature

6.1 Families of files

As we collected too much data almost 1 GB, we extracted only portions of full databases and put these parts into files, then gathered those files into families. The files described below could have been the result from various WFS request, mostly based on BBOX. In fact we worked offline using full exports of features and sorted them using tools scripts detailed in 6.2.1 Four families of AIXM files were identified and populated: A first family composed of small files 10kB: tree D-NOTAMs from Eurocontrol. A second family composed of medium sized files between 10kB and 1MB, each of it made from a single AIXM feature, bringing its own characteristics for instance airspaces, geo borders, runways and taxiways elements contains much more coordinates than others features. Routes have simple structure only 28 different elements taking 65 of the file compared to airspaces 60 different elements taking 30 of the file A third family made of bigger files 1MB, alternating both mixed features as the whole Estonian database or the sum of all features from family 2 or single features to see how the performance of compression algorithms evolve along with volume A fourth family made of technical files, useful to check a specific aspect against all algorithms influence of order, handling of autoclosing tags, drops of comments, formatting …. Original AIXM files readable are stored into exittfmsdata. Normalization script works from this path when displaying file names.