DesignID, ItemID or partnumber ?

[Magnus Forsberg]

I wrote this at the Part Tracker:

Isn't it time for some sort of definitive definition here?

7-digit number <=> ItemID <=> Part Physical_Colour <=> beginning with _ (underscore)
5-digit number <=> DesignID <=> Part Alias <=> beginning with = (equal to)
old design in a new mould, leading to a new partnumber, is a Part Alias <=> beginning with = (equal to)
partnumber only used for transparent parts <=> Part Alias <=> beginning with = (equal to)
partnumber only used for laquered parts <=> Part Alias <=> beginning with = (equal to)

Or am I totally wrong? I still find the difference between itemID, designID and our partnumbers very confusing.

and Philo answered:

Magnus, I'd suggest to put this on the forum for future reference...
Basically this is OK. A design number is _mainly_ a mold number, while item number is a shape in a specified color.
Unfortunately, LEGO also use 5 digits design numbers for patterned parts and sometimes (eg. hoses) for specific colors.

[Michael Heidemann]

Thanks for this Magnus. I had just the same idea this morning, but you where faster

Code:

partnumber only used for transparent parts <=> Part Alias <=> beginning with = (equal to)
partnumber only used for laquered parts <=> Part Alias <=> beginning with = (equal to)

Just the above I would like also to have more clear if possible. I like to build with the correct design id, but if it comes to transparent parts, I do not not which one should be taken. Maybe a future app can give me that information. MLCad can not and I do not recommend to make all work with MLCad, as it does not support so much of our efforts to help the user identifying a part he needs.

[Santeri Piippo]

I still strongly think it's a bad idea to bloat the library with Item ID parts simply out of the sheer amount of Item IDs out there. At least for the typical case of single-color item ID, these should be exported to a textual database like how I outlined it here. I'd keep the Physical_Color parts for special cases like 4285879.dat.

[Michael Heidemann]

If any of our tools would use such a database I would be fine with that. But as far as I can see, there is no tool that do this for me. So building with parts according the list provided by TLG for each set is impossible without that files.

But those parts should be located in another directory IMHO.

[Philippe Hurbain]

I still strongly think it's a bad idea to bloat the library with Item ID parts simply out of the sheer amount of Item IDs out there.

...and I strongly agree with you
Fortunately, the foundation of such a database already exists, courtesy of Brickset... http://www.brickset.com/export/parts/
To make that database fully usable, there is still a huge work to do to create all part aliases, and especially for patterned parts. But at least it's more manageable...
As for using this database, I'd like to see an evolution of LDFind (hint, hint, Mike

[Michael Heidemann]

Code:

As for using this database, I'd like to see an evolution of LDFind (hint, hint, Mike ;)

Which way do you think ?

[Philippe Hurbain]

More thinking probably needed, but...
I see split window design, with the same kind of text search available, one window using Brickset database (which is more or less directly LEGO service one), the other identical as the one we have today. If there is a design number match between the two databases, then both window halves display all available information.

[Magnus Forsberg]

Are there to many different Part Alias?
Should there be a different qualifier for transparent and/or laquered parts?

[Michael Heidemann]

I just had a look to that link. It generates a simple question to me:
How should I match the colournames in that file to LDraw?
Please see attached list of unique colour names.

[Michael Heidemann]

Maybe not too much but on building process I do not see currently which one i use, for transparent or for laquered parts.

[Michael Heidemann]

Yes, that is not really a big challange to do, but this is just what I like to avoid. By using LDFind for this, I need for each part that I like to use in my model ask LDFind for - maybe - another part. This is not the way I like to build.

Besides the challenge of matching the colours it's not a big deal (hopefully) .

[Philippe Hurbain]

Hopefully data in LDConfig.ldr is enough to get the LEGO -> LDraw matching?

[Philippe Hurbain]

Imho user knows 90% of parts used and find them by category/names. Only for the tricky ones will need to be looked up...

[Roland Melkert]

This seems something that could be solved using the LDConfig.xml file discussed awhile back (in regards to LOD).

Instead of a million .dat's just add the alias list to the xml. Any software can then use that information in their search function.

[Travis Cobbs]

Given that the alias list is likely to easily be 100+ times as big as the other stuff we suggested for LDConfig.xml, I think it would be much better to have any such alias list kept in a separate file. Also, I'm not so sure that XML is a good idea for an alias list file. Yes, it is a standard format, but in this case it seems like the XML would introduce a huge amount of bloat. To me, a SQLite database would make sense here, but I'm hesitant to suggest a proprietary binary format, even if it is the standard format for a cross-platform open source software product. (The fact that I work for one of the companies on the SQLite Consortium probably also biases me, but SQLite would provide fast, cross-platform alias lookups. For that matter, such a database could contain all the info in parts.lst as well, and could be used for any kind of indexing information that we want provide fast access to for software programs.)

[Michael Heidemann]

That's a good idea.
I hope that also NET applications are supported by the SQLite Team.
I have to look for that.

[Santeri Piippo]

We should keep things simple IMO. If XML is too much bloat I'd suggest we make a simple file format for the cause.

Code:

// PHYSICAL_COLOR <id> PART <design-id> COLOR <color> [...]
PHYSICAL_COLOR 4211000 PART 3660 COLOR 72
PHYSICAL_COLOR 4211536 PART 6553 COLOR 71
PHYSICAL_COLOR 50163 PART 48452 COLOR 72 PART 48168 COLOR 0
PHYSICAL_COLOR 4118687 PART 3815c4f COLOR 0

I'd really want to avoid sqlite if possible because it kind of sounds like complete overkill for this. Keep things in plain text!

[Michael Heidemann]

SQLite might be overkill for this special task. But we have many lists laying somewhere. If we would use only one single file for all those lists maintainance will be much easier.

[Magnus Forsberg]

Is PartID the same as ElementID?

Lego PaB and this blog use ElementID, but Brickset seems to call them PartID.
I called it ItemID above. Is that wrong?

[Michael Heidemann]

I would guess yes. Really important is not to mix the DesignID with one of the others (ElementID, PartID, partnumber, etc.)
The parts we build and that has LDRAW_ORG Part are only stored with the DesignID.

[Roland Melkert]

If not using a generic LDraw cfg XML file, I would prefer plain text special meta's over sqllite too.

Mainly because most software will have their own internal data structures making the sql engine redundant / overkill.

In the end it will probably only be used for importing the stuff into your own data environment, and having to learn sqlite api's while a basic LDraw parser is already available in your own code seems highly annoying to me.