Data area bounds revisited

Do you remember my earlier post on data area bounds ?

Turns out I was a bit too naive on believing that the largest administrative bounds polygon in an extract always equals what the extract is actually supposed to be containing.

This assumption can be false for many different reasons:

  • there may be a larger admin polygon that just happens to be part of the extract as it intersects with its bounding box, but extends far beyond it
  • the largest polygon may not actually be included as it’s extending beyond the bounding box slightly, e.g. due to the bounding box being based on an older version of this border polygon
  • the extract may just be a real rectangular area extract after all

This sometimes lead to a wrong admin polygon being shown as assumed data bounds, often one that only represents a small subset of the actual data.

So the bounds logic has now been changed to only assume that the largest contained admin polygons bounding box width and height are both witin 75% and 110% of the total data bounding box width and height. Otherwise the bounds shown on the slippy maps will just be that of the full data bounding box.

Form submission switching to multi page format …

I’m not really sure what’s going wrong with it, but apparently the paper layout is sometimes automatically switching to multi page format on submission of single page render requests, and the choice is made “sticky”, too, so the next time you create a map from the same browser multi-page layout is pre-selected.

I’ve experienced that a few times myself now, even with witnesses looking over my shoulder when it happened, but I have no idea by what this may be triggered yet.

Unfortunately I don’t have the time to debug this either right now, but I hopefully will get this tracked down by the end of the week.

Meanwhile, if you are interested, you may subscribe to the related github issue report: