powsybl / powsybl-diagram Goto Github PK

• Do you want to request a feature or report a bug?
  API consistency

• What is the current behavior?
  SLD provides code to write to SVG a voltage level or a substation. The feature is identifical, but:

• there is no base class to these classes to mutualize the code for VL and Substations
• the writeSVG method takes the same parameters but not in the same order

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  Be able to write code like this:

Diagram diagram;
Identifiable identifiable = network.getIdentifiable(id);
if (identiable.getType() == VOLTAGE_LEVEL) {
    diagram = VoltageLevelDiagram.build(...);
} else if (identifiable.getType() == SUBSTATION) {
    diagram = SubstationDiagram.build(...);
} else {
    throw Unsupported();
}
diagram.writeSVG(prefix, writer, path, labelProvider, styleProvider);

• What is the motivation / use case for changing the behavior?
  Have an API simple to use

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?

Feature

• What is the current behavior?

The feeders are nodes that are put at the vertical extremity of an extern cell.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  Having the possibility of having feeders that are picked horizontally to an extern cell.
  The Extern Cell shall have at least one "normal" feeder displayed vertically.

• What is the motivation / use case for changing the behavior?
  Display ground Feeder nodes.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  The way 2 and 3 windings transformer are managed in the diagram generation part is not very clean. Looking at DefaultSVGWriter we can see some hack to be able to get SVG sub components corresponding to windings.

• What is the expected behavior?
  It could be interesting to add in the component library the concept of sub components in case of multi-terminal nodes. So in most we would have only one sub component but in the case of transformers (and maybe others later) we would have 2 or 3 sub components, one for each terminal. Each sub component would have its own SVG (so it will be easier to independently style each of the sub component).

SPEC TO DETAIL BEFORE CODING.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  In the case of substation diagram, there is no special processing for crossing snake lines:
  

• What is the expected behavior?
  To improve readability we could draw a "bridge" in case of 2 snake lines crossing:
  

Before coding this feature, we have to thin about potential performance issue because to draw bridges we need to known where are the crossing and it might it not correctly implemented have a n^2 complexity with n number of snake lines.

• What is the motivation / use case for changing the behavior?
  Improve diagram readability.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Substation diagram graph can be build only from an IIDM network.

• What is the expected behavior?
  We should be able to easily connect substation diagram to another network model for specific needs. The aim is to move IIDM specific code from Graph and SubstationGraph to another class like

interface GraphBuilder {

    Graph buildVoltageLevel(String id);

    SubstationGraph buildSubstationString id);
}

And having an IIDM implementation:

class NetworkGraphBuilder implement GraphBuilder {
   
   private final Network network;

   ...
}

And also adapt SubstationDiagram and VoltageLevelDiagram to take a GraphBuider and an id to build a diagram.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Probably because of #10 , CGMES substation layout is broken.

2019-12-09_17:04:16.527 [Thread-15] INFO  com.powsybl.sld.SubstationDiagram - Writing SVG and JSON metadata files...
2019-12-09_17:04:16.551 [JavaFX Application Thread] ERROR c.p.s.v.a.AbstractSingleLineDiagramViewer - java.lang.AssertionError: One node must be outside any graph
java.lang.AssertionError: One node must be outside any graph
	at com.powsybl.sld.svg.DefaultSVGWriter.drawSnakeLines(DefaultSVGWriter.java:978)
	at com.powsybl.sld.svg.DefaultSVGWriter.drawSubstation(DefaultSVGWriter.java:398)
	at com.powsybl.sld.svg.DefaultSVGWriter.writegraph(DefaultSVGWriter.java:366)
	at com.powsybl.sld.svg.DefaultSVGWriter.write(DefaultSVGWriter.java:327)
	at com.powsybl.sld.SubstationDiagram.writeSvg(SubstationDiagram.java:122)

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Using the sample of #5

Network network = Importers.loadNetwork("sample.zip");

new LayoutToCgmesExtensionsConverter(new VerticalSubstationLayoutFactory(),
                                                                    new PositionVoltageLevelLayoutFactory(new PositionByClustering()), new LayoutParameters(), true)
                .convertLayout(network);

