The suggested value for the ID-offset when reading additively or when using model transfer files is always the highest existing ID+1. Thereby in many cases (particularly by using external extensions for IDs), long IDs could develop which may cause overflows.
Since Visum14 many network object classes offer the function 'Renumbering': Nodes
Links/Zones/Main nodes/Main zones/Territories/POIs/Screenlines/Count locations/Detectors/Stop points/Stop areas/Stops/Lines (Vehicle journeys/Coupling sections) -> (Right click to open the context menu) -> Renumbering
This function is also available as COM method 'Renumber' for each network object collection type, which is more powerful than the respective context menu functions. It (optionally) respects filters and allows to define a custom stepping.
Using this, you can do the entire job in one call. You can even call this from the Python console AddIn:
Where the arguments are (new start number, stepping, OnlyActive True|False)
Workaround for older releases (< Visum14):
Re-number the ID's of particular object classes via COM. In most cases, this can be done by using the line ''For Each anObject In Visum.Net.Nodes.GetAll', like, in this case, for nodes. The setting of the new value is possible via 'anObject.AttValue('NO') = newNumber'.
Links have to be handled separately. The reason for this is, that links have an initial and an opposite direction, so they consist of two different objects which have to be changed at the same time. That's why you are not able to use the method AttValue('NO'). Thence, the link number could not be changed via COM until Visum 10. Since Visum 11 therefore there is the method SetNo(...).
Some objects use a multipart key and don't have the attribute 'NO'. In this case, re-naming is not necessary.
Examples are contained in this VBA project: