LDraw.org Discussion Forums
LEGO 2 LDraw 2 BL - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: LEGO 2 LDraw 2 BL (/thread-23337.html)

Pages: 1 2 3


LEGO 2 LDraw 2 BL - Willy Tschager - 2019-04-07

I'd like to discuss the argument opened here:

The LDD ldraw.xml file has this structure:

<!-- Arch  3 x  6 x  5  30613.dat -->
<!-- PAVILION 6X3X5  19063 -->
<Brick ldraw="30613.dat" lego="19063"/>
<!-- PAVILION 6X3X5  30613 -->
<Brick ldraw="30613.dat" lego="30613"/>

<!-- Animal Dolphin  6228b.dat -->
<!-- DOLPHIN 9M  6228 -->
<Brick ldraw="6228b.dat" lego="6228"/>

How does it look like in Studio?

How would an information like this treated in an editor? Would it show also the alternate number or just jump to the right part is an element number is entered say in a search?

w.


RE: LEGO 2 LDraw 2 BL - Roland Melkert - 2019-04-07

(2019-04-07, 12:05)Willy Tschager Wrote: How would an information like this treated in an editor? Would it show also the alternate number or just jump to the right part is an element number is entered say in a search?

Could be as simple as XML:
Code:
<items>
 <item src="6228b" dst="6228"/>
</items>

or JSON:
Code:
[{src: '6228b', dst: '6228'}]

or even CSV
Code:
6228b,6228

An editor would use it as a translation table.

Any format could be generated if the 3rd party names would be stored in the parts tracker as metadata.

We could also introduce a new LDraw meta for this, and add it to the parts themselves. Eliminating the need for an index file altogether.


RE: LEGO 2 LDraw 2 BL - Lutz Gehlen - 2019-04-08

(2019-04-07, 18:40)Roland Melkert Wrote: Could be as simple as XML:
Code:
<items>
 <item src="6228b" dst="6228"/>
</items>

or JSON:
Code:
[{src: '6228b', dst: '6228'}]

or even CSV
Code:
6228b,6228

An editor would use it as a translation table.

Any format could be generated if the 3rd party names would be stored in the parts tracker as metadata.

We could also introduce a new LDraw meta for this, and add it to the parts themselves. Eliminating the need for an index file altogether.

Hi all,

I think the two of you are talking about two different aspects. Roland is talking about how to store the information in files. One important aspect is whether to store the reference system of a part number explicitly. In the ldraw.xml file that Willy quoted the attribute names encode explicitly which is the lego number and which is the ldraw number. In my opinion this is preferable over src/dest. In the latter case you need meta information on the file in order to know how to use it. For example you need to know that this is an ldraw to lego translation file and not the other way around or ldraw to bricklink or whatever. In the former case, this information is stored in the content of the file itself. You could even have something like

Code:
<item ldraw="foo" lego="bar" bricklink="baz" />

in one go. Whether the file format is XML or JSON is not that important I think, but CSV might be too limited.

I think the last idea is interesting to store the information in the files themselves and eliminate the need for a translation file altogether. Roland, could you elaborate on that idea? Do you think of something like
0 ALIAS LEGO 6228
or what is the idea?

On the other hand, if I understand correctly, Willy is talking about how to expose this information (no matter how it is stored) to the user in an editor. I think from a model author's point of view there are several aspects. If I want to add a part to my model it would be most convenient if I can find it under any of its part numbers. Maybe I have found the part in a Lego model or on Bricklink or wherever and now I want to use it. On the other hand, in some situations I might want to use its number in a specific reference system. For example, I might want to look up on Bricklink how expensive the part is. Or I want to export a Bricklink XML file. It just happened to me that I exported such a file from LeoCAD and could not import it to Bricklink before I manually translated some of the part numbers. Ideally, this is to be avoided by an editor if such translation information is available.

Cheers,
Lutz


RE: LEGO 2 LDraw 2 BL - David Manley - 2019-04-08

(2019-04-07, 18:40)Roland Melkert Wrote: We could also introduce a new LDraw meta for this, and add it to the parts themselves. Eliminating the need for an index file altogether.

