Did navteq changed their "LINK_ID" field format??

[AsafBen-Ari]

Hi,

I am using the "Street Data Processing Tool" in order to create a network dataset, and for some reason it does not recognize the inputs data.

After some checks I did, I discovered that in the last 2 versions (2014Q4 and 2015Q1), the format of the LINK_ID field (in all the FC), was changed from "double" into "long integer"..

Changing the fields format in the ArcGIS is of course only a wishful task, so can it be that the only work around is creating a new FC (with the old format, and loading the new features?

Thanks,

Asaf.

[AsafBen-Ari · Accepted solution]

Hi,

After some correspondence I had with the Network Analyst Team in Esri, I got the following answer:

"The HERE data has not changed the format of the fields for their NAVSTREETS shapefile data.  HERE still publishes their LINK_ID fields as N(10) (Numeric size 10) dBASE format. Note that HERE natively manages the LINK_ID field as a 32-bit integer.

What has changed is that, between ArcGIS 10.2.x and 10.3, the way that a dBASE data type of N(10) is interpreted has changed – in ArcGIS 10.2.x, the N(10) dBASE format is assumed to be of type Double, but in ArcGIS 10.3, the N(10) dBASE format is now assumed to be of type Long Integer.  There is a similar change with the interpretation of the N(5) dBASE format – in ArcGIS 10.2.x, the N(5) dBASE format is assumed to be of type Long Integer, but in ArcGIS 10.3, the N(5) dBASE format is now assumed to be of type Short Integer."

They believe that in the near future an update to the tool will overcome the issue.

(Many thanks to Alan, who helped me with that)

Asaf.

[ThibaultThibault]

I had the same problem. The solution was to input the shapefiles instead of the feature classes from a file Geodatabase.

http://www.arcgis.com/home/item.html?id=755f96fcde454ece8f790fecb3e031c7#!

How the tool works?

The tools process shapefile data from TomTom MultiNet or NAVTEQ NAVSTREETS into a file geodatabase network dataset.