Skeys Library

[rompik]

Hello Shing, I want to make form for adding new skey symbols to IsoAlgo.skey (as I understood it based on IDF format) for isometrics. Please, can you write briefly how to recognize symbol details in symbol file, like for example next symbol lines: 501 FLWN 100 3 0 0 0 0 0 0 0 0 502 1 0 275 1 100 550 2 100 0 2 0 0 0 502 2 0 275 1 100 450 2 500 325 2 500 225 0 502 2 100 100 1 0 275 2 0 550 2 100 550 0 502 1 500 275 0 0 0 0 0 0 0 0 0 0

What do values in columns mean? What do you think if to store all skeys in xml based file which will be more human-readable? Currently, I'm preparing form for adding/modifing skeys but unknowing internal structure of skey file stop my work. Here is UI of form:

[eryar]

Hello Roman,

Yes the symbol skeys are ISOGEN format.

You can refer to there document: https://docs.hexagonppm.com/r/SKEY

https://vdocument.in/building-user-defined-symbol-shapes-55844787522b5.html?page=10

[rompik]

Thank you! Second document is what I needed:) But what do you think if we will change format of symbol to xml? In this case, we will be able to add more information, which can be required in catalogues.

[eryar]

The early version of IsoAlgo I used xml to save symbol data, in order to use ISOGEN symbol data I changed to read ISOGEN symbol file directly.

I think the data in ISOGEN symbol is enough for ISO drawing generatation.

[rompik]

Mainly yes, there are a lot of symbols inside Isogen symbol file. But previously, on some of our projects, we had to update symbol files for some specific catalog elements. Also, it's quite difficult to understand from isogen file if required symbols is existing and no need to add it. That why I would like to have small form, which will allow getting information about existing symbols and add new one if there is need. For me, it's also good exercise for pyqt training:)

[eryar]

Yes, the ISOGEN file is difficult to understand without documentation.

Your symbols library form is great and looks like the Symbol Editor of Intergraph.

[rompik]

Hello Shing, After investigating documentation and checking symbols file, I think of using Isogen format of file is way to "dead end" for PipeCAD as complexity of isogen format will prevent next evolution and supporting of symbol library in case it will be required to add more information/properties to symbols. As I understood, such format was developed in condition of RAM limits for old PCs, but currently we haven’t such limits.
As you already used XML format, I can convert all symbols to it quite quickly and continue working with iso symbol file using XML library. Or we can use JSON form (it’s just questioning what do you prefer). In any case, if we will start using XML or JSON format, we will be able to get next benefits: 1) Symbol file can be open for all users who will require to add more symbols. Even PipeCAD symbol file can be like an industry library for symbols keys, as iso symbols will be “standardized” for using by different companies to avoid situation when iso contains the same symbols but with different skeys. 2) Avoid 4 symbols limitation for Skey. Skey can be 10 symbols (for example), so we will be able to have a lot of symbols for different subtypes of piping elements. For example, for a valve with several connections, we will be able to code all required combination (we can setup Skey naming convention to avoid mix of same symbol but with different skey); 3) In symbol file, we can describe geometry of symbol in easier manner, like for example:

<geometry>
    < type=”arrive” position=”-1.0;0.0” style=”Solid” ></type>
    < type=”tee” position=”0.0;0.0” style=”Solid” ></type>
    < type=”leave” position=”0.5;0.0” style=”Solid” ></type>
    < type=”spindle” position=”0.0;0.0” skey=”01SP” style=”Solid” ></type>
    < type=”line” position_start=”-1.0” position_end=”1.0” style=”Solid” ></type>
    < type=”circle” position=”0.0” diameter="0.5" style=”Solid” ></type>
</geometry>

For geometry, we will be able to use specific styles to add more graphics details on iso view. 4) Later symbol file can be also written to catalog database, so we can replace process of skey writing in detref by selecting of required from Iso Symbols library and keep reference to it. And by moving to skey element we will be able to achieve some specific information from it or automatically use “corrected” one like for piping catalogs. 5) We can remain only one Skey: no needs to have New Skey and Base Skey. 6) I would like to draw symbol in relative coordinates with limits -1 to 1. It will allow making size of all symbols equivalent and remove scale option. So it will make iso more readable and code of IsoAlgo is more simple. Currently, in symbol file I found elements with size more than 4000 units which require to use scale to view it on screen.
If you think that we can go this way, please can you share format of XML which you used or if you want I can prepare test XML file and discuss it.

Here is the current version of skey library utility, which currently works like a viewer. When I finish basic functionality for adding new symbol and saving to file, I will push updates to master.

https://user-images.githubusercontent.com/12736532/210360878-e5c18b46-79b6-4563-b7b4-87b0c89e1778.mp4

[eryar]

Hello Roman,

Happy new year!