new CgmesDLExporter(network)
                .exportDLData(new FileDataSource(Paths.get("/tmp"), "sample"));

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  No extra space is left for displaying arrows: they are displayed between feeder and first node/equipment encountered, and often overlap/touch those if there is not enough place.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Display a voltage level with a feeder linked to a bus bar section with two consecutive switches or more, for instance the example in README.md, where some arrows are below switches, or the following:
  

• What is the expected behavior?
  Some space between the arrows and the switch

• What is the motivation / use case for changing the behavior?
  Better looking diagrams

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  API is a little bit complex and could be simplified in most use cases by adding convenient methods with default behaviour.

• What is the expected behavior?
  Instead of:

ComponentLibrary componentLibrary = new ResourcesComponentLibrary("/ConvergenceLibrary");

VoltageLevelLayoutFactory voltageLevelLayoutFactory = new PositionVoltageLevelLayoutFactory(new PositionByClustering());

VoltageLevelDiagram voltageLevelDiagram = VoltageLevelDiagram.build(new NetworkGraphBuilder(network), "C", voltageLevelLayoutFactory, false, false);

voltageLevelDiagram.writeSvg("",
                             new DefaultSVGWriter(componentLibrary, new LayoutParameters()),
                             new DefaultDiagramInitialValueProvider(network),
                             new NominalVoltageDiagramStyleProvider(network),
                             new DefaultNodeLabelConfiguration(componentLibrary),
                             Paths.get("/tmp/c.svg"),
                             false);

We could be able to write:

VoltageLevel vl = ...

ComponentLibrary componentLibrary = ResourcesComponentLibrary.load("ConvergenceLibrary");

VoltageLevelDiagram diagram = VoltageLevelDiagram.of(vl, PositionVoltageLevelLayoutFactory.byClustering());

diagram.writeSvg(componentLibrary, network, Paths.get("/tmp/c.svg"));

• What is the motivation / use case for changing the behavior?
  API simplication for common use cases while keeping the full API for complex use cases (connectrion to other data source that IIDM, custom style, label providers, etc)

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Rendering is done using SVG. With the new zone diagram feature we might have some performance issue when it comes to render very large zones (hundred or thousands of substation).

• What is the expected behavior?
  WebGL is now very well supported by all browsers and rendering performance is far better than with SVG. We could try to re-implement SVGWriter (that should be rename SingleLineDiagramWriter) to generate WebGL code.
  Probably component library will have to be adpated to not only support SVG component providing but also something usable in WebGL.

• What is the motivation / use case for changing the behavior?
  To smoothly render larger zone diagrams.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Even if no DL profile is provided in a cgmes zip, several minutes are spent in DL post processor import.
  See profiling result:
  

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Just use a real large grid, and activate DL post processor.

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Only 2 very simple implementation are available: horizontal and vertical layout.

• What is the expected behavior?
  We should be able to have a smarter substation layout that could be able:

  • To decide the layout direction itself
  • To shift and rotate voltage levels so that there is a minimum of overlapping, transformer crossing.
  • As an option, the layout could decide to change the direction and the order of a feeder if it improves the diagram.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Documentation/Example

• What is the current behavior?
  The is no example of how to create the layout shown on the front page.

It is not possible to create the diagram using the VoltageLevelDiagram as it only visualizes one VoltageLevel pr. diagram.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  It is not a bug, but merely lacking documentation on how to create the diagram shown on the front page.

• What is the expected behavior?
  Better example on how to create the diagram shown on the front page.

• What is the motivation / use case for changing the behavior?
  There should exist documentation on how to create the diagram illustrated on the front page.

• Please tell us about your environment:

  • PowSyBl Version: 3.4.0
  • OS Version: Windows 64

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  LayoutParameters has to be passed to SVGWriter::writeSvg.

• What is the expected behavior?
  A LayoutParameters could be provided in component library (layout-parameters.json) that will be used as default values for layout parameters. Thus, in DefaultSVGWriter we should be able to omit to provide a LayoutParameters in wrteSvg method in the case we don't need to override one of the layout parameters.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Wrong arrows position

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  • Enable straight wire option (LayoutParameters.setDrawStraightWires(true)), for instance in TestSVGWriter tests
    
  • Enable shift feeders option (LayoutParameters.setShiftFeedersPosition(true))
    

