ThinkGeo.com    |     Documentation    |     Premium Support

Is the release version of Geocoder 3.1 incompatible with 3 Beta data?

#1

I downloaded the release version of Geocoder 3.1.299.77 and have updated my application for the changes in the API. I am receiving an error when trying to Geocode and was wondering if the data I already have is no longer compatible. The exception I have is file does not exist when I attempt to open the Geocoder object. Please see the attached stack trace. The path I am passing to the Geocoder is: C:\ThinkGeo\GeocodeData\Map Suite 3.0 Geocoder Index. 


Can you please point me in the right direction to correct this? Thank you.



1711-Geocoder_Stack_Trace.txt (760 Bytes)

#2

David, 
  
 It seems the problem is from your index data, according to the attached file, maybe there is a localtion error for the rt2.dbf file in your local machine, please see the following exception message in the attached file: 
  
 C:\ThinkGeo\GeocodeData\Map Suite 3.0 Geocoder Index\streets.dbf\rt2.dbf 
 Parameter name: The file specified does not exist 
  
 Obviously, the file path of rt2.dbf file is incorrect, please review it, 
  
 Thanks, 
  
 Scott,

#3

David, 
  
 Also, if you are not sure where is the problem, can you attach your sample code to us so that we can help you on this problem exactly? 
  
 Thanks, 
  
 Scott,

#4

Scott,


Thank you for your help. The path is definitely wrong, but I do not see where I am setting it that would be incorrect. Please review the attached sample that exhibits the exception. I am also attaching a text file of the directory and contained files. The index files are from the Geocoder 3.0 Beta that I received about a week and a half ago. 


My system is Windows 7 Professional English 32bit, running as administrator with UAC turned down. This exact same path worked fine in 3.0 Beta.


Thanks,


David



1721-Geocoder3.1Test.zip (25.7 KB)
1722-files.txt (1.3 KB)

#5

David, 



Thanks for your code, I reproduced your problem on my local machine, this is a bug in the new version, we ignored the constructor problem of StreetMatchingPlugin, usually, when we used the UsaGeocoder object, we just need to open it and match, so we didn't need to add StreetMatchingPlugin myself, but this is a definitely bug, I have fixed it, please keep your eyes on the site to get the update version.


Also, currently, there is a workaround way for your problem, please see the changed code below:



UsaGeocoder InstanceGeocoder = new UsaGeocoder(GeocoderPath, MatchMode.ExactMatch);
            InstanceGeocoder.MatchingPlugIns.Clear();
            InstanceGeocoder.MatchingPlugIns.Add(new StreetMatchingPlugin(GeocoderPath, MatchMode.Default));
Collection<GeocoderMatch> matches = new Collection<GeocoderMatch>();
try
{
InstanceGeocoder.Open();
Collection<GeocoderMatch> temp = InstanceGeocoder.Match("21910 Suburban", "46516");
}
catch (Exception ex)
{
// catch errors
Console.WriteLine(ex.ToString());
throw;
}
finally
{
InstanceGeocoder.Close();
}

You just need to use another constructor of StreetMatchingPlugin,  your problem can be resolved correctly.



Thanks, 



Scott,



#6

Scott, 
  
 Thank you, but I now receive a NullReferenceException error. It occurs inside the Try/Catch but does not make it to the Catch section. It fails when executing the InstanceGeocoder.Match line. 
  
 Exception detail: 
 System.NullReferenceException was unhandled 
   Message="Object reference not set to an instance of an object." 
   Source="MapSuiteGeocoder" 
   StackTrace: 
        at ThinkGeo.MapSuite.MapSuiteGeocoder.CustomFieldIndexFile.Close() 
        at ThinkGeo.MapSuite.MapSuiteGeocoder.StreetMatchingPlugin.Dispose(Boolean disposing) 
        at ThinkGeo.MapSuite.MapSuiteGeocoder.StreetMatchingPlugin.Finalize() 
   InnerException:  
  
 Is there something I am missing? The reason I am even using the Clear and Add method is because the default geocoder is looking for census files that we do not have yet from the new update.  
  
 Thanks, 
 David

#7

David, 
  
 It seems you mssed some files when executing the Match operation, please see the exception information below: 
  
 at ThinkGeo.MapSuite.MapSuiteGeocoder.CustomFieldIndexFile.Close()  
 at ThinkGeo.MapSuite.MapSuiteGeocoder.StreetMatchingPlugin.Dispose(Boolean disposing)  
 at ThinkGeo.MapSuite.MapSuiteGeocoder.StreetMatchingPlugin.Finalize()  
  
 The CustomFIeldIndexFile is a null reference, in fact, when you execute the StreetMatchingPlugin we need these files: 
  
 streets.dbf, rt2.dbf, rt2.idx, streetname.idx, zip.dbf. 
  
 The streetname.idx is the CustomFieldIndexFile object, can you make sure the streetname.idx is existed in your index data folder. I tried to reproduce the exception used your sample, but I can’t reproduce it. So I guessed you missed some index files in your index data folder. 
  
 Thanks, 
  
 Scott,

#8

Scott,



In my Geocoder index folder I have:

Citystate.dbf

county.dbf

numberlist.txt

rt2.dbf

rt2.ids

rt2.idx

SoundexStreet.txt

State.dbf

streetdirection.txt

streetname.ids

streetname.idx

streets.dbf

StreetSoundEx.dbf

streettypeabbr.txt

streettypefull.txt

tlid.dbf

zip.dbf

zipBBX.txt


Is there a way I am supposed to set the CustomFieldIndexFile? I did not see one.


Thanks,


David



#9

David, 
  
 I added a message box after executing the InstanceGeocoder.Close() operation, I re-create this problem as you said, I found the streetname.idx file was closed in an incorrect place, I have fixed this bug in the core code, please contact to ThinkGeo Support to get the newest version. 
  
 Thanks for your post, 
  
 Scott,

#10

David, 
  
 The CustomFieldIndexFile is a internal class, we don’t public it in this MapSuiteGeocoder version,  I need to explain to you about i, please see the following index files: 
  
 Citystate.dbf 
 county.dbf 
 numberlist.txt 
 rt2.dbf 
 rt2.ids 
 rt2.idx 
 SoundexStreet.txt 
 State.dbf 
 streetdirection.txt 
 streetname.ids 
 streetname.idx 
 streets.dbf 
 StreetSoundEx.dbf 
 streettypeabbr.txt 
 streettypefull.txt 
 tlid.dbf 
 zip.dbf 
 zipBBX.txt 
  
 You can see there are two kinds of idx, ids files, they are rt2.idx, rt2.idx and streetname.idx, streetname.ids, but they are different, the rt2.idx, rt2.ids are the RtreeIndex object, the streetname.idx and streetname.ids are the binary file object, we just gave them the same extension name, but essentially, they are the different objects. 
  
 The rt2.idx file stores the spatial query information, the streetname.idx just stores the street name information, it is used for increasing the search performance.  
  
 If you want to build your own streetname.idx, I think you can write the logci easily, even you can use the another extension name. In our MapSuiteGeocoder, just the rt2.idx is the rtree index file. 
  
 In addition, the index file for IN state is processing, I will give you the response on it if there are any problems, 
  
 If you have any other questions please let me know, 
  
 Thanks, 
  
 Scott,