-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise toc calculation #2047
base: master
Are you sure you want to change the base?
Revise toc calculation #2047
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2047 +/- ##
==========================================
+ Coverage 85.51% 85.62% +0.10%
==========================================
Files 120 120
Lines 5276 5320 +44
==========================================
+ Hits 4512 4555 +43
- Misses 764 765 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
It looks good to me. |
Are the law status already taken into account here? If a theme has plrs "in force" and plrs "changes" the topic is listed twice in the toc of the pdf. |
Yes, the law status is taken into account here:
If a theme has plrs of type inForce and plrs of type changeWithoutPreEffect there are two entries in the extract['ConcernedTheme'] list and therefore are included in the calculation.
|
@michmuel your comment on the daily was correct. the toc calculation is executed before the json is transformed for mapfish_print. Therefore it does not take into account different law_status. I will try to fix this behaviour this afternoon. |
The calculation now takes into account the law_status. The PR can now be tested... |
I tested this branch within our oereb-server. I could not find any parcel, that calculates a wrong toc, thus. |
Same here, the calculation works for us too. 👍 |
total_size = 0 | ||
page_bottom_margin = 20 # toc.jrxml | ||
footer_height = 10 # toc.jrxml | ||
log.debug(f"header total_size: {total_size}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
total_size
is always zero.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well spotted, thanks! I just commited a bugfix.
@voisardf, @peterschaer |
This detail contains the NoData heading ("Öffentlich-rechtliche Eigentumsbeschränkungen, zu denen noch keine Daten vorhanden sind"). |
I selected the wrong lines. I meant these lines: |
This detail contains the names of the topics having no data. It can be empty. |
return x | ||
total_size = 0 | ||
theme_without_data_item_height = 15 # toc.jrxml (12 in themelist.jrxml) | ||
total_size += len( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
total_size should be calculated like this: len(self.extract["ThemeWithoutData"]) * theme_without_data_item_height
Also, the theme_without_data_item_height is 15 only for one entry. 12 is the line height of an individual entry, plus padding. (@voisardf )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a bugfix adressing this. Did I understand it correctly?
@peterschaer @michmuel I checked the templates and found, that some spacings and alignments were (in my opinion) over time not defined as they should have or could have. I adapted them slightly and pushed a draft version to openoereb/pyramid_oereb_mfp#147 |
adresses #2038
I completely reworked the calculation:
@svamaa @michmuel @voisardf @lopo977 could you test with your data?