Cse valid/glsk merged #92
Conversation
b1b2bc7 to
7cf275b
Compare
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
…outarea countries Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
7cf275b to
2689b5a
Compare
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
| private static Map<String, List<GlskPoint>> getGlskPointsFromTimeSeries(List<TimeSeriesType> timeSeries) { | ||
| Map<String, List<GlskPoint>> cseGlskPoints = new TreeMap<>(); | ||
| if (timeSeries == null) { | ||
| return cseGlskPoints; |
There was a problem hiding this comment.
should a warning be logged / an exception be thrown here?
There was a problem hiding this comment.
An exception, I'm sure not.
A warning, not sure if it is useful or not... Theoretically the timeSeries variable here should never be null, as we check in CseGlskDocumentImporter.canImport() method that the document contains at least one element named . It could possibly be null for timeSeriesExport, if no markup exists in the document. But it will happen for every "standard" GLSK file handling (I mean here, no Export Corner handling), so I don't think we need to warn the user systematically.
| } | ||
|
|
||
| private static Map<String, List<GlskPoint>> getGlskPointsFromTimeSeries(List<TimeSeriesType> timeSeries) { | ||
| Map<String, List<GlskPoint>> cseGlskPoints = new TreeMap<>(); |
There was a problem hiding this comment.
maybe you could rename it to cseGlskPointsPerArea
|
|
||
| private static final List<Class<?>> STANDARD_BLOCK_CLASSES = List.of(ManualGSKBlockType.class, PropGSKBlockType.class, PropLSKBlockType.class, ReserveGSKBlockType.class); | ||
|
|
||
| public CseGlskPoint(TimeSeriesType timeSerie) { |
There was a problem hiding this comment.
timeSeries* (singular is series, which can make devs a bit confusing i guess)
| String italyEIC = new CountryEICode(Country.IT).getCode(); | ||
| List<String> countriesInArea = new ArrayList<>(); | ||
| List<String> countriesOutArea = new ArrayList<>(); | ||
|
|
||
| calculationDirections.stream() | ||
| .map(cd -> cd.getInArea().getV()) | ||
| .filter(countryEIC -> !countryEIC.equals(italyEIC)) | ||
| .forEach(countriesInArea::add); | ||
|
|
||
| countriesInArea.add(italyEIC); | ||
|
|
||
| calculationDirections.stream() | ||
| .map(cd -> cd.getOutArea().getV()) | ||
| .filter(countryEIC -> !countryEIC.equals(italyEIC)) | ||
| .forEach(countriesOutArea::add); | ||
|
|
||
| return Map.of(COUNTRIES_IN_AREA_KEY, countriesInArea, | ||
| COUNTRIES_OUT_AREA_KEY, countriesOutArea); |
There was a problem hiding this comment.
why is Italy a special case?
There was a problem hiding this comment.
For Export Corner developments, the CalculationDirections (representing which countries have activated Export Corner excahnges or not) should contain only directions from a country to Italy or vice-versa. E.g.: {InArea: France, OutArea: Italy} if France has activated Export Corner exchanges, or {InArea: Italy, OutArea: France} if France has not activated Export Corner exchanges.
There is no sense to put {InArea: Italy, OutArea: Italy} because no exchange is made from Italy to itself.
But we need to handle Italy because we need to retrieve its TimeSeries. As the rules for Italy (concerning TimeSeries retrieval) are the same as the rules for countries having activated Export Corner exchanges, I decided to put it in the countriesInArea List.
Signed-off-by: Vincent BOCHET <vincent.bochet@rte-france.com>
|
Kudos, SonarCloud Quality Gate passed! |
Please check if the PR fulfills these requirements (please use
'[x]'to check the checkboxes, or submit the PR and then click the checkboxes)Does this PR already have an issue describing the problem ? If so, link to this issue using
'#XXX'and skip the restWhat kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change or deprecate an API? If yes, check the following:
Other information:
(if any of the questions/checkboxes don't apply, please delete them entirely)