All Activity

This stream auto-updates     

  1. Earlier
  2. I am a Staff Author at Field Engineer a Marketplace for On-Demand telecom workforce, extending from field engineers to high-level network engineers, project managers and Network Architects in 146 nations. I am an IT Engineer.

  3. Attached sample of Shamir product base chart. As you can see for some of the Sphere power we have some bases that we can produce but only one of them is the primary. e.g.: for SPH=-2.00 the primary base is 3.00 and the secundary are base 4.00 and 5.00. I will be happy to add more information if its not clear. Autograph III 18 - HI Polar Brown.pdf
  4. Shamir also prefer option number 2 with some notes: Add field to LDS file that indicate if we receive measurment value or defaultr value. Shamir, as a vendor, should have an option to send this default value to LMS systems by LPDS protocol. As i see it we have an impact on 2 protocols: 1. LPDS - set default value for some of parameters. 2. DCS - add fiels or flag that indicate the type of the value (measured or default)
  5. Hi Nick, First, just to be clear, this is for the new standard still under development, not the existing LDS. The problem is that we do not have a standardized, universally unique way of identifying things outside of physical lenses. OPC's work for that and while expanding the use of OPC was discussed it's not really feasible for this purpose. So it's really about more than packages. No user of the standard would be forced to create packages in their LPDS catalogs but if they want to we would like to have a single ID methodology that can be applied to those as well. I think your last bullet is on point... I believe that is exactly what the group is trying to develop. Regards, Paul
  6. During the LPDS Committee meeting (and the DCS meeting) an issue was brought up surrounding parameters and allowing the LDS to specify that parameters should not be filled with defaults. The specific example discussed was that when POW values are sent to the LDS these are sometimes filled by one of the systems between the patient and the LDS (LMS, PMS etc). Ideally this should not happen and it would be beneficial for the LDS to specify this. This issue could be handled by adding a field to the parameter object which specifies that the parameter can not have defaults applied. Alternatively a field could be added which specifies the source of the data (ie Patient) which implies it cant be filled at any other point in the system (this option would be my preference). Any further discussion or comments would be appreciated.
  7. Couple comments from lens manufacturer/lab perspective: what is the problem that is trying to be fixed? I am coming late to the party and just curious so I can better understand the goal of this Having OPC/IDs for packages I believe is excess Many times "packages" or Marketing campaigns are temporary.. so why go through all this work for something that would be obsolete a few months later? This presents another step in launching a Marketing campaign which could potentially limit your ability to respond to market demands quickly (it takes time to request identifiers, load them in our system, then load them in LMS systems, etc) if there was some sort of design identifier that all LMS companies can recognize, this would make the process much more efficient and easy to use from a lens designer perspective Hope this helps and look forward to the conversation. Nick
  8. During the LPDS Committee meeting the working group presented their proposed implementation for concise base cure and range chart definitions. This proposal is outlined in this thread: During discussions at the meeting representatives from Shamir pointed out that this method does not allow the specification of an allowable base curve range for a specific power combination. The group requested this topic be started so further discussion could take place between now and our next meeting at Vision Expo West.
  9. Starter topic for discussion of product ID's to be used in LPDS to include identification of "packages" which may include lenses and various treatments. Please post your thoughts, questions, concerns, etc. If you have any specific proposals on the creation of product identifiers please feel free to share those as well.
  10. Here there is an example for 2 IOT products. One of them using collections of lens blanks provided by a different vendor. https://drive.google.com/file/d/1WOeT749fTRTYdJcw1eub9apVTHAKSlR7/view?usp=sharing
  11. Agenda for our 2019 VEE meeting. 2019 VEE - DCS Agenda - FINAL.pdf
  12. I also added the DCS fields for polarized film details into the Blank; PLRCRV & PLRLOC
  13. Hi Steve, We have updated the Zeiss complete example to use the changes you have made above, excluding alphabetical ordering of fields. This example is larger than required for the working document but can provide a second reference. It can be found though the following link: Updated Example - Google Docs (I recommend turning print layout off when viewing the document) I have also added some suggested changes to better map fields in Blanks to their respective DCS fields: Base -> MBASE Addition -> ADD Front Radius -> FRNT Back Radius -> BACK
  14. I've updated the working definition, which is still using the same file location as before. https://docs.google.com/document/d/1W9JL-d93RfKZwRp_2K1hBtD27-PhyVI6_-WZjZdrKF4/edit?usp=sharing I've modified it so that some of the naming is more consistent now. A reference to a list of other items defined elsewhere in the document has a name ending with "IDs" A reference to a single item defined elsewhere in the document has a name ending in "ID" The Owner value has been removed from each object, given that the ID now incorporates the owner. Alphabetized fields, to make tracking down missing ones easier (Though I stopped doing Blanks after the first few). Changed the way treatments were included in the Characteristic Family to match how it was done at the product level, with using specific lists indicating requirements such as "Required Treatment IDs" I've also included a diagram of that JSON structure. Each box has three sections that are delimited by a horizontal line The first section indicates the name of the node. If there is more than one line in that top section, it indicates a child object of the parent. The second section is for values that are either the object's ID, or references to another objects ID The third section is for values that are not foreign keys, and are informational about that particular object. I think adding all the lines that would point to Parameters and Treatments would make the document a lot more difficult to read, so I've left those out. But, a name that has "* Parameter ID(s)" or "* Treatment ID(s)" will indeed be referencing objects in those appropriate nodes.
  15. https://drive.google.com/file/d/1JJjTVyaq626b9ggYyBP90m8Q4d0o-U8f/view?usp=sharing
  16. Hi, Marcos - I sent you the link to the google document via email.
  17. Hi there, I was trying to find the working sample that Stephen was editing during our last call yesterday. Is it in a Google Drive or somewhere that can be shared? I would like to use it to edits the samples that I was working on. Maybe we should have a shared Google Drive folder where to upload everything that we work on directly. It could be easier to follow up for any updates. Thanks
  18. Hi there. My name is Paul Wade and I'm a liaison for The Vision Council. I'd like to see if I can help you with this but it might be better if you contact me directly. You can email me at pwade@thevisioncouncil.org. If you could include some more detail about the system you are trying to design I can try and provide you with some documentation that might help with your goal.
  19. is there any standard and easy way i can define my lens code number with description to my customize lens inventory system. please advice.
  20. The audio from the DCS meeting at VEW 2018 has been uploaded to our Google Drive folder. https://drive.google.com/file/d/1SapKukV1slmkNc3DEKaQQD0IGraaZreT/view?usp=sharing Please let me know if you have any trouble downloading it. Paul
  21. Hi Everyone, The audio from our working group meeting is now available: https://drive.google.com/file/d/1wr30abo1Zib0v-dtwuONCzYBLw7pbRS0/view?usp=sharing Let me know if you have any trouble downloading it. Thanks, Paul
  22. Hi Everyone, The audio for our 2018 VEW meeting is now available: https://drive.google.com/file/d/1jsTOINTa0IwKT9y-xKi0jIGtfqQqsaPI/view?usp=sharing Let me know if you have any trouble downloading it. Thanks, Paul
  23. 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.
  24. The presentation attached proposes a way of more efficiently communicating range chart data rather than a list of each combination or simple array. The second file is a more detailed version of the presentation. Please review and provide feedback, suggestions or alternatives. One observation raised at the meeting was that there might be a more efficient way to define boundaries rather than the use of in between 025 steps (for example -262cyl) referring to a numerically irrelevant base curve (1000D). Base Selection Communication Detailed Description.pdf Base Charts Communication Presentation.pdf
  25. 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.
  1. Load more activity