You must be 16 or over to participate in the Brickset Forum. Please read the announcements and rules before you join.

BrickLink/Peeron Element Crossref

davee123davee123 USAMember Posts: 747
edited December 2011 in Everything else LEGO
So, is anyone out there aware of any cross-reference between element ID's in Peeron and BrickLink? For example, in BrickLink, you've got part ID "4342", which is the french bread loaf. But in Peeron, it's "x395". I've got a very short list (a few dozen) that I've compiled of these, but I was wondering if anyone has anything more comprehensive?

While I'm at it, is there any cross-reference done between LEGO Design ID's and BrickLink and/or Peeron IDs? In the example above, I assume that "4342" *matches* the LEGO Design ID (both BL and Peeron always intended for that to be the case, whenever possible). But then we've got elements like the camel from Prince Of Persia, where the BrickLink ID is "camel", and the Peeron ID is "x2001", neither of which are the Design ID (which I don't know).

DaveE

Comments

  • madforLEGOmadforLEGO USMember Posts: 7,496
    I think the LEGO element ID is in Bricklink somewhere cause you can search for a part by it.. depends on if it is in the Part description listing in BL or not.. I do not use much Peeron any longer, it seems like their part lists are not as accurate as they are for older sets.. I found a lot of issues between it and the parts in the box (I think people are submitting incorrect type part numbers in Peeron whereas BL is a bit better, at least for 10190)
  • davee123davee123 USAMember Posts: 747
    edited December 2011
    Well, yes, BrickLink has the "Part Number" that LEGO uses, but not the "Design ID". Effectively, the "LEGO Part Number" is the combination of LEGO Design ID and LEGO Color ID. For example:

    A "Plate 2 x 3" has a LEGO Design ID of "3021". But for a "Dark Green Plate 2 x 3", you have a LEGO Part Number of "4297717". And for a "Sand Blue Plate 2 x 3", you have a LEGO Part Number of "4153276". So different LEGO Part Numbers for each combination, but with the same LEGO Design ID for each.

    Peeron, BrickLink, and LDraw use the *combination* of the LEGO Design ID and the color ID in order to reference a particular instance of a part. But LEGO uses the LEGO Part Number. They do that because effectively, in a production line, they want a robot to go pick up parts from "bin X". The robot shouldn't care what the LEGO Design ID is, or what the LEGO Color ID is, so they use that separate numbering system.

    For a lot of parts, hobbyists don't know what the LEGO Design ID is-- like for a Super Battle Droid arm. When it got entered into the Peeron system, since they didn't know the LEGO Design ID, they had to invent a new number, so they arbitrarily used "x387". Similarly, when BrickLink entered it into their system, they ALSO didn't know the appropriate number, but they also didn't co-ordinate with Peeron (or visa versa), and so they wound up with "x280". In that case, we actually know that the LEGO Part Number for Battle Droid Arms in Pearl-Dark-Gray is "4499247". But as a community, we still don't know what the LEGO Design ID is for that element (or, at least, I don't think we do!).

    Anyway, I'm wondering if anyone's ever collected this data. I discussed this with Dan Boger some 5 years ago or so, and I know he didn't have that data at the time. But I have no idea if anyone out there had made any effort to collect the data.

    DaveE
  • brickmaticbrickmatic Member Posts: 1,071
    edited December 2011
    @davee123 If I follow you correctly, the LEGO Part Number identifies a particular shape and color. The LEGO Design ID identifies a particular shape, but not color. The LEGO Color ID identifies a particular color, but not shape. Thus the information conveyed by the Part Number is the same information conveyed by the Design ID along with the Color ID. HOWEVER, the Part Number is NOT numerically related to the Design ID and Color ID.

    That is stupid. Why couldn't they have made it so that the Part Number is the conjunction of the Design ID and Color ID? Even if it was in binary, like the part number is a 3 byte value with the first 2 bytes being the Design ID and the last byte being the Color ID. That would make things so much easier.
  • davee123davee123 USAMember Posts: 747
    That is stupid. Why couldn't they have made it so that the Part Number is the conjunction of the Design ID and Color ID?
    Actually, some do that-- The earlier LEGO Part Numbers (well, maybe not "earlier", but "more basic") are a combination of the Design ID and Color ID. For instance, a 2x4 brick has a Design ID of "3001", and the Color ID for red is "21", and the LEGO Part Number for a Red 2x4 brick is "300121".

    From what I can tell, all the 6-digit LEGO Part Numbers behave that way-- the first 4 numbers are the LEGO Design ID, and the latter 2 numbers are the LEGO Color ID. But longer Part Numbers seem to have no correlation. I'm not sure if that's the way they used to ALL be (until 5-digit Design ID's or 3-digit colors), or if they simply got "grandfathered" in that way when they started the "Part Number" system.

    Also, to make things even more confusing, some elements actually have *multiple* LEGO Part Numbers, like this one:

    imageimage

    Those are two different LEGO Part Numbers (4612985 and 4613928), but (I believe) identical. It's possible that these have different batch numbers, or are otherwise different somehow in a way that AFOLs wouldn't be able to tell (like the particular ABS mixture used), or that they're used in different packing facilities-- but yes, it just adds more to the confusion.

    DaveE
  • brickmaticbrickmatic Member Posts: 1,071
    Seriously, LEGO must have a file somewhere that lists their Part Number and the corresponding Design ID, Color ID, Part Name, and perhaps a CAD picture. They should just release that file to hobbyists. It will not hurt the company and shouldn't cost them anything either.
  • davee123davee123 USAMember Posts: 747
    They've got an internal database of the information that goes back to sometime in the 1990's, but they're VERY strict about that data going outside the company. Up until 2003, LEGO refused to share its color palette with hobbyists, because they were afraid of competition getting ahold of internal LEGO RGB, CMYK, and Pantone colors (which was pretty silly).

    I think the major reason that the data isn't accessible outside the company is that it probably contains upcoming and/or unreleased information that they don't want leaving the company. Of course, there's no reason they couldn't ONLY deliver the content from publicly released sets, but compiling that data that would take some development work for LEGO, and they're probably not willing to spend any time on it for whatever gain the hobbyist community would receive. We'll just have to wait for some AFOLs to get jobs in the LEGO internal Systems group who are willing to put in some off-hours work for the fans :)

    DaveE
  • brickmaticbrickmatic Member Posts: 1,071
    Up until 2003, LEGO refused to share its color palette with hobbyists, because they were afraid of competition getting ahold of internal LEGO RGB, CMYK, and Pantone colors (which was pretty silly).
    Yes, because you could just take a colorimeter to the bricks and why would a competitor care to get the shade just right?
    I think the major reason that the data isn't accessible outside the company is that it probably contains upcoming and/or unreleased information that they don't want leaving the company. Of course, there's no reason they couldn't ONLY deliver the content from publicly released sets, but compiling that data that would take some development work for LEGO, and they're probably not willing to spend any time on it for whatever gain the hobbyist community would receive.
    OR they could just save the file as it is today and release it in a year or two OR if possible they could release a file from one or two years ago that they have on their backups. It would still be very helpful even with the two year lag.
  • davee123davee123 USAMember Posts: 747
    Yes, because you could just take a colorimeter to the bricks and why would a competitor care to get the shade just right?
    Exactly. Ultimately, any serious competitor could just extract the CMYK or Pantone color closely enough that it wouldn't matter, all for a few hundred dollars in equipment. But for hobbyists, it's more than just the color values-- and they don't typically want to spend several hundred JUST to extract colors.
    OR they could just save the file as it is today and release it in a year or two OR if possible they could release a file from one or two years ago that they have on their backups. It would still be very helpful even with the two year lag.
    Well, I think the issue is that it's not a simple file, like the color data. The Color Palette is distributed internally to various departments every year so that different groups know what colors to use in their various media. If (for instance) the US catalog department wanted to show a particular part in the catalog, they'd have the matching CMYK value for the print file. Similarly, if the web department wanted to show a particular color, they'd have a "corporate approved" RGB value to display. Etc, etc, etc. They just distribute a file around the company (used to be an Excel file), and everyone knows what to do.

    But this is much more complicated, so it's not a simple file that they can save. It's a set of database tables that's not really uniform. They may have entries for parts that are unreleased, and WON'T be released for many years in the future. For example, the skeletal horse molds were created before 2003 (probably 2002 or earlier), and may have had an entry in the database, even though it wasn't released until 2007.

    So, in order to produce a cross-reference file (like the kind I'd like), they'd have to set up an extract, and include some complex logic in it to make sure that ONLY the "safe-to-release" information is included. And I don't know how difficult that would be (if it's even possible). It could be a 10-minute job, or it could be a several-month-long process.

    Where it would be really nice is LUGBULK (which is coincidentally why I'm asking about the crossref). Right now they have to translate fan-based names and ID's into LEGO ones for LUGBULK requests, and that takes manpower. If a database extract would save them time (and therefore money), then it's in their interests to do it. But to date, whenever I've asked about it, the answer from LEGO is "No, that's too difficult". Personally, I don't have a lot of confidence that they've looked into it in detail-- but that's me speaking as a developer. I'm imagining that it would be a simple set of SQL queries, and maybe a quick few regex's, writable in an afternoon, and usable ever-after at the click of a button. But since I'm not familiar with their databases, I can't actually promise that it's really that easy.

    But the big thing is that you have to convince the lawyers. Even if my guess is correct about being a pretty easy extract, convincing LEGO's legal team that it's a safe and prudent thing to do may be a bigger battle than anyone wants to take on.

    DaveE
  • IstokgIstokg MichiganMember Posts: 1,771
    Thanks for the details Dave.... now I wish a designer would find a need for the 2x2x3 75 degree slope double convex that they probably already have a mold have waiting for a use for somewhere... I wonder if they had the same part mold in 33 degree slope already developed before the Robie House Architectural Set came out?

    Of course when TLG releases these type of parts that help complete "a system"... they torture us with "it's not available in the right colors".... :-(

    I don't know how long I've waited for a 2x2 45 degree double convex slope in trans-clear to go with those bazillion 2x2 trans-clear regular slopes I've accumulated over the years in basic sets... hoping one day to make a trans-clear pyramid like those in the courtyard of the Louvre in Paris.... but I digress...
  • bluemoosebluemoose Member Posts: 1,714
    edited December 2011
    ^^ that's my experience too; I have (and I know of others have too) been lobbying for them to release element and set inventory data to the fan community, but I've been repeatedly told that it would be too expensive to manipulate the data into a form suitable for release outside the company. I've volunteered community effort to do the work (figuring I wouldn't have any difficulty finding volunteers should they ever say 'ok'), but it's something they just aren't interested in pursuing at this time ...

    ^ there are many unreleased elements in the Design Lab in Billund; I've seen & handled a few (as have others from the fan community over the years). Pretty much anything we could dream up as a useful new part has already been designed, prototyped & tested ... for example, several years ago I got to handle some prototypes of the 1x1 round tiles that have just started to appear in sets.
  • brickmaticbrickmatic Member Posts: 1,071
    @davee123 Thanks for the detailed info. :) I think you're right about the lawyers. Or at least about the CYA mentality you often find in business environments. I suspect, like you do, that they haven't looked into it seriously. This is most likely because the information is spread around different departments and negotiating across departments in likely a lot harder than if the info is all wrapped up in one place. As to the safe-to-release information, I'm sure their manufacturing department has information in the database as to what is actually being made. So you could use your simple set of SQL queries and maybe a quick few regex's to compile a list that doesn't include anything that isn't being made. Even if they don't release a comprehensive list, a partial list would be a good place to start and would be much appreciated by the community. I hope some momentum within TLG to do this develops as the fan community would really appreciate it and it might even prove to be useful to TLG internally. I mean, the more accessible and easily queried your database is, the easier it is to put that information to good use. If you can't easily get the data you want, then it might as well not exist, right?
  • MinifigsMeMinifigsMe Member Posts: 2,828
    Just resurrecting an old thread, as I'd really like to be able to get at the element IDs for parts with out finding them first in bricklink, then finding a set it's in, then going in to Lego's replacement parts and trying to get the element ID that way. it's very convoluted.
    The element IDs (colour and shape identifier) must be in bricklink, as you can search by them. but I can't find out how to get at the info!!
    Anyone?
  • sidersddsidersdd USAMember Posts: 2,427
    ^ Once you've navigated to the part you want in Bricklink, click the totally obvious "View Small Images" link in the middle of the page. You'll get a page with images of the part in different colors, as well as a table showing the part color codes.
    rocaoMinifigsMebrickmatic
  • MinifigsMeMinifigsMe Member Posts: 2,828
  • DawnTreaderDawnTreader Chilliwack CanadaMember Posts: 10
    So here is a question...

    Why doesnt the fan community get together and start a new and better organizing number system.

    I rather like the idea of using the shape as one number and then a color as another. those are 2 simple tables with a 1 to many relationship in a database. the only other thing i think that i would do is to group things in a way so that all bricks are numbered one way, all plates another and so on. in fact i would almost keep the groupings that LEGO has in LDD and use them for a part grouping ID.

    i think that the biggest reason that LEGO doesnt hand out all the data relating to thier parts is that they are human. i was looking at an instruction book the other night trying to record the parts for francesco bernuli into my own lego inventory database. i noticed that some of the parts seemed to be duplicates of a totally different number from LDD. same part shape and color, but 2 different numbers.

    that means that either someone screwed up in the instructions or in the creation of the part information in LEGO's database. either way, i bet they would rather not let us see all the inventory mess that humans create.

    i work at a place where we have a lot of inventory messes and i just dont believe that any large inventory can be perfect as long as there are humans involved.
  • HuwHuw Brickset Towers, Hampshire, UKAdministrator Posts: 5,578
    edited December 2012
    Interesting to see this thread revisited given what's happened recently.

    Here's my take on it.

    LEGO parts have a design number and a colour number

    Before 2002 or so, parts were numbered design number + colour number (e.g. 300101, 2x4 brick, white)

    Since they introduced SAP, numbers for everything they produce -- parts, boxes, instructions, poly bags, leaflets etc. were allocated sequentially in the same number series.

    > Why doesnt the fan community get together and start a new and better organizing number system.

    Two reasons,
    1: the community is too fragmented and set in its ways: BrickLink won't be changing anything any time soon and Peeron is dead.
    2: There is no need now that official information is available from LEGO, and exposed here at Brickset.

    > same part shape and color, but 2 different numbers.

    That happens a lot, either because a mould has been changed slightly or production of a particular part has restarted after having been previously 'retired' (I believe). I don't think it's down to errors as such.

    BTW, @Davee123, the battle droid arm is part 41890: http://www.brickset.com/parts/?part=4499247

    BrickLink records some of LEGO's part numbers and provides a cross reference with its own numbering, and it can be downloaded from http://www.bricklink.com/catalogDownload.asp, 'Parts and Colour codes'

Sign In or Register to comment.
Recent discussions Categories Privacy Policy