• What is the expected behavior?
  Arrows on the wire, lined up with the wire

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  2 and 3 windings representation has been correctly designed for voltage level diagram. With substation diagram (and soon zone diagram), representation looks like a little bit strange as the windings symbole is duplicated at each end of the transformer. Consequently coloration is also very confusing.

Here is an example with a 3 windings transformer but same apply for 2 windings:

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Here is the xiidm sample:

<?xml version="1.0" encoding="UTF-8"?>
<iidm:network xmlns:iidm="http://www.itesla_project.eu/schema/iidm/1_0" id="three-windings-transformer" caseDate="2018-03-05T13:30:30.486+01:00" forecastDistance="0" sourceFormat="test">
    <iidm:substation id="SUBSTATION" country="FR">
        <iidm:voltageLevel id="VL_132" nominalV="132.0" lowVoltageLimit="118.8" highVoltageLimit="145.2" topologyKind="BUS_BREAKER">
            <iidm:busBreakerTopology>
                <iidm:bus id="BUS_132" v="133.584" angle="-9.62"/>
                <iidm:bus id="BUS_133" v="133.584" angle="-9.62"/>
            </iidm:busBreakerTopology>
            <iidm:load id="LOAD_132" loadType="UNDEFINED" p0="7.6" q0="1.6" bus="BUS_132" connectableBus="BUS_132"/>
            <iidm:load id="LOAD_133" loadType="UNDEFINED" p0="7.6" q0="1.6" bus="BUS_133" connectableBus="BUS_133"/>
        </iidm:voltageLevel>
        <iidm:voltageLevel id="VL_33" nominalV="33.0" lowVoltageLimit="29.7" highVoltageLimit="36.3" topologyKind="BUS_BREAKER">
            <iidm:busBreakerTopology>
                <iidm:bus id="BUS_33" v="34.881" angle="-15.24"/>
                <iidm:bus id="BUS_333" v="34.881" angle="-15.24"/>
            </iidm:busBreakerTopology>
            <iidm:load id="LOAD_33" loadType="UNDEFINED" p0="11.2" q0="7.5" bus="BUS_33" connectableBus="BUS_33" p="11.2" q="7.5"/>
            <iidm:load id="LOAD_333" loadType="UNDEFINED" p0="11.2" q0="7.5" bus="BUS_333" connectableBus="BUS_333" p="11.2" q="7.5"/>
        </iidm:voltageLevel>
        <iidm:voltageLevel id="VL_11" nominalV="11.0" lowVoltageLimit="9.9" highVoltageLimit="12.1" topologyKind="BUS_BREAKER">
            <iidm:busBreakerTopology>
                <iidm:bus id="BUS_11" v="11.781" angle="-15.24"/>
                <iidm:bus id="BUS_111" v="11.781" angle="-15.24"/>
            </iidm:busBreakerTopology>
            <iidm:load id="LOAD_11" loadType="UNDEFINED" p0="0.0" q0="-10.6" bus="BUS_11" connectableBus="BUS_11" p="0.0" q="-10.6"/>
            <iidm:shunt id="SELF_11" bPerSection="-0.15" maximumSectionCount="1" currentSectionCount="0" bus="BUS_111" connectableBus="BUS_111" q="-0">
              <property name="qMax" value="-150"/>
            </iidm:shunt>
        </iidm:voltageLevel>
        <iidm:threeWindingsTransformer id="3WT" r1="17.424" x1="1.7424" g1="0.00573921028466483" b1="5.73921028466483E-4" ratedU1="132.0" r2="1.089" x2="0.1089" ratedU2="33.0" r3="0.121" x3="0.0121" ratedU3="11.0" bus1="BUS_132" connectableBus1="BUS_132" voltageLevelId1="VL_132" bus2="BUS_33" connectableBus2="BUS_33" voltageLevelId2="VL_33" bus3="BUS_11" connectableBus3="BUS_11" voltageLevelId3="VL_11">
            <iidm:ratioTapChanger2 lowTapPosition="0" tapPosition="2" loadTapChangingCapabilities="true" regulating="true" targetV="33.0">
                <iidm:terminalRef id="LOAD_33"/>
                <iidm:step r="0.9801" x="0.09801" g="0.08264462809917356" b="0.008264462809917356" rho="0.9"/>
                <iidm:step r="1.089" x="0.1089" g="0.09182736455463728" b="0.009182736455463728" rho="1.0"/>
                <iidm:step r="1.1979" x="0.11979" g="0.10101010101010101" b="0.0101010101010101" rho="1.1"/>
            </iidm:ratioTapChanger2>
            <iidm:ratioTapChanger3 lowTapPosition="0" tapPosition="0" loadTapChangingCapabilities="true" regulating="true" targetV="11.0">
                <iidm:terminalRef id="LOAD_11"/>
                <iidm:step r="0.1089" x="0.01089" g="0.8264462809917356" b="0.08264462809917356" rho="0.9"/>
                <iidm:step r="0.121" x="0.0121" g="0.8264462809917356" b="0.08264462809917356" rho="1.0"/>
                <iidm:step r="0.1331" x="0.01331" g="0.9090909090909092" b="0.09090909090909093" rho="1.1"/>
            </iidm:ratioTapChanger3>
            <iidm:currentLimits1 permanentLimit="1000.0">
                <iidm:temporaryLimit name="20'" acceptableDuration="1200" value="1200.0"/>
                <iidm:temporaryLimit name="10'" acceptableDuration="600" value="1400.0"/>
            </iidm:currentLimits1>
            <iidm:currentLimits2 permanentLimit="100.0">
                <iidm:temporaryLimit name="20'" acceptableDuration="1200" value="120.0"/>
                <iidm:temporaryLimit name="10'" acceptableDuration="600" value="140.0"/>
            </iidm:currentLimits2>
            <iidm:currentLimits3 permanentLimit="10.0">
                <iidm:temporaryLimit name="20'" acceptableDuration="1200" value="12.0"/>
                <iidm:temporaryLimit name="10'" acceptableDuration="600" value="14.0"/>
            </iidm:currentLimits3>
        </iidm:threeWindingsTransformer>
    </iidm:substation>
