|
The few I looked at were definitely by index. To prove this:
1) Pick a POI by name
2) Figure out its index into the array (this is easier if you pick one towards the end of the list).
3) Search for that index value in the data
4) Read off the lat and long and look it up on Mapquest (or your PDA).
As for the memory issue, suppose you had 10,000 POIs at an average length of 20 characters apiece. That's only 200k of memory. But, perhaps this explains why NAVTECH doesn't have a database of millions of POIs like all of the other guys.
One thing that is troubling me: Towards the end of the list of strings it has a list of all of the names of the cities. These don't appear to work like the POIs. (I couldn't find any entries between FF FF FF FF's to match their index numbers). I tried figuring out if its its own array, but gave up after a little while. Maybe if someone else posts something promising, I'll take another look.
However, one more contribution before I go: Between the index in the strings array and the end of a POI entry, there appears to be several collections of bytes that may be dates. I say this because I looked at a few POIs that were close together, and they all had some data which, when converted to a time_t, were all very close (within a few minutes) and recent (2003-2004). I'm guessing that this might be the date that the data was collected. But, this may knock out the mystery of another dozen or so hex characters.
- Jes
|