Planning for backwards incompatible changes

[joto]

At some point in the not too far future (not the next version as I write this) we want to make a backwards incompatible change to the pgsql middle which means everybody has to do a re-import. If we have a breaking change anyway, this might be the chance to do some other changes, too. This issue is here to collect the different things we might want do, see individual issues for discussions and details.

Planned or possible changes:

• [X] Format of the database middle tables changes. (See #1384)
• [X] Change default value for --cache/-C parameter? (See #1501) -> Default is okay, still works for small OSM files.

Are there some other things "we always wanted to do" but didn't for compatibility?

[joto]

Just to make this clear: There is no decision yet how to make this backwards incompatible change. It might be possible to do some kind of phased change over a longer time. But that has some cost (mainly in development time), too. So maybe a clear breaking change is better. But to figure this out it is good to collect ideas how such a change could look and what else we might want to do. That's why I created this issue.

[joto]

• [X] Removal of gazetteer. Already deprecated in 1.8.0. (See #1870).
• [X] Removal of --with-forward-dependencies. Already deprecated in 1.8.0. (See #1870).
• [X] Flex Lua command add_row() will at some point be deprecated/removed in favour of insert(), no schedule for this yet.
• [X] The --cache-strategy options has been marked as deprecated since 1.5.0. It just shows a warning since then. Should be completely removed.

[joto]

• [X] Remove area column type in flex output. It only works with add_row(), not with insert().
• [X] From 1.9.0 expire configuration for the flex output will be done in the Lua config file, but the old command line options are (as I write this) still supported. We might want to change this. The command line options are: -e, --expire-tiles, -o, --expire-output, and --expire-bbox-size. -> We keep this for the time being. The pgsql backend still needs this so it would only be a minor simplification for us.
• [X] Do we want to remove support for the non-bucket way-node-index in the middle? -> Yes, it was removed.
• [X] Do we want to rename the middle tables in the new middle? -> No
• [X] pole_of_inaccessibility() is currently still marked as experimental. -> Not marked as experimental any more in v2.
• [X] Generalization support is currently still marked as experimental. -> Should stay that way.

[joto]

It is unclear how the -b, --bbox option is supposed to work and how well it works, especially with updates. There are better solutions. i.e. creating an extract first and feeding that to osm2pgsql.

Maybe it is time to get rid of it.

Anybody using this option?

• [X] Remove it? -> No, we don't have a better solution that works with osm2pgsql only.

[joto]

Not really a compatibility problem but fits in here: We currently have a limit of 32767 members per relation (enforced in https://github.com/openstreetmap/osm2pgsql/blob/master/src/osmdata.cpp#L119-L124) due to #713. The new middle doesn't have this problem any more. In addition the API has now a limit of 32000 members per relation, so this shouldn't be a problem in the future.

• [ ] Should we remove this check?

[joto]

We can probably remove support for Proj4 soon. Ubuntu 18.04 has reached EOL in April 2023, it was the last major distribution we might care about still using a version 4 proj. Debian 10 (Buster) uses version 5 which is EOL sometime in 2024, everybody else uses 6 or above.

• [X] Support for Proj4 has been removed.

[joto]

There are many command line option combinations which make no sense and should be illegal. I am currently working on creating warnings for many of them. Eventually these warnings should be turned into errors.

• [X] Warnings and sometimes errors are generated now.