</iidm:network>

• What is the expected behavior?
  Here is a picture of what should be rendered in substation/zone mode for a 3 windings transformer:

Ideally, we should be able to precise in the component library if a component is a single terminal or multiple terminal and automatically in case of multi-terminal component adapt rendering like in the previous picture. We must not hard coded a specific behaviour for transformers, but be generic for multi terminal components.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  To be consistent with SubstationGraph and soon ZoneGraph we should rename Graph to VoltageLevelGraph.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

It would be nice to be able to add custom SVG around node like labels (for instance to add a lock picture in case of line planned outage)

• Do you want to request a feature or report a bug?
  A feature.

• What is the current behavior?
  Font and background color is hard coded.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?
  To be able to configure background color (hex string) and font in ComponentLibrary using component.css

• What is the motivation / use case for changing the behavior?
  To adapt font and background color to components style.

• Please tell us about your environment:

  • PowSyBl Version: 2.5.0-SNAPSHOT
  • OS Version: Linux

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?
  feature

• What is the current behavior?
  The viewer allows to show one diagram with the set of paramers on the right side.

• What is the expected behavior?
  Having the possibility of displaying the same diagram with different (2 would be probably already enough) sets of parameters.
  One option would be to duplicate into tabs the panel with the layout and parameters.
  More usefull would be to split the screen (vertically as the interesting substation layouts are horizontal) and in the configuration panel having the opportunity to switch between the different configurations

• What is the motivation / use case for changing the behavior?
  testing the rendering with different PositionFinder

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Variable length text is handled in an adhoc fashion

• What is the expected behavior?
  We should define rules to handle text

• What is the motivation / use case for changing the behavior?
  This will bring several benefits:

• reduce the overlapping of text with other elements
• allow to compute the size and aspect ratio of the image without rendering it
• reduce the size of the image

