Skip to content

Latest commit

 

History

History
36 lines (26 loc) · 1.41 KB

7-results.adoc

File metadata and controls

36 lines (26 loc) · 1.41 KB

IE Experiment Results

Results Related to CDB Data Store (Experiment 1)

Results from Experiment 2

Compusult metrics from Experiment 2

Approach: One GeoPackage per LOD per dataset

CDB: CDBYemen_4.0.0

Available Datasets:

  • 101_GTFeature

  • 100_GSFeature

  • 401_Navigation

  • 201_RoadNetwork

Number of ShapeFiles processed: 358 Number of GeoPackages created: 18 Total byte size of ShapeFiles (bytes): 3,569,324 Total byte size of GeoPackages (bytes): 41,715,712 Elapsed time (seconds): 173

Results from Experiment 3

Results from Experiment 4

Guidance

A couple of performance comments (so far):

  1. Structure of the data matters. Timing differences in SQL queries on integers rather than strings is enough to matter.

  2. As mentioned by others, opening a GeoPackage with lots of tables is slower than having a single table (option 3). .Doing a query to get features out of a very large table is MUCH slower (option 4). I am getting 40x slowdowns for heavily forested areas where I am querying 4700 points out of a table with >2.8M points.

  3. The more columns a table has, the larger the slowdown (ie, a query in option 4 vs a query in option3 might take twice as long with 8 columns, but 4 times as long with 30 columns)

    1. Depending on how much time we have left, testing option 1b might be worthwhile. It should yield faster queries to not flatten class-level attributes into the feature table.