If I'm understanding this correctly, this suggestion would be to specify the part mapping within the individual part files. Given that BrickLink's part number change over time, wouldn't the implication of doing this be that then the individual LDraw part files would need to be updated? If so, I think an index file would be more preferable.

Also, if something along these lines sees the light of day, it might be worth liaising with rebrickable.com. They have a pretty good database mapping between LDraw, LEGO, BrickLink and BrickOwl part ids and a published API which might simplify the generation of any mapping file.

David


RE: LEGO 2 LDraw 2 BL - Milan Vančura - 2019-04-08

(2019-04-08, 8:41)David Manley Wrote: If I'm understanding this correctly, this suggestion would be to specify the part mapping within the individual part files. Given that BrickLink's part number change over time, wouldn't the implication of doing this be that then the individual LDraw part files would need to be updated? If so, I think an index file would be more preferable.
The index file has more advantages:
* any utility can read just one file than thousands of files
* any standard format (JSON, YAML, XML...) allows us to use standard libraries immediately and easily
* there is a room for extensions (I'd like to have a database of existing colors for each part, one day in future... - I know, I know. It's hard to get and maintain. But let me dream, OK? Wink )
* any change is a problem of this index file, not a certification of the part


RE: LEGO 2 LDraw 2 BL - Magnus Forsberg - 2019-04-08

I think we have to have this information outside the individual dat-files. The same dat-file would be referenced in many different ElementID. The same dat-file would be used in a red brick as in a blue brick, but have different ElementID.

ElementID = DesignID(shape of the brick) + colour of the brick.


And to make it even worse, sometimes the DesignID mean the shape of the brick, and sometimes it means the design of the print on the brick. The same DesignID could be printed on both a 3626c.dat and on 3626b.dat. But they would have uniqe ElementID numbers.

I think it would quickly become a nightmare to sort all this info correct.

And why do we want our own database when all of this is already at Rebrickable or Brickset?
Lets use what is already done and build on that.


RE: LEGO 2 LDraw 2 BL - Philippe Hurbain - 2019-04-09

Fully agree with Magnus !


RE: LEGO 2 LDraw 2 BL - Willy Tschager - 2019-04-09

Last time we recycled all parts through the PT to add the licence we had a stilstood of almost two years so adding this kind of information to the single parts is a no-go.

w.


RE: LEGO 2 LDraw 2 BL - Johann Eisner - 2019-04-09

(2019-04-08, 22:24)Magnus Forsberg Wrote: I think we have to have this information outside the individual dat-files. The same dat-file would be referenced in many different ElementID. The same dat-file would be used in a red brick as in a blue brick, but have different ElementID.

ElementID = DesignID(shape of the brick) + colour of the brick.


And to make it even worse, sometimes the DesignID mean the shape of the brick, and sometimes it means the design of the print on the brick. The same DesignID could be printed on both a 3626c.dat and on 3626b.dat. But they would have uniqe ElementID numbers.

I think it would quickly become a nightmare to sort all this info correct.

And why do we want our own database when all of this is already at Rebrickable or Brickset?
Lets use what is already done and build on that.

I followed this article with great excitement and did not understand anything at the beginning.
Now that I know what is meant, I also think that we do not have to reinvent the wheel.


RE: LEGO 2 LDraw 2 BL - Jaco van der Molen - 2019-04-09

(2019-04-07, 12:05)Willy Tschager Wrote: I'd like to discuss the argument opened here:

The LDD ldraw.xml file has this structure:

<!-- Arch  3 x  6 x  5  30613.dat -->
<!-- PAVILION 6X3X5  19063 -->
<Brick ldraw="30613.dat" lego="19063"/>
<!-- PAVILION 6X3X5  30613 -->
<Brick ldraw="30613.dat" lego="30613"/>

<!-- Animal Dolphin  6228b.dat -->
<!-- DOLPHIN 9M  6228 -->
<Brick ldraw="6228b.dat" lego="6228"/>

How does it look like in Studio?

How would an information like this treated in an editor? Would it show also the alternate number or just jump to the right part is an element number is entered say in a search?

w.

Following the discussion... have to think about contributing.
After all it was kind of "my idea..."  Blush