|
 |
10-05-2005, 12:30 PM
|
#1
|
|
FLAC
Join Date: Jun 2005
Location: Anoka County, MN
Posts: 1,020
|
Editing/reading iguidance POI bin files
Before I go try to tackle this myself, has anyone else had any success in mapping out how the poi.bin file is layed out?
|
|
|
|
|
|
Advertisement
|
Sponsored links
|
10-05-2005, 12:37 PM
|
#2
|
|
MySQL Error
Join Date: Sep 2004
Location: Woodbridge, VA
Posts: 5,012
|
hasnt happened. But DAMN do i hope you get the job done!
|
|
|
10-05-2005, 12:49 PM
|
#3
|
|
Maximum Bitrate
Join Date: Nov 2004
Location: Coon Rapids, MN
Posts: 597
|
i'm also cheering you on..
p.s. we gotta hang out sometime
|
|
|
10-05-2005, 02:05 PM
|
#4
|
|
FLAC
Join Date: Jun 2005
Location: Anoka County, MN
Posts: 1,020
|
Ow, this hurts to think about.
So far, I have determined that the first two values after (most) FF FF FF FF characters corospond to 32 bit floating point values that refer to GPS coordinates:
For example thats a POI database entry for a state park. But I don't know how it indicates where in the POI name string array what name corosponds to what GPS coordinates.
All I need is a way to determine name, category, and coordinates and I can rewrite the POI Interface for IG. But it looks much to complciated to put in our own custom entries yet.
|
|
|
10-05-2005, 03:04 PM
|
#5
|
|
MySQL Error
Join Date: Sep 2004
Location: Woodbridge, VA
Posts: 5,012
|
That might be farther than anyone else has been able to get! Lets keep this thread alive people!
BTW, i dont supposed anyones ever asked inav for a poi editor? lol
|
|
|
10-06-2005, 11:29 PM
|
#6
|
|
Maximum Bitrate
Join Date: Nov 2004
Location: Coon Rapids, MN
Posts: 597
|
it would be great to get an editor going, I for one would ahve problems taking some saturdays and going war-driving/ PIO driving, and updating the maps in the minneapolis area.. Lord knows in these 'burbs things grow like weeds.
purdoom what software are you using to dig this info up?
|
|
|
10-06-2005, 11:38 PM
|
#7
|
|
FLAC
Join Date: Jun 2005
Location: Anoka County, MN
Posts: 1,020
|
I use http://www.chmaas.handshake.de/delph...vi32/xvi32.htm for most of my hex editing. After looking at the file more I plan on making my own reader that breaks the data segments into better easy to see categories so I can compare records to eachother.
Also, useless wardriving idea: If in the future we wanted to dynamically input POI entries I have a good idea involving starting a new copy of ig in the background with the new POI entries then switching the new IG with the POIs on the map with the one thats running. We do that every few moments or when we add new POI entries (hotspots).
Man if only I knew how to intercept the funtion calls in this program, I could do so much...
|
|
|
05-07-2006, 07:07 PM
|
#8
|
|
Newbie
Join Date: May 2006
Posts: 2
|
I spent a few minutes looking at this file, too, and thought that I'd post what I found:
* It looks like all the POI names are loaded into an array of ASCII strings, and then an index is used to look them up. Hex position 36 in the file is the number of strings in the array. I took a sample location entry (everything between FF FF FF FF's) and got this:
First 32 bytes are latitude and longitude:
66 35 20 42 Float Latitude
94 34 D2 C2 Float Longitude
Next however many, I have no idea:
FF 7F 9E 16 00 00 06 86 10 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 00
Then there are these two repeating sections:
93 3F 05 00
93 3F 05 00
93 3F 05 00
93 3F 05 00
and
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
Then this:
04 79 00 1C BC C4 01 00 EB
Then the index into the name array:
2D 12 Unsigned Short Index into strings array
And the remainder:
00 3F 06 00 40 AB 21 20 42 E2 21 D2 C2 02 00 41 0D 00 00 19 87 69 01 00 00 00 00 00 CB 6D 01 00
Hopefully someone else has some good ideas!
- Jes
|
|
|
05-07-2006, 11:18 PM
|
#9
|
|
FLAC
Join Date: Jun 2005
Location: Anoka County, MN
Posts: 1,020
|
Quote: Originally Posted by lefcourt
I spent a few minutes looking at this file, too, and thought that I'd post what I found:
* It looks like all the POI names are loaded into an array of ASCII strings, and then an index is used to look them up. Hex position 36 in the file is the number of strings in the array. I took a sample location entry (everything between FF FF FF FF's) and got this:
First 32 bytes are latitude and longitude:
66 35 20 42 Float Latitude
94 34 D2 C2 Float Longitude
Next however many, I have no idea:
FF 7F 9E 16 00 00 06 86 10 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 00
Then there are these two repeating sections:
93 3F 05 00
93 3F 05 00
93 3F 05 00
93 3F 05 00
and
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
B2 3F 05 00
Then this:
04 79 00 1C BC C4 01 00 EB
Then the index into the name array:
2D 12 Unsigned Short Index into strings array
And the remainder:
00 3F 06 00 40 AB 21 20 42 E2 21 D2 C2 02 00 41 0D 00 00 19 87 69 01 00 00 00 00 00 CB 6D 01 00
Hopefully someone else has some good ideas!
- Jes
Nice! Its another part of the puzzle. Do you think the strings array is refrenced by offset in the file, or offset by index? If it was an index offset, the program would have to load the entire array into memory at runtime, but isn't the POI database pretty huge (much more than a PDA running iG could handle)?
Ideas?
|
|
|
05-08-2006, 08:33 AM
|
#10
|
|
Newbie
Join Date: May 2006
Posts: 2
|
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
|
|
|
|
Sponsored links
|
|
Advertisement
|
|
| Thread Tools |
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 11:06 PM.
| |