For example, in the following simple voltage level, the long feeder name causes the image to have a large "unused" white zone, or to clip the name.

Note: powsybl/powsybl-incubator#153 is related and tries to handle the specific case of feeder names overlapping. However it doesn't fix the problem of the rightmost feeder name extending out of the image (or forcing the picture to have a bigger width)

Ideas to deal with variable length text are:

• in some places just ignore it, the text is always short
• for longer text, ellipsize it, with variations: ...zz, aaa... , aa..zz , etc
• for longer text where vertical space is available, do line breaking.

This has to be done on a case by case basis.

For example, for hex feeder names, we could ellipsize the middle and center the label around the feeder. This would allow for much tighter bounding boxes:

For the voltage level name, we need to find a strategy too. It could depend on the size of the whole image because the name is written after the image is computed.

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Sometime wires directly connected to a feeder do not start in the right direction. In the following example, all top line feeders start from the left and then go down:

• What is the expected behavior?
  It would be prettier to go straight down.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Here is attached sample.zip, a small 1 substation, 3 voltage level CGMES file, extracted from real data. sample.zip

Using automatic layout without extensions and vertical substation layout we can generate this diagram:

The following code generates using same layout configuration a DL file.

Network network = Importers.loadNetwork("sample.zip");

new LayoutToCgmesExtensionsConverter(new VerticalSubstationLayoutFactory(), new PositionVoltageLevelLayoutFactory(new PositionFree()), new LayoutParameters(), true)
    .convertLayout(network);

new CgmesDLExporter(network)
    .exportDLData(new FileDataSource(Paths.get("/tmp"), "sample"));

Then after adding sample_DL.xml to the original zip, we can generate this diagram using CGMES voltage and substation layout:

I seems that there is a lot of missing data and diagram is not really usable.
Did I missed something in the way I generated the data?
Maybe we introduced a regression in last PR?

• Do you want to request a feature or report a bug?
  Quality

• What is the current behavior?
  Code coverage is 74% which is too low.

• What is the expected behavior?
  We need to add unit tests to reach 80%.

• What is the motivation / use case for changing the behavior?
  Improve robustness.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bad design

• What is the current behavior?
  To support substation diagram SVG customization, CSS classes are added to graph nodes according to a SubstationDiagramStyleProvider implementation. The way it is done is not standard as CSS class name are generared according node ID. So CSS is dependent of a particular substation. Usually, CSS class are "fixed" and not dependent of the SVG content.

• What is the expected behavior?
  CSS should not be generated with the SVG but should be part if the component library and consequently should be the same for all the diagrams. Consequently SubstationDiagramStyleProvider interface should be refactored to no generate CSS but just to add classes to nodes.

Proposition for switches to be able by just adding a closed or open class to top level component tag, to change its state. Using this kind of design we won't be able in the DefaultSVGWriter to dive into internal sub component to change switch state. Same could be done for arrows.

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
    <style><![CDATA[

.BREAKER {
    stroke: rgb(0, 0, 255);
    stroke-width: 2;
    fill: rgb(255, 255, 255);
}

.open .open-switch {
	visibility: visible;
}
.open .closed-switch {
	visibility: hidden;
}
.closed .open-switch {
	visibility: hidden;
}
.closed .closed-switch {
	visibility: visible;
}

]]></style>
    <g>
        <g class="BREAKER closed" id="b" transform="translate(35.0,145.0)">
            <g class="open-switch">
                <rect x="1" width="18" y="1" height="18"/>
                <line y2="15" x1="10" x2="10" y1="5"/>
            </g>
            <g class="closed-switch">
                <rect x="1" width="18" y="1" height="18"/>
                <line y2="10" x1="5" x2="15" y1="10"/>
            </g>
        </g>
    </g>
</svg>

• What is the motivation / use case for changing the behavior?
  To ease the animation od SVG on client side (change coloration, switch position, etc).

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Documentation

• What is the current behavior?
  When writing a new component library, there is a lot of convention that should be used for designing SVG components (like ids of open/close, windings). Also CSS classes that should be supported have to be described.

