Investigate conflation behavior between gdb and shapefile

[mikejeffe]

Investigate conflation behavior when input data ingested from gdb source vs. shapefile to see if there is a differences in the output. Data is from customer.

[mikejeffe]

Converted gdb source data (MAAX and roads_shp_113) to shapefile and compared conflation for the following test cases: 1) shapefile source MAAX vs. shapefile source roads_shp_113 2) gdb source MAAX vs. gdb source roads_shp_113 3) gdb source MAAX vs shapefile source roads_shp_113

In all three test cases I did not see any difference in the conflation and/or reviews. I did see however that importing the shapefile vs. gdb there were more tags in the shapefile (36) than in the equivalent gdb (30). Not sure what accounted for the extra fields but I noticed the shapefile included bridge:load_class1 , bridge:load_class2 , bridge:load_class3 , among other diffs.

[mikejeffe]

[mikejeffe]

@mattjdnv any ideas why we might see additional tags when importing .shp vs. gdb? I used the TDSv6 translation during ingest in both cases.

[mattjdnv]

Could you have another go importing the data but use the TDSv4 translator for both datasets.

• The MAAX data is TDSv4 (filename: MAAX_gdb_TDS4.gdb)
• The roads_shp_113.gdb is also TDSv4

Also, when comparing elements, you can use the TDSv61 view but be aware that it will translate the feature on the fly to TDSv61.

Attached are text files from importing both of the FGDB's via the command line with debugging turned on. This makes it easy to compare what attributes went in and what tags came out. in_maax.txt in_street.txt

[mattjdnv]

in_maax_shp.txt in_street_shp.txt

Attached are the import text files from MAAX & Street as shapefiles.

[mikejeffe]

The difference in the tag list is due to the fact that shapefiles don't support null values whereas gdb's do. This will lead to differences in tags b/w shapefile and gdb when ingested. Attributes with only null values in Hoot are dropped and but shapefiles will keep those tags with a value of 0.

[mikejeffe]

@mattjdnv It looks like when you ingest the input fgdb datasets using TDS4 translator, then try to export the merged output as anything (osm, shapefile, fgdb, etc.), the export fails. When you ingest the input fgdb datasets using TDS61 then export it works for all options. Something must be happening with the TDS4 translation that causes the conflated input datasets to try to pass invalid tags during export.

[mattjdnv]

Fixed.

The TDSv4 & TDSv61 translators now drop zero values for attributes that can't have zero as a value.

NOTE: Other fields that CAN have zero as a value (angle, elevation etc) can still cause translation problems.

[mattjdnv]

Finished and merged.

[mikejeffe]

thanks @mattjdnv