Is it possible to set or renumber Element IDs so it starts with specific value?
Like start all elements with 100000 similar as it is with file position which starts with 4000000?
Hi Oto,
Oto said:as it is with file position which starts with 4000000?
I am not sure whether file position starts with this number. The file position is in-memory information, not persisted anywhere, valid only "right now", which is different from ElementID. But, it's true I never check the value, because in API, it was (because file position is quite obsolete concept and is used rarely) like to receive it in one function and to pass it to another.
Oto said:Like start all elements with 100000
ElementID is 8 bytes number, persisted in DGN V8 format, incremented automatically when a new element is added. So it starts from 1 (I guess) and just counting up.
Oto said:Is it possible to set or renumber Element IDs so it starts with specific value?
No.
I even think that there is no API how to access ElementID in read-write mode. I can imagine to create a new file, copy at first all settings from the source one, fill the rest to the defined "start ID" by some dummy elements and copy source elements one by one.
But, what can be an advantage of such change? ElementID is similar to identity number in SQL database: The important feature is not value, but that it is unique and does not change during record lifetime.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan Šlegr said:The important feature is not value, but that it is unique and does not change during record lifetime.
Exactly but could hold additional value. What I am looking for is a workaround in case adding it as Items doesn't work in the workflow.
Idea is to have number for each file which is unique in each file but also for many files from one supplier.
Oto said:Idea is to have number for each file which is unique in each file but also for many files from one supplier.
Often these types of request are solved creating GUID from file (source) ID and element ID.
I can imagine "file ID" or "model ID" (what is better for this specific purpose) can be stored in DGN file as application data or as hidden EC data (both can be done using API) and used when "unique ID" is necessary.
Moving the elements looks more complicated to me, but both solutions require some coding and application support.
Regards,
Oto said:Idea is to have number for each file which is unique in each file but also for many files from one supplier
The element IDs within a DGN file are unique. IDs are not re-used: delete an element and its ID goes with it. It's quite possible to have two DGN files that contain elements having the same ID.
In the context of DGN files, it's not possible to have unique IDs across different files. What would happen when you use Windows to copy a DGN file? In that case, the entire file is a bag of bits that is use to create another bag of bits: Windows knows nothing about MicroStation. A unique ID can be obtained by concatenating the element ID with a DGN file GUID. But where does the file GUID come from?
You need a GUID convention, as Jan suggests, to maintain ID uniqueness within a project. IFC, for example, identifies objects with a GUID.
A Document Management System (DMS) is one way to assign GUIDs to files controlled by that DMS. I know, for example, that it's possible to configure ProjectWise to assign a GUID to each document under its control. By combining the file GUID with the DGN element ID you obtain a unique, albeit large, unique identifier for each and every element in that project.
As Jan notes, the actual values of those GUIDs is irrelevant.
Regards, Jon Summers LA Solutions
GUID will not work as requirements is to have incremental ID within specific interval(large one)
Oto said:GUID will not work
"Incremental ID within specific interval" is also GUID.
Oto said:to have incremental ID within specific interval(large one)
When the requirement is to have incremental ID (and continuous optionally) over more files, I think it's not very compatible with individual DGN files with own "element id numbering".
I can imagine that when the files are sent to a customer, application can analyze them and to create a new ones, using some logic to use (and delete after that) enough elements, so every file will start from some ID.
But how to solve a situation, when the files will grow, so gaps between numbering will have to changed from time to time, so the history cannot be maintained (existing file will receive different IDs in different exports)? Or, it's about one export at the time, with no continuity required?
Oto said:Requirement is to have incremental ID within specific interval
That's not possible without intimate control over MicroStation's ID generator. There's no user access to that mechanism, and there are no APIs that control it.
If you're not using a document management system (DMS), then I suggest that you consider an Item Type that provides an ID, then create an Item instance for each element for which you need an ID. That way you're in control of the ID generator.
Jan identifies some of the problems you must solve in order to create a safe ID generator. It's akin to the row indexing that relational database vendors have developed, where the ID generator must be reliable when multiple users want to assign the next ID to an object. It's not a simple algorithm. If you're using a DMS, that would be the first place to start seeking an ID generator.
Jan Šlegr said:Or, it's about one export at the time, with no continuity required?
Only that each supplier have some element counter within this interval not required to have to exactly elemID any other method could also work. Maybe item value which could be sum of Initial value(File Properties comment field)+ElemID could do the trick.
Jon Summers said:I suggest that you consider an Item Type that provides an ID, then create an Item instance for each element for which you need an ID
Thanks but will need more details as not have yet grasped how to use Items in a such way.