• What is the expected behavior?
  We must have a markdown document that describe how to create a new component libray what how SVG components have to be designed.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Some substation dot not have any busbar section. To help cell detection algo, fictitious busbar sections are added (see Graph.ensureOneBusInConnectedComponent). Fictitious busbar section are drawn exactly as if it was a real one.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?
  We should hide fictitious busbar section so that diagram looks like exactly as it is in the data model. => feeders connected to a fictitious busbar section should be connected to a single point, like if a fictitious busbar section would be just a fictitious node.

• What is the motivation / use case for changing the behavior?
  We want to faithfully draw substation diagram.

In the Default diagram value provider ("DefaultDiagramInitialValueProvider"), the get initial value method is missing values (P, Q...) for some components as "DanglingLine", can you please set initial values for all components of the same node type (especially for FeederNode).

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  NominalVoltageDiagramStyleProvider does not apply any style to wires and arrows are not displayed correctly when wire is connected to a two windings transformer.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Choose nominal voltage as style provider:

• What is the expected behavior?

Wires should be colored according to the nominal voltage.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  It is not possible to change switch position by clicking on switch object.

• What is the expected behavior?
  In the JavaFX and in Web component it should be possible to add a a listener to the diagram component and to listen for switch position change.

For example in JavaFX:

VoltageLevelDiagramView diagramView = ...
diagramView.addSwitchPositionChangeListener(new SwitchPositionChangeListener() {
    void onPositionChange(String switchId, boolean open) {
         // could be a rest request on server to change the data on server side
    }
})

Same for SubstationDiagramView.

Something similar in ReactJs component.

• What is the motivation / use case for changing the behavior?

Being able to change the topology from diagrams.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  There is 2 component libraries available to style substation diagram:

  • ConvergenceLibrary
  • FlatDesignLibrary

FlatDesignLibrary is not terminated
- there are missing components
- SVG component should be stripped to remove Inkscape metadata (there is an option for that in Inkscape)
- coloration of component is not correct (more or less depending of the style provider)
- we want to develop a "dark variant" of the FlatDesignLibrary with a dark background and adapted component coloration.

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?

The grid is not displayed correctly, using layouts other than Auto* e.g. Random, CGMES.
Apparently, the data needed to create the grid, in the SVG writer, is missing or incorrectly set.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

