BrickLink Discussion Forum

In Catalog, Brick.Door writes:

For parts is the z dimension the height? Because I looked at 1x1x5 brick and
the height is .8 cm. The actual height was entered as the y dimension.

Or is the z dimension the smallest? So that it can be used to determine whether
the item will fit in a thin envelope. In that case there are many entries that
need to be changed.

Before all the work of populating part dimensions i think we need to figure out
how it is going to be used.

Many of the currently entered Packing Dimensions were mass imported from LDraw
data when Instant Checkout was implemented in 2017. These measurements have no
user credit - that is how you can tell where they came from.

Things were done that way to get the system up and running quickly, but at this
point we need to refine the data. I am outlining the submission rules on the
Help page, but essentially what they say is this - for parts, use the stud dimensions
to determine the order of the fields. Where there are no stud dimensions, add
dimensions in whichever order you wish.

So please submit a correction to that data. It is very likely there is more wrong
than just the order of the fields.

Instant Checkout will work no matter what order the data is in, but when stud
and metric dimensions are listed together, it makes sense that the fields line
up.

The Z dimension should always mean height / thickness according to the rules
for stud dimensions.

Author:

randyf

Posted:

Apr 7, 2021 11:16

Subject:

Re: Inventory Change Request for Minifig sw0100

Viewed:

32 times

Topic:

Inventories Requests

In Inventories Requests, dcarmine writes:

Then why is the figure pic in DK OG? The set pic and box image also have it
as DK OG?

There are many official set images and box images that show things that were
never included in the sets, but our guideline is to *not* alter official set
images or box images. However, we can change the figure image. There just happens
to be another image attached to that figure that shows the correct hair, so we
will just remove the image with dark orange hair. The image for the figure with
cape is already correct, also.

Author:

Brick.Door

Posted:

Apr 7, 2021 11:04

Subject:

Re: New Packing Dimensions Feature

Viewed:

44 times

Topic:

Author:

brickerking

Posted:

Apr 7, 2021 11:00

Subject:

Re: New Packing Dimensions Feature

Viewed:

42 times

Topic:

In Catalog, Admin_Russell writes:

Personally, I would encourage you to spend 100% of your measurement submissions on actual dimensions at this point, and not worry about the studs.

Yay, this makes sense! You can always perform a calculation on the server side
to display stud dimensions. Entering a real unit of measurement on the user/data
entry side is a great improvement!

Author:

tec

Posted:

Apr 7, 2021 10:56

Subject:

Re: New Packing Dimensions Feature

Viewed:

36 times

Topic:

Good to know

Author:

Admin_Russell

Posted:

Apr 7, 2021 10:48

Subject:

Re: New Packing Dimensions Feature

Viewed:

59 times

Topic:

In Catalog, cosmicray writes:

In Catalog, Admin_Russell writes:

In Catalog, yorbrick writes:

Just to note, you have snipped the image starting with the 2x4 brick but not
included its dimensions. I got confused with the first set of dimensions x, y
and z until I realised they are for the slope and not the brick.

Sorry about that. Here is another screenshot:

An observation, and not a criticism, the Z dimension (on the brick and the slope)
correctly includes the height of the stud on top, and because of that is not
directly convertible into brick heights (when measured in brick units). This
is because assembled bricks nest the stud within the bottom of the above brick.
And, as we all know, no one ever ships bricks assembled (but see below).

Which also, causes the rather oblique situation of hips/legs (which have studs
on top) and torsos, to not add up correctly in the Z direction, because of being
shipped individually.

Somewhere in all this (part II or part III ?) we need to address the issue I
pointed out a couple of weeks back about part-assemblies (e.g. wheels and tires)
and how they are measured for X+Y+Z and if assembling them is required.

Nita Rae

There is no relationship or dependency between the two types of dimensions
- stud and metric. I know in the past that stud dimensions were used to give
an estimate of actual metric size, but we don't want to do that now.

I will continue adding examples of how we want you to measure things for the
catalog. It's going to be a long Help page!

Author:

Admin_Russell

Posted:

Apr 7, 2021 10:44

Subject:

Re: New Packing Dimensions Feature

Viewed:

55 times

Topic:

In Catalog, tec writes:

Update:
Many of my measurements got rejected
Is it because of fractions? (0.5 0.66 ..)
My example was:

44567b Hinge Plate 1 x 2 Locking with 1 Finger on Side without Bottom Groove
Parts: Hinge

where W=1.67

They were rejected because we do not accept stud dimensions on non-standard parts.
Especially now that we have actual metric values being added, there is no need
to find the stud dimensions for weird shapes.

In fact, we are considering hiding stud dimensions altogether, or moving them
to a separate info tab to keep people from being confused. Almost all pertinent
stud information is contained in the item name anyway.

Of course, it is a bit subjective whether a part is "weird" enough to not have
stud dimensions, but that is up to the catalog admin handling the request. Personally,
I would encourage you to spend 100% of your measurement submissions on actual
dimensions at this point, and not worry about the studs.

Author:

cosmicray

Posted:

Apr 7, 2021 08:31

Subject:

Re: New Packing Dimensions Feature

Viewed:

40 times

Topic:

In Catalog, Brick.Door writes:

In Catalog, Emporiosa writes:

In Catalog, Brick.Door writes:

How will this be used? Will we be able to set up a shipping method that is only
allowed if all pieces are under a certain thickness? (i.i USPS large envelope/flat)

So the checkout would need to find the smallest of the three dimensions for each
element in the cart, and make sure it is below the threshold.

Or is it just to better approximate the total volume of the order?

It's already very much in use with Canadians sellers; it can jump from a
$1.94 stamp to $22 if the part is over 20mm in thickness. Canadian sellers have
been manually putting in the packaging dimensions for every oversized item (and
setting those items to Volume based).

What you do is set the packaging limits (if you have any for USPS) in the shipping
option like you mentioned, and it ensures that if there's a thickness maximum
(like the 20mm in Canada for Lettermail), that no part has any dimension that
goes over that. There's also general volumetric dimensions that you can set
where it's to try to calculate if "that much LEGO" can fit into what you
gave it, but I'm not entirely sure how well this part works.

So you have to exclude a part with any dimension over 20mm? That doesn't
seem like it would work very well. A 1x6x5 brick can easily fit but only one
of its dimensions is less than 20mm.

Believe it or not, the correct answer to this question also involves orientation
within the envelope when shipped. If you put solid bricks (or any part) in the
envelope with the wrong orientation, then it becomes what is known as a nonmachinable
letter. It all has to do with what USPS (and likely Canada Post) normally
expect letter mail to be subjected to when it goes through the processing equipment.
See this passage in Postal Explorer for a better detail of the requirements (DMM
101.1.2) …

https://pe.usps.com/text/DMM300/101.htm?q=diameter&h=diameter&t=H&s=R&p=1&c=DMM|QSG

There are even a few USB thumb drives that are thin enough to get thru letter
mail, but you need a thin cardboard frame to keep them oriented correctly.

Nita Rae

Author:

cosmicray

Posted:

Apr 7, 2021 08:18

Subject:

Re: New Packing Dimensions Feature

Viewed:

42 times

Topic: