Steve Shanbaum

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve Shanbaum

  • Rank
    Newbie
  1. Steve Shanbaum

    Base Curve Charts

    Steve posted the presentation in another thread, so that's a better starting point than this one and the discussion should take place over there.
  2. Steve Shanbaum

    Base Curve Charts

    This is to get the conversation started on Base Curve Charts within the LPDS. (Very condensed and slightly modified) Zeiss presented something similar to the following as a suggested terse method of transmitting the Base Curve Charts. Steve should be able to post the actual presentation to get much better detail to explain this. Add, Sphere, Cyl, Base 0, -9, -4, NA 0, -9, -2, 8 0, -9, 0, 6 0, -6, -4, NA 0, -6, -2, 6 0, -6, 0, 4 Where a -6sph, -2.5cyl would pick a 6 base. Which, at first glance, to fit into JSON tersely, would be something like: “Base Curve Charts” : [ { “ID” : “123”, “Owner ID” : “TVC”, “Adds” : [ “0” : { Spheres : [ “-9” : [ “-4” : “NA”, “-2” : 8, “0” : 6 ], “-6” : [ “-4” : “NA”, “-2” : 6, “0” : 4 ] ] } ] } ] Which, since JSON parsers don't ensure that things get spit out in the same order that they were input in, the readability goes out the window. It also doesn't have to be interpreted into JSON and could be left more in the original format. But, this is just to get conversation going about this.
  3. I took the CZV example and modified it to apply the changes we discussed during the working session. Namely, Having materials appear once with treatments owning the lenses used Adding processing parameter collections Having treatment reference IDs in three arrays to indicate Inherent/Required/Excluded treatments Moving the mandatory flag on the processing parameter to instead be implied in the name of the array the processing parameter appears in Including an example of region exclusivity, with a region override. https://docs.google.com/document/d/1W9JL-d93RfKZwRp_2K1hBtD27-PhyVI6_-WZjZdrKF4/edit?usp=sharing The document should be valid JSON at this point - I changed the comments to a JSON-acceptable format, so that it would pass through jsonlint.
  4. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    That works for me.
  5. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    One difference is that it will allow for datasets. A common thread I've heard (outside the forum) is that it's a bit verbose for the task. I'd argue that computers will be able to quickly generate or consume the extra text, but that when a human has to examine the OMA data to determine, for example, why a particular device is receiving a given LMATID, it'd be much faster to search through that text for "LMATID" and run through the results and immediately determine which device-specific line applied. That's as opposed to finding a LMATID line with a particular prefix and move back up to find out what to what PROCBLK that line belongs and getting the device there. Now it may be that's not a use-case that's of great concern to folks, and to help determine if I'm imagining a problem, I've attached three examples LMS files that use the three main recommendations for PROCBLK (or lack of it). So, what's the LMATID for a FSG-OPT-VHZ in each of these files? ProcBlockUniquePrefix.txt DeviceSpecificPrefix.txt ProcBlockRequireContiguous.txt
  6. Steve Shanbaum

    PROCBLK new record + SDFMODE extension

    That's a good point, Yaron. I'm a little torn on this, as it's entirely true that we have a number of other datasets that are necessarily ordered and contiguous. TRCFMT RR= RR= There's value in following that schema. Though, I think there'd be something cleaner about using a special character to indicate belonging to a particular PROCBLK, and the '!' seems handy for this, as I'm not aware of it being in use. PROCBLK=FSG;SCH;HSC !LMATID=70;70 !ETC=1;2 Where there wouldn't have to be any restructuring of the contents of the block, as the line is otherwise correct. Looking, the pipe character is a reserved character, and doesn't currently have a definition when used in a name, so that might be a better alternative if we want to maintain absolute compatibility. One other thing that might combine the best of both worlds - we've been using the tag for PROCBLK to identify an upcoming block...what if we didn't use PROCBLK, but simply had the machine prefix on the tag. FSG;SCH;HSC|LMATID=70;70 FSG;SCH;HSC|ETC=1;2 Pros 1) These device-specific records don't have to be contiguous. 2) Ease of knowing which device a line is targeting. 3) Backwards compatible. Cons 1) More verbose.
  7. Steve Shanbaum

    Lens Blank Groups

    What was throwing me on the blank families discussion was that I had planned a similarly named element, but for a different purpose. The blank group I'd envisioned would hold the elements common to a collection of blanks, such as the material, class (semifinished/finished), and possibly other features like Intrinsic Treatments. But, I do understand the goal of this other blank group now. Maybe it would be good to have both? A shared-characteristic grouping, as well as a product-availability grouping?
  8. Steve Shanbaum

    LPDS Lens Catalogue

    Prior file got sent to the cornfield. LPDS v1.0.json
  9. Steve Shanbaum

    LPDS Lens Catalogue

    That'd be great - I know I'd like to work on that. I started to hash something up while we were at the meeting (this attachment), but any starting point on the actual layout would be good at this point. LPDS v1.0.json