Thread: Adding POI's in iGuidance???

1) Only operations will be add/delete/modify POIs and the only data guaranteed to be changeable is lat/long/name

Interesting project! Don't forget 'POI Categories', etc...

Originally Posted by MatrixPC

Just make sure it is 40 buck per hr or for a whole project.

Exactly, SOW!!! $40 bucks here, 40 there. I would rather pay 5 bill$ as a community and get it done with an interface for importing and exporting than $40 bucks to someone who couldn't possibly think it is respectible to ask for 40 bucks!

If this coder can creat this module to import, I say we use him to extract the other POIs from the Lexus system (from what i understand Lexus has one of the best lists).

create a mySQL database (yes at over a million records, it may get sluggish but it wont matter to much)

I build websites using MySQL and PHP and personally own a website with over 15 million entires in a single mysql database table, it take approximatly 40 seconds to query the entire thing for a single object. MySQL/PHP could be used to elimitate duplicates if neccesary, but i do not think it will be neccesary to go to such lenghts. In my opinion, if the abiliy to delete current POIs is there then the most logical way of avoiding duplicates is to remove ALL POIs from iGuidance and just import the most complete list we can acquire. Then as stated above just circulate the complete replacement BIN file for everyone to use.

Interesting project! Don't forget 'POI Categories', etc...

POI Categories will be an important feature. We should be sure to ask if this can be done as well.

One of the things I do like about the project is that the developer mentioned releasing it under the Open Source license so everyone may have access to modify/use it. Open source, from what I have experienced, is a great thing. You end up with a community who is motivated to help the rest of the community for a cause instead of a profit.

Steve - Check your PMs, I just sent you the details for providing the software for the coder.

I think this is a greta project and the coder definatly deserves a bonus if sucsessful.

-DrDank

Upon reviewing my last post I have noticed a few typos and would like to clarify for everyone that I HAVE been drinking and should not be held accountable for my fingers not finding their mark on the appropriate keys.



Also, there are some concerns about the price of this project. I agree that the price is very low, but what seems difficult to one may be something rather simple to another, and we should not dicredit the coder's ability who has bid on this project because of his price.

There is the reason funds are held in escrow until the project is completed sucessfully AND why we are going to give him a bonus , should he be sucsessful.

-DrDank

Haha, you're talking about me, this is where I stand:

I have been decoding the POI file and I have determined:

Little-Endian coding is used.

At offset 0x24 there is a ULONG referring to the number of entries in the string table.

At 0x78 the string table starts. Entries are separated by NUL. It ends at 0xAEF196.

POI entries are 31 bytes long.
There is no static separator between entries.
The structure is as follows where B is the starting offset of a POI.

B+0 = ULONG where the OFFSET IN THE FILE of the string in the file is determined by the 20 LSB (mask with 0x000FFFFF to get offset). I have no idea what the high 12 bits are for but they are used.
B+4 unknown, likely signed LONG, -1 is common in sections
B+8 unknown, but matches between POIs with same LAT/LONG (maybe just LAT?)
B+12 unknown, but matches between POIs with same LAT/LONG (maybe just LONG?)
B+16 FLOAT, LATITUDE
B+20 FLOAT, LONGITUDE
B+24 USHORT, flag bits of some kind, very sparse "bit-on" pattern
B+26 unknown, likely LONG, I think it might be the same for all POIs in a section (most-significant byte never seems to be utilized)
B+30 CHAR, values range from 1 to 34 or so, smells like flags, could be something as simple as a category

First group of POI entries starts at 0x01516C05

However, the more and more I unwrap the more and more I find and go UHG. Although I initially believe the file to be a rather simple database format and deeper inspection shows a huge tangle.

The file appears to be a balanced tree of some sort. POI sections are interspersed with what I am calling "G" (for lack of better name blocks) which are 54 bytes in length and precede the respective POI sections. (Patterns of POIs per section looks like 430, 43, 5, 1 indicating a tree of some sort). The last 8 ULONGS are pointers into memory locations into the following POI regions.

Following that out further I get to the sparse-data section (quite literally a dozen MBs or so if almost all 0's) which, while at first glance appear meaningless, contains memory references to the "G" blocks.

It is slow and VERY tedious work. I don't know if I'll be able to decode the sparse region and data and other miscellaneous information. (Which is a long way after after decoding the "G" blocks and what I believe to be additional tree-algo fragments in the POI entries).