To illustrate the problem, here below are three screenshots taken from the substation viewer (CGMES network "MiniGrid", NodeBreaker version, selected substation is "Sub4"; network found in powsybl-core's cgmes/cgmes-conformity module).
Note the grid(s) rendered as a couple of small dotted boxes, for the Random and the CGMES layouts (first two pictures) WRT the Auto-without-extensions/Horizontal layout, used in the third image.

Random layout

CGMES layout

Auto-without-extensions layout

• What is the expected behavior?
  the meaning of the expected grid (assuming the "Auto" is the correct rendering) should be better clarified: the meaning of the vertical lines (feeder separator?) and the horizontal lines; also, why a separate grid for each voltage level diagram?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Sonar is not configured to take into account cross module testing like it is in powsybl core repo.

• What is the expected behavior?
  We have to:

  • create a distribution module that contains a dependency to all other modules
  • configure sonar to generate an aggregated report

• What is the motivation / use case for changing the behavior?
  To have real code coverage.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  When there is no value defined for a feeder, arrows up and down are both visibles.

• What is the expected behavior?
  None of the up and down arraw should be visible.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Some diagrams references in the tests display glitches / bugs, hence the corresponding tests probably flag a bug or do not call properly the svg generation (unless the test want to highlight a misuse? but then the tests should be mentionning it)

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  In single-line-diagram-core, open the following files in test/resources: vl1_nominal_voltage_style.svg, vl2_nominal_voltage_style.svg and vl3_nominal_voltage_style.svg.
  
  Everything is displayed in (0, 0).

• What is the expected behavior?
  The reference files in the tests should be corrected: the voltage level should not display everything in (0, 0).

• What is the motivation / use case for changing the behavior?
  The corresponding tests are highlighting a misuse / an issue, and not testing a standard behaviour.

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  Arrows direction is reversed when the first node in a wire is a breaker.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Substation diagram needs to be released on Maven central, so that project can rely on a stable versions.

• What is the expected behavior?
  To reach this we need to work on the following steps:

  • Move substation diagram to its own repo (also move issues and projects)
  • The repo will be named powsybl-single-line-diagram. Single line diagram (SLD) seems to be the most common term (https://en.wikipedia.org/wiki/One-line_diagram).
  • Java package will be com.powybl.sld.
  • All Sonar issues have to fixed
  • Based on powsybl core release (2.7.0?)
  • Remove dependency to powsyb-rte-core and to reach this goal, publish on powsybl-single-line-diagram IIDM extension for position.
  • Release 1.0.0 on Maven central

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Some diagrams references in the tests display glitches / bugs, hence the corresponding tests probably flag a bug or do not call properly the svg generation (unless the test want to highlight a misuse? but then the tests should be mentionning it)

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  In single-line-diagram-core, open the following files in test/resources: substation_no_feeder_values.svg and substation_optimized.svg.
  

They both display wrong anchoring of lines on the 3WT / 2WT (note that there's no problem in substation.svg)

• What is the expected behavior?
  The reference files in the tests should be corrected: lines arriving at 3WT / 2WT should be touching the transformer

• What is the motivation / use case for changing the behavior?
  The corresponding tests are highlighting a misuse / an issue, and not testing a standard behaviour.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  The svgs don't have a viewbox

• What is the expected behavior?
  The svgs should have a viewbox.

• What is the motivation / use case for changing the behavior?
  This allows to give them an aspect ratio and preferred size that so that the client doesn't have to render them to know it. This also allows to have elements at negative coordinates that are displayed in viewers (currently only the voltage level name is like this)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  When we use the shift feeders height functionality, the coordinates of the snake lines (2WT and 3WT) in the substation diagram are incorrect : the line doesn't start from the new node position

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  Start from the new feeder node position when drawing a snake line

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Some diagrams references in the tests display glitches / bugs, hence the corresponding tests probably flag a bug or do not call properly the svg generation (unless the test want to highlight a misuse? but then the tests should be mentionning it)

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  In single-line-diagram-core, open the following files in test/resources: TestCase12GraphWithNodesInfosTopological.svg.
  
  They display a wrong rotation of the 3WT / 2WT.

• What is the expected behavior?
  The reference files in the tests should be corrected: the 3WT/2WT circle linked to a certain line should have the same voltage color.

• What is the motivation / use case for changing the behavior?
  The corresponding tests are highlighting a misuse / an issue, and not testing a standard behaviour.

• Do you want to request a feature or report a bug?

Bug.

• What is the current behavior?

In CGMES import, some switches are imported as lines in IIDM model.
For now, those switches are not displayed in the substation view based on DL file.
How should we handle the DL data for this? Cf. case with HVDC. Maybe flag it with a property ? Need some more analysis and thoughts.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

We should find an acceptable way to display those switches.

• What is the motivation / use case for changing the behavior?

Having an electrically correct representation of those voltage levels.

• Please tell us about your environment:
  PowSyBl Version: 2.4.1

• Do you want to request a feature or report a bug?
  Feature.
  Discussion about his feature has started on powsybl/powsybl-incubator#28.

• What is the current behavior?
  We are able to create voltage level diagram, substation diagram.

• What is the expected behavior?
  We should be able to create zone diagram. A zone is a list of substation, so a zone diagram rely on substation diagrams which itself rely on voltage level diagram. In a zone diagram, substation diagrams are the nodes and lines are connecting nodes.
  We need to improve the data mode by adding a ZoneGraph and LineEdge.
  We need a ZoneDiagramLayout which will support different implementation to support several layout algorithms.
  There is a strong connection between this issue and CGMES DL support as zone diagram will be used to display large DL diagrams.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  When using TopologicalStyleProvider which is based on BaseVoltageColor for base voltage color configuration, an exception is thrown if file is not present in ~/itools.

• What is the expected behavior?
  We could provide a default configuration (in jar resource for instance).

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Substation diagram contains too many Sonar issues (61)...

• What is the expected behavior?
  We must fix as many Sonar issues as possible in the following modules

  • substation-diagram
  • cgmes-dl
  • cgmes-gl

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Condo symbol not touching the line if in top position (MEZE5P7):
  
  Lines over breakers (ALL):
  
  Disconnector shape "\" instead of "/" (MEZE5P7 or .CTLHP3):
  

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Design issue

• What is the current behavior?
  Unit tests have been badly designed. It is not real "unit" test as most of them test the full diagram generation process. Consequently our unit test are hard to maintain and each time we change something in code, we need to regenerate SVG files. Worst, we most of the time regenerate reference SVG files without really looking at them.

• What is the expected behavior?
  We need have real unit tests and not integration tests. I propose the following change.

  • In all different voltage level, substation tests (with small network specially designed for a specific purpose), we should not compare SVG anymore but only the data model (nodes + cells + blocks + coordinates x,y of nodes). We can do that by generating the data model json (here I'am talking about (XXX::writeJson methods, not metadata json!!!!!) and compare to a reference json. So with this change, most of the unit test won't depend anymore of CSS, component library, etc. (remark: it is very likely that the existing data model json export will have to be enriched).

  • The DefaultSVGWriter will be tested on the other side, by creating "by hand" a data model, affecting coordinates and generating a SVG, then comparing with a reference SVG. A few test data models will have to be design to test all the features of DefaultSVGWriter.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  When using TopologicalStyleProvider, buses are colored according a variant around base color (linked to base voltage). But color difference between 2 buses is not really clear.

• What is the expected behavior?
  We should improve algo that generate color around a base color so that the N buses of a voltage level are clearly distinguable.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  Building the voltage level graph, each THREE_WINDINGS_TRANSFORMER feeder node is replaced with a fictitious node and 2 new feeder nodes (please see class com.powsybl.sld.model.Graph, method constructCellForThreeWindingsTransformer). These replacements seems to be necessary for the creation of diagrams at the substation level (please see class com.powsybl.sld.model.SubstationGraph, method addSnakeLines).
  CGMES voltage level layout can set coordinates only of nodes (equipment) belonging to the original network (with data read from CGMES DL profile), so the 3 nodes replacing each THREE_WINDINGS_TRANSFORMER node have no coordinates assigned by the CGMES voltage level layout. In the svg they are all placed with [0, 0] coordinates:
  

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Load the MiniGridTestConfiguration_BC.zip grid in the viewer and select the first substation, the one with 3 voltage levels, selecting CGMES as substation layout, and Diagram as CGMES-DL Diagram (you can reproduce the problem also on the voltage levels of the same substation, choosing CGMES as voltage level layout)

• What is the expected behavior?
  That all the nodes in the graph can have the coordinates correctly assigned:
  

• Do you want to request a feature or report a bug?

Feature

• What is the current behavior?
  none

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  We would like to have the possibility to select and clic those elements:
  -Any single element
  -An entire bay
  -The label

The idea is when the pointer enters in the bay area, the background changes color and is clickable. If the pointer goes over an item the item is selectable (with a graphic animation ?)

Same behavior when you mouse over the label.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  When rendering a voltage level diagram cell height is an input parameter (coming from LayoutParameters and cell blocks are hierarchically rendered inside this pre-defined cell box. There is some limitation to this design:

  • in case of very complex cells (like in some CGMES files) and also in case of a component library with large SVG component (like switches), we could end up with component overlapping.
  • in case of simple voltage levels with simple cells, generated SVG is sub-optimal because there is a lot of wasted space between components.

• What is the expected behavior?
  We should adapt cell height to content. The cell height parameter of LayoutParameter should be replaced by a min and max cell height and cell height should be calculated from graph content. Calculated cell height (one for top and one bottom part of the graph) should be the maximum calculated height of all cells and should also fit into (min, max) value of LayoutParameter. Also LayoutParameter should provide "spacing parameters" like min vertical space between 2 components.

• What is the motivation / use case for changing the behavior?
  To obtain a more compact rendering in some cases and to avoid component overlapping in some other cases.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)