I agree with you and prefer JSON format, JSON is simple and compact.

For IsoAlgo I will keep the old ISOGEN skey file support and provide the new JSON format support.

The skey scale is import, I think you can draw the symbol in 1:1 scale, not limit it to -1 to 1. Because some symbol is longer, such as valve symbol is longer than weld symbols in ISO drawing. The scale option in skey file is useful and base on the 1:1 symbol, if you change scale option, will zoom in/out the symbol in ISO drawing.

[rompik]

Thank Shing, Happy New Year! I found your first version of IsoAlgo and could find example of skey file in xml. Now I converted isogen symbols to JSON format. Here is an example for couple symbols (still need to correct coordinates):

    "CK": {
        "group": "Valves",
        "subgroup": "Check Valve",
        "description": "",
        "spindle_skey": "",
        "scale_factor": 1.0,
        "orientation": "Use on non-symmetrical component",
        "flow_arrow": "Default",
        "dimensioned": "Default",
        "geometry": [
            "ArrivePoint: pos=(100,200)",
            "Line: start=(100,150) end=(100,250)",
            "Line: start=(300,150) end=(300,250)",
            "Line: start=(100,250) end=(300,200)",
            "Line: start=(300,200) end=(100,150)",
            "Line: start=(125,200) end=(187,200)",
            "Line: start=(187,200) end=(175,212)",
            "Line: start=(187,200) end=(175,187)",
            "SpindlePoint: pos=(200,200)",
            "LeavePoint: pos=(300,200)"
        ]
    },
    "VB": {
        "group": "Valves",
        "subgroup": "Ball Valve",
        "description": "",
        "spindle_skey": "03SP",
        "scale_factor": 1.0,
        "orientation": "Use on symmetrical component",
        "flow_arrow": "On",
        "dimensioned": "Default",
        "geometry": [
            "ArrivePoint: pos=(100,200)",
            "Line: start=(100,200) end=(100,250)",
            "Line: start=(100,250) end=(300,150)",
            "Line: start=(300,150) end=(300,250)",
            "Line: start=(300,250) end=(100,150)",
            "Line: start=(100,150) end=(100,200)",
            "Line: start=(193,232) end=(206,232)",
            "Line: start=(206,232) end=(218,227)",
            "Line: start=(218,227) end=(227,218)",
            "Line: start=(227,218) end=(232,206)",
            "Line: start=(232,206) end=(232,193)",
            "Line: start=(232,193) end=(227,181)",
            "Line: start=(227,181) end=(218,172)",
            "Line: start=(218,172) end=(206,167)",
            "Line: start=(206,167) end=(193,167)",
            "Line: start=(193,167) end=(181,172)",
            "Line: start=(181,172) end=(172,181)",
            "Line: start=(172,181) end=(167,193)",
            "Line: start=(167,193) end=(167,206)",
            "Line: start=(167,206) end=(172,218)",
            "Line: start=(172,218) end=(181,227)",
            "Line: start=(181,227) end=(193,232)",
            "SpindlePoint: pos=(200,200)",
            "LeavePoint: pos=(300,200)"
        ]
    },

I added group/subgroup attributes to show keys in TreeView (to replace TableView and make like in Symbol Editor in SP3D). Also, I added properties for description to provide precise details "what for" this symbol as in subgroup could be several different skeys. May be later description will be found like useless but by my experience in PDMS/E3D quite difficult to understand purpose of user defined symbol which was created long time ago by somebody else.

If this format of JSON file is suitable for you, I will keep it. If not, just give me know what better to change.

My idea for using relative units is in allowing user to create symbols with required proportion depends on default symbol size. In this case, user will see difference how is big or small his symbol compare with default symbol. Size of unit can be defined during iso creation and for example 1unit could be equal 5mm (or any other size for more clear representation in iso). I used this way just due to my experience, when user doesn't know which symbol size will looks correctly on iso, so they create symbol and after manipulate with scale to get correct representation on iso. So I think that better to avoid this situation in the begging. In any case, I will align size of symbol to have correct proportion compare with default size.

[eryar]

Hello Roman,

        "spindle_skey": "",
        "scale_factor": 1.0,
        "orientation": "Use on non-symmetrical component",
        "flow_arrow": "Default",
        "dimensioned": "Default",

These options I think it is better use number for programming, for position such as arrive point line start/end point, I think use arrive_point: x=0, y=0 line: x1 = 1, y1=1, x2=10, y2=6

will simplify the conversion.

Yes, IsoAlgo support relative position in symbols.

[eryar]

Hello Roman,

:thumbsup: :thumbsup: :thumbsup:

[rompik]

Hello Shing, Thank you! I thought it will be useful to create separate class for making drawing, so it can be used later for making module for drawing diagrams and connect it with 3d model like in AVEVA.