search

openoereb / pyramid_oereb

pyramid_oereb is an open-source implementation of the server side part for the Swiss "Cadastre of Public-law Restrictions on landownership" (PLR-cadastre).
Other
8 stars 23 forks source link

TOC - review calculation #2038

Open svamaa opened 2 months ago

peterschaer commented 2 months ago

This issue is about checking the calculation of the size of the table of contents (i.e. number of pages) made in https://github.com/openoereb/pyramid_oereb/blob/ec86cb5af4671edd850d5a26c37b5c71dc03ad3b/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py#L8 The number of pages that the table of contents needs is used in mapfish_print.py to be compared with the actual length of the table of contents in the PDF. If the two numbers do not match, the PDF is created a second time to correct the page numbers in the table of contents. The most accurate calculation possible prevents the PDF from being created a second time and therefore increases performance.

peterschaer commented 2 months ago

First of all, I looked at some parcels in the canton of Bern to see whether the PDF would be generated a second time. I looked at the following examples:

In all these cases, the length of the TOC is two pages. In no case will the PDF be generated a second time. In our current constellation, there is no plot in the canton of Bern that generates a table of contents of more than two pages, so that in our case at least, the PDF is only ever generated once.

@svamaa @michmuel @voisardf @lopo977 Are there examples in your cantons where the PDF is generated twice? I can't really test this from the outside.

lopo977 commented 2 months ago

First of all, I looked at some parcels in the canton of Bern to see whether the PDF would be generated a second time. I looked at the following examples:

* Parcel with only one topic: https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368946357207&lang=de

* Parcel with two hits (but 3 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH743546874207&lang=de

* Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368746359439&lang=de

* Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH643546232754&lang=de

In all these cases, the length of the TOC is two pages. In no case will the PDF be generated a second time. In our current constellation, there is no plot in the canton of Bern that generates a table of contents of more than two pages, so that in our case at least, the PDF is only ever generated once.

@svamaa @michmuel @voisardf @lopo977 Are there examples in your cantons where the PDF is generated twice? I can't really test this from the outside.

In Tessin, both in the worst and best case, we have a table of contents of 2 pages. There is also no parcel that generates a table of contents of more than two pages

svamaa commented 2 months ago

Extracts with wrong calculation (results in second print request):

https://api.oereb.bs.ch/extract/pdf/?EGRID=CH198970136775 https://api.oereb.bs.ch/extract/pdf/?EGRID=CH516710897827 (only one theme concerned)

We always have 2 pages table of contents. But I could not find a case where the calculation was correct.

michmuel commented 2 months ago

PDF computation in BL:

voisardf commented 2 months ago

Computation of the TOC length is mostly incorrect in our case. One of the few examples it is ok:

2 calls:

In our case, as soon as there are two concerned themes (which is the default for us) and the title for restrictions touching the real estate needs two lines, the computation is wrong by default.

My best guess would be that we need to also calculate the wrapped text length for the concerned themes header, as depending on the municipality name and the 'Grundbuchkreis' there is a line break leading to a wrong computation. An other guess would be that the default height of one of the elements changed and was not adapted accordingly in the computation. - I need to check that in the templates

peterschaer commented 2 months ago

In my opinion there are several issues with the calculation:

  1. Line Breaks in the concerned themes header are not taken into account by the calculation (as mentionned by @voisardf )
  2. the calculation does not include the qr code block. This is mentionned as a TODO in the code: https://github.com/openoereb/pyramid_oereb/blob/ec86cb5af4671edd850d5a26c37b5c71dc03ad3b/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py#L61)
  3. The whole block of text (including general information, disclaimers and qr code) is not allowed to have a page break (according to the spec). The calculation does not take this into account. There will be many cases where the calculation comes to the conclusion that the TOC only has one page. In the PDF, however, there are two pages because this text block may not be wrapped and is placed on a new page.
  4. There are some small differences in the item heights between the templates and the calculation code. I will put them together.
voisardf commented 2 months ago

thanks @peterschaer

I opened the template and can already confirm the first point: d1 is set to a fixed height of 77px in the computation though it should also be computed.

Here are the screen shots of the template allowing also a better understanding of the code in https://github.com/openoereb/pyramid_oereb/blob/ec86cb5af4671edd850d5a26c37b5c71dc03ad3b/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py

One real estate info line in d1: TOC_default_1line_for_d1_77px

Two real estate info lines in d1: TOC_with_2lines_for_d1_85px

In conclusion: d1 should also be computed using the compute_length_of_wrapped_text function

For point 2: QR-Code height is 56px by default

michmuel commented 2 months ago

Thanks @peterschaer for updating the branch. I think we will be able to narrow down the remaining issues next week.

Here some information from the logs from BL using the latest version:

michmuel commented 2 months ago

Are topMargin and bottomMargin possibly relevant as well (just a thought)? https://github.com/openoereb/pyramid_oereb_mfp/blob/8d9da5ab3a8d1a8469fd693e4f86c5870ee9f6dc/print-apps/oereb/toc.jrxml#L3

peterschaer commented 2 months ago

Yes, topMargin and bottomMargin are relevant but not yet included in the calculation. Thanks for the hint.

I included those two values. Could you test again?

michmuel commented 1 month ago

Now, it is close. One example misses the correct value (one or two pages) by 2.

These (<box bottomPadding="">) are not relevant in any case?