(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?

(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.

(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.

(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.

(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.

(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.

(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.

(2019-04-09, 21:53)Orion Pobursky Wrote: I think this a fairly trivial problem to solve as long as the APIs to Rebrickable and Bricklink are robust. A simple script that runs every so often to update a database and then another script to pull info from the database to auto-generate a file in the format of choice (I think JSON is appropriate). Manual entries to the database would also be available to suppliment the API data. We could even do an initial population of the data by scraping already available KEYWORD data. Maybe a front end to allow searching. I'm super worried about it being 100% accuarate, just "good enough".

(2019-04-11, 7:17)Willy Tschager Wrote: Could you find out if this is doable? As for 100% accuracy - we are working on this project for ... some 25 years ... and are still far from perfection ;-)

w.

(2019-04-12, 12:34)David Manley Wrote: It is do-able. I've just knocked something together to process the rebrickable data using their published API. My attempt at producing a reasonable output is visible here.

There are a couple of rough edges to remove from my solution but I'll post my approach and scripts on here in the morning, should there be any interest.

David

(2019-04-09, 21:53)Orion Pobursky Wrote: I think this a fairly trivial problem to solve as long as the APIs to Rebrickable and Bricklink are robust. A simple script that runs every so often to update a database and then another script to pull info from the database to auto-generate a file in the format of choice (I think JSON is appropriate). Manual entries to the database would also be available to suppliment the API data. We could even do an initial population of the data by scraping already available KEYWORD data. Maybe a front end to allow searching. I'm super worried about it being 100% accuarate, just "good enough".

(2019-04-12, 12:34)David Manley Wrote: It is do-able. I've just knocked something together to process the rebrickable data using their published API. My attempt at producing a reasonable output is visible here.

There are a couple of rough edges to remove from my solution but I'll post my approach and scripts on here in the morning, should there be any interest.

David

• Windows PowerShell
  
• curl (free to download from https://curl.haxx.se/)
  
• saxon (free to download the Home edition from http://www.saxonica.com)
  
• you have a rebrickable account and already have an API key or you obtain a free API key for your account from rebrickable 
  

1. I have been running this on Windows 10, using PowerShell 5. It should run on earlier versions of Windows, depending on which version of PowerShell is installed on the OS. Try it and see.
   
2. I'd suggest you alter the PowerShell script part_mapping_generate.ps1 on line 48 and update it with the path to your installation of saxon. You can pass this value in as a command line parameter if you so wish but I suggest this will quickly become tiresome
   
3. While the output format appears to be okay, I need to do some checks on whether all the parts have been output. According to Rebrickable's website, they have 32 000+ parts in their database. The generated XML file currently contains 5 000+ parts. I'll to a bit of digging into this.
   
4. Some rebrickable part ids map to multiple part ids in other systems. For example this part lists two LDraw part numbers. This can occur for systems other than just LDraw. My unconfirmed suspicion is that the first part number listed when there are multiple matches should be taken as the "best" match.
   
5. I don't know whether rebrickable differentiates between the part id being the same between two systems (e.g. rebrickable and LDraw) and a part being only in rebrickable but not in LDraw. When the part id is the same, I think it does not explicitly identify the LDraw part id but is it doing the same thing when there is no equivalent LDraw part? Something I shall be digging in to.
   
6. I keep forgetting how much I dislike PowerShell scripting.
   

1. The command is invoked from the Powershell command line thusly;
   .\part_mapping_generate.ps1 your-api-key xml-output-file-name json-output-file-name
   
2. The parameter values influence its behaviour
   

• .\part_mapping_generate.ps1 your-api-key
  Queries rebrickable and output XML to standard output
  
• .\part_mapping_generate.ps1 your-api-key abc.xml
  Queries rebrickable and output XML to the file abc.xml
  
• .\part_mapping_generate.ps1 your-api-key abc.xml abc.jsn
  Queries rebrickable, output XML to the file abc.xml and JSON interim output to abc.jsn
  
• .\part_mapping_generate.ps1 "" abc.xml abc.jsn
  Takes its JSON input from abc.jsn rather than querying rebrickable and output XML to the file abc.xml
  
• .\part_mapping_generate.ps1 "" "" abc.jsn
  Takes its JSON input from abc.jsn rather than querying rebrickable and output XML to standard output
  

1. The command is invoked from the Powershell command line thusly;
   .\part_mapping_generate.ps1 your-api-key xml-output-file-name json-output-file-name
   
2. The parameter values influence its behaviour
   

• .\part_mapping_generate.ps1 your-api-key
  Queries rebrickable and output XML to standard output
  
• .\part_mapping_generate.ps1 your-api-key abc.xml -output_progress 1
  Queries rebrickable and output XML to the file abc.xml and displays progress when querying Rebrickable.
  
• .\part_mapping_generate.ps1 your-api-key abc.xml abc.jsn -output_progress 1
  Queries rebrickable, output XML to the file abc.xml and JSON interim output to abc.jsn and displays progress when querying Rebrickable.
  
• .\part_mapping_generate.ps1 "" abc.xml abc.jsn
  Takes its JSON input from abc.jsn rather than querying rebrickable and output XML to the file abc.xml
  
• .\part_mapping_generate.ps1 "" "" abc.jsn
  Takes its JSON input from abc.jsn rather than querying rebrickable and output XML to standard output
  

(2019-04-12, 15:29)Orion Pobursky Wrote: Very nice. I think maybe we should seek a closer partnership with Rebrickable since they seem to be very LDraw friendly.

(2019-04-16, 5:50)David Manley Wrote: I made a couple of posts over in the Rebrickable forum regarding the mapping of part ids.  The potential implications of the replies is that it would be beneficial to be running some form of confirmatory query of the existence of a LDraw part id as part of the process of creating a mapping file.

Is there (he wrote optimistically) any form of API available to query the LDraw parts database e.g. to obtain a list of the part ids? This could be used as part of the transformational process of Rebrickable's data to create better matching part ids.

Regards,

David

(2019-04-16, 6:40)Willy Tschager Wrote: I guess the only person who can gives a proper answer is Chris. Beside that I'd like to hear from the code-gods how the drawn information can be used in their progs?

w.

(2019-04-16, 15:27)Orion Pobursky Wrote: There is no formal API. All the individual parts are accessible online but the expection now is for people to download the library and collate thier own database.

(2019-04-18, 6:39)Jaco van der Molen Wrote: Something worth looking at, I think?

LPub3D has element-ID integration too in the BOM!
See https://github.com/trevorsandy/lpub3d/issues/196
It can get the element-ID based on color too:


And, using some LDView features it can create a partslist with Designnumber and Elemen-ID!

(2019-04-19, 0:24)Orion Pobursky Wrote: I replied to this on Rebrickable.

(2019-05-06, 14:31)Willy Tschager Wrote: Is there going on some work in the background I'm not aware of? Could you please update us on the progress?

w.