Thread: Venus Series City Navigator China NT CHS 2011.11

Originally Posted by betahash

I think, without confirm with syzygy, ISM is no way to work with Venus, nor could it be Venus-ed.

It's not clear to me if ISM.IDX contains any shifted data that needs to be corrected or not. Judging by its extension IDX, I guess it should contain indices for searching purpose only and needs no correction.

If you have an official Garmin China device, you certainly can choose to install the official map or the Venus (optionally with QSI and ISM) map. Just need to make sure the shift adding feature provided by the bin file is or is not activated respectively. For all other devices, Venus map (without QSI and ISM) is the only choice left for China NT map.

Originally Posted by betahash

I just guess from the result plans and its names:
1. idx = index = properties , relationship and namespace alias
2. Any kind of alias must have a way to locate unique GPS record/mark. And vice versa.
3. Venus maps has unreliable distant-trip plan ---> such kind of coordination and alias seems less valid.
4. if the shifted GPS marks are used by aliases and their indexes, it might be impossible to offer a Venus version. In such a case precondition #1-2 ( #2 might be a false one) in this case might not be satisfied.-- e.g., for multi-connected points in several blocks , which are already orphan OR folded in Venus, their relationships and properties are already broken . Even their namespace aliases are consistent with corrected GPS marks, it will not work any more.

And for this reason and this result, inter-blocks {route} Mechanism is hard to rebuild in Venus.

Above is not based on any kind of research as syzygy has already done. I just tried to discuss this possibility in viewpoints of database and data structures --- could be nonsense as well.

Ander:
junction=crossing query
Intersection might be detailed address ( street, bld. number ) query. I have no such a device, try yourself.

My understanding of an index is: it is a key that helps the associated search algorithm to find the queried item quicky, without going through each item one by one. An index normally contains search key related data and pointers only, not all data of the queried item.

For example, a telephone book sorted by last names may provide you with an index table that maps A, B, C (keys) to the page number (pointers) of the first page containing last names starting with A, B, C respectively. You will not find a person's first name, address or phone number in the index table. Because of this, even if you update a person's phone number you don't need to update the index table. The same search algorithm will work just fine.

Now, treat the road name, ISM.IDX and coordinate as the last name, index table and phone number of the example above respectively. To search an address or junction, you will go through the index table ISM.IDX. Once you find it, you can look up additional info like coordinates and road side of the matched item. But like a phone book, correcting a coordinate will require no changes to the index table ISM.IDX and the same search algorithm will work just fine.

If there are route planning or routing issues, they should come from somewhere else, especially the NET and NOD subfiles. I would not think the ISM.IDX subfile is the culprit to cause wrong route planning and routing.