Open imagico opened 4 hours ago
Just a quick note: A reimport is not strictly necessary for the changes in #4978. The database is compatible enough that you can keep updating an old database. That being said, occasional reimports are useful anyway due to database bloat.
And at some point a reimport has to be done, because of other changes in osm2pgsql. Since osm2pgsql 2.0.0 the old middle database format (and some other stuff) is not supported any more. For details see the osm2pgsql release notes and docs.
Yes, i should probably have explained that more explicitly. As per our README we do a new major release based on:
Any change the requires reloading a database, or upgrading software dependencies will trigger a major version change
If we decide to not have any database structure changes beyond #4978 we can mention in our release notes that a database reload is not strictly required. I would assume that most users of the style will do a reload anyway though - hence it is a good opportunity to do some adjustments we'd want to do anyway.
There are a number of things that should be looked up after merging #4978. Since we are going to require deployments to re-import their rendering database it is a good idea to look at a number of things that can only be changed with a re-import of the data. These should best be done before the next release. Others are more long term strategic changes that are facilitated by the flex backend. For those it is more important to thoroughly consider and plan them rather than to rush to have them in this release.
ignore_keys
andignore_key_prefixes
list regarding which might have largely vanished from the database in the meantime (so can be removed) and what new metadata tags might have been added to the database in larger numbers that we might want to add there.roads_info
table with the z-order values #4431 had addedbusway
there - which might be a good idea to pre-emptively add in case we decide to render those in some form.waterway
here - defaulting to linestring and listing exceptions for certain values to default to polygon. If we want to integrate that change we should take a careful look at what values should default to polygon. #4431 misseswaterway=dam
here - which is widely used on closed ways representing polygons.foot
,bicycle
andhorse
in context of the access restrictions rendering work. Because this affects backwards compatibility (see https://github.com/gravitystorm/openstreetmap-carto/pull/4978#issuecomment-2424799901) we should discuss this as a separate issue. This can be - but does not have to be - part of the next release.planet_osm_roads
table. #4431 demonstrated a method to connect the individual ways ad hoc on a per-tile basis. That is not without issues, in particular discontinuities across tile boundaries and potential performance implications. But is is a method that can be employed ad hoc and that avoids the current white line + comp-op: darken technique (which is somewhat awkward and causes artefacts). It does not solve our long standing issue of low zoom admin boundary rendering (#2172) or facilitating reducing the visual noise at the mid to low zoom levels by removing geometric and topological details.way_length
column onplanet_osm_line
in analogy toway_area
for polygons. A concrete approach how to do such things needs to be developed and discussed. Also this approach would call for moving the z-order calculation out of the import process. We would need to discuss if we want to do that - and if yes: how to implement that at render time instead.planet_osm_polygon
and have a separate buildings table with very few columns. For any such idea we would need to carefully evaluate the benefit this has under the goals of OSM-Carto.planet_osm_roads
table - this is connected to the previous item and the administrative boundary strategy.