Announcement

Collapse
No announcement yet.

Editing/reading iguidance POI bin files

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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?
    Current projects: iGmod reloaded (Latest release) (put on hiatus indefinatly)

    Unlimited Internet and gps tracking for $6 a month with boost mobile!

    Carputer 2: www.lmaocar.com

  • #2
    hasnt happened. But DAMN do i hope you get the job done!
    mp3Car.com Senior Tech Blogger (Want a product reviewed? Contact me.)
    Follow Me on Twitter or Facebook
    Live mp3Car Facebook Chat

    Comment


    • #3
      i'm also cheering you on..

      p.s. we gotta hang out sometime
      Shawn



      Check out my web company Minneapolis Web Designer | MODx Web Design - Himmelberger Design

      Comment


      • #4
        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.
        Current projects: iGmod reloaded (Latest release) (put on hiatus indefinatly)

        Unlimited Internet and gps tracking for $6 a month with boost mobile!

        Carputer 2: www.lmaocar.com

        Comment


        • #5
          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
          mp3Car.com Senior Tech Blogger (Want a product reviewed? Contact me.)
          Follow Me on Twitter or Facebook
          Live mp3Car Facebook Chat

          Comment


          • #6
            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?
            Shawn



            Check out my web company Minneapolis Web Designer | MODx Web Design - Himmelberger Design

            Comment


            • #7
              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...
              Current projects: iGmod reloaded (Latest release) (put on hiatus indefinatly)

              Unlimited Internet and gps tracking for $6 a month with boost mobile!

              Carputer 2: www.lmaocar.com

              Comment


              • #8
                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

                Comment


                • #9
                  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?
                  Current projects: iGmod reloaded (Latest release) (put on hiatus indefinatly)

                  Unlimited Internet and gps tracking for $6 a month with boost mobile!

                  Carputer 2: www.lmaocar.com

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      iguidance poi hexedit hack

                      Originally posted by PURDooM View Post
                      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?


                      Has anyone made any progress on reversing the POI's for iguidance 2009?

                      Comment

                      Working...
                      X