We have had some code in osm2pgsql basically forever that is supposed to handle the case where a (multi)polygon crosses the 180° line (antimeridian).
The idea is as follows: Lets say we have a polygon (like a small island) straddling the 180° line:
```
+---------------------+
| |
| |
|> <|
| |
+---------------------+
```
If we calculate the bounding box by taking the smallest and the largest longitude value for that polygon, we'll get this:
```
+---------------------+
| |
| ___________________ |
|[___________________]|
| |
+---------------------+
```
To detect this, we check the width of the bounding box. If it is larger than half the circumference of the earth, we assume that we have a case like this.
Then we create two bounding boxes, one going from -180° to the left edge of the original bounding box, one from the right edge of the original bounding box to +180° like this:
```
+---------------------+
| |
| |
|] [|
| |
+---------------------+
```
The same code is run for multipolygon relations.
So far, so good. The problem is that this is not how we map things. We don't have polygons crossing the 180° line in OSM, because they lead to all sorts of problems when using the data.
Instead mapping is done using multipolygon relations. The polygon is split into two, one to the left and one to the right of the 180° line.
The effect is that we have two polygons, both touching the 180° line. When we use this algorithm, it calculates the bounding box as going around the whole earth from -180° to +180°, then decides that this is more than half the circumference of the earth, so it creates two new bounding boxes with zero width, one at -180°, one at +180°. That doesn't make any sense.
So this code handles cases we don't have in our current planet file, but does the wrong thing for some cases we do have. It comes from way back, probably before we had relations, we should retire it.
We might still want some checks in the future to catch overlarge bounding boxes to defend against bad edits that will lead to a large number of tiles to be expired, but that is a different issue.
You can view, comment on, or merge this pull request online at:
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2427
-- Commit Summary --
* Remove special case in expire code that doesn't work
-- File Changes --
M src/expire-tiles.cpp (11)
-- Patch Links --
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2427.patch
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2427.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2427
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/pull/2427 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20251029/973f0a3a/attachment.htm>