Skip to main content

Creating good GLDF files

How to create GLDF?​

The most efficient method is to create GLDF directly from the PIM system. It involves generating an XML file containing all the necessary files and properties. If you can already create ROLF or ULD files from your systems, creating GLDF should be a straightforward process. The container aspect is relatively new, but it's essentially just a zip archive with a renamed file suffix.

We have various tools in mind to support the creation of GLDF, similar to how DIAL or RELUX member tools supported ULD or ROLF creation. These tools range from Excel templates to database tools. The specifications for GLDF and L3D are publicly available, allowing the community to develop free and open tools.

Some PIM system manufacturers even provide GLDF generators due to the open format. Implementing GLDF should be relatively easy with such support. Additionally, on gldf.io, there are tools already available to investigate and create L3D and GLDF files. It's also possible to manually create GLDF files using an XML or text editor.

GLDF offers flexibility with many optional structure elements. You can start with a simple LDC file and the product name in GLDF, but, of course, this won't be sufficient for most applications.

A good starting point is to match the data amount of ROLF and ULD. Ensure you have a unique product name and number (and GTIN). A geometry, even a simple one, is mandatory. If the product has multiple light outputs and lamps, make sure to include them. It's recommended to add a product picture and a description in multiple languages. If your PIM system ,supports product variants, make sure to fill in the variant structure in GLDF.

The next level involves transporting all the data from your creating PIM system to GLDF. However, filling up all the native properties that GLDF offers can be quite challenging. It's essential to carefully consider the specific data and properties that are most relevant to your and your users needs.

Validation​

Many rules in the GLDF XML are already validated by the XML schema (XSD) and errors prevented this way. If the XML is valid against the schema, an essential step towards a good GLDF has already been taken. But not all constraints can be covered with the XSD schema. Therefore, on this page you will find further rules, recommendations or simply hints on how to create good GLDF files.

Provide consistent translations​

The GLDF allows translations to be specified in many places, in the form of the Locale elements:

<Root>
  <Header />
  <GeneralDefinitions />
  <ProductDefinitions>
    <ProductMetaData>
      <ProductNumber>
        <Locale language="en">Global product number</Locale>
        <Locale language="de">Globale Produktnummer</Locale>
      </ProductNumber>
      <Name>
        <Locale language="en">Global product name in English</Locale>
        <Locale language="de">Globaler Produktname auf Deutsch</Locale>
        <Locale language="fr">Nom global du produit en français</Locale>
      </Name>
    </ProductMetaData>
    <Variants />
  </ProductDefinitions>
</Root>
tip
  • Rule: Provide for at least one language at each translatable element a translation of this language
  • Recommandation: Provide English translations for each translatable element
  • Recommandation: If you define some language at one element, provide this language at all elements
  • In the example above, the first rule is satisfied because the luminaire data contains at least one consistent translation for both - the ProductNumber and the Name element. In this case even two languages: German (de) and English (en) are completly translated.
  • The first recommendation is also fulfilled, as all elements contain an English translation (en).
  • The second recommendation, however, is violated because only one of the two elements contain a French translation (fr) and the other does not.

Provide a consistent default language​

The Header element contains a child element called DefaultLanguage:

<Root>
  <Header>
    <DefaultLanguage>de</DefaultLanguage>
  </Header>
  <GeneralDefinitions />
  <ProductDefinitions />
</Root>

It specifies for applications the language that should preferably be displayed if the product does not provide translations in the application's display language. Assuming an application such as DIALux is running in German and a GLDF contains the two languages Spanish and French - with the DefaultLanguage you could influence that one of the two languages, that should be used as a fallback. The important part for this to work is the following rule:

tip
  • Rule: For the specified DefaultLanguage, provide at each translatable element a translation of this language

Interchangeable Emitter without Geometry​

This rule applies only to GLDFs with the definition of Emitter but without Geometry elements. This use case is also indicated by the usage of the EmitterReference element:

Photometry Only - Do not use optional equipments

The rule states:

tip
  • Rule: In the so-called photometry-only case (when using EmitterReference and omitting any Geometry definition), interchangeable emitter definitions like in the example above should be avoided. Because in this use case not only the photometric information is taken from the photometry, but also the geometric. Define multiple Emitter and use them in multiple Variants instead.

Duplicate file names​

Another rule applies to the file structure within the GLDF container. As this is an ordinary ZIP archive, it is theoretically possible to create two different files with exactly the same file name within one folder. For example, within the image folder, a product image of the luminaire named product.jpg and a product image of the lamp also named product.jpg. This can cause problems if applications need to unpack these files into a file system such NTFS on Windows (which does not support equal file names).

tip
  • Rule: Do not use equal file names for different files within one directory.

Forbidden file name characters​

A similar rule applies to certain characters within the file name. In particular, the backslash \ should be avoided. This is allowed in a ZIP archive, but when unzipping such a file it would lead to the file being unpacked into a subdirectory and thus an incorrect File reference.

tip
  • Rule: Do not use the Backslash \ charackter in file names

Too many Variants​

It may be tempting to define not only a luminaire but a complete product family in one GLDF through the usage of Variants. However, the strongly recommendation here is to limit the definition to the essential variants of a single luminaire.

tip
  • Recommandation: Specify only a single luminaire in the Variants, not a whole product family
  • Recommandation: Limit each GLDF to a maximum of 15 Variants

Too large GLDF files​

GLDFs are intended for the exchange of luminaire data. Be it as is or integrated within lighting design projects of applications such as DIALux or RELUX. For this purpose, it is important that they do not exceed a manageable size.

tip
  • Recommandation: Keep your GLDFs small and do not exceed the size of 5MB

You can achive this in several ways:

  • Resize and compress your images. 1000 pixel and jpg with a 70% compression should be sufficient for most use cases
  • Offload files like PDFs to the web and link them only in the File element - instead of delivering them within the GLDF