You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems the automatic bbox boundary computation is frequently causes slowdowns on startup, and confusion among novice users. I personally also experienced it. Let's make bounds computation disabled by default.
Changes
Add a new --bounds enum config option with values none (default) and auto. TBD: Should it be full, world, all or planet instead of none?
Remove --disable_bounds option, or at least make it deprecated for now, and prevent its usage at the same time as --bounds
Config should also support the same values, e.g. bounds: auto in addition to bounds: [-180,-90,180,90]
Config should obsolete the disabled_bounds and instead add a bounds value to the auto_publish.tables section - from PgConfig to PgCfgPublishType
I think we should also move default_srid, max_feature_count to the auto_publish.tables section.
To consider
It might be good to do asynchronous bounds computation, where it gets done after Martin startup, and initially Martin uses full bounds until the computation is done... This might be a lot trickier though, because we will need to modify how all sources are stored and updated. At the moment, all sources are immutable and exist for the entire duration of the program, but this may change as part of the source auto-refresh work (ability to re-query the database to add new sources on the fly #288)
* Remove `--disable-bounds` flag and `disable_bounds` config parameters.
* Add `--auto-bounds` / `-b` CLI parameter and `auto_bounds` config
value:
* `quick`: Compute table geometry bounds, but abort if it takes longer
than 5 seconds (default)
* `calc`: Compute table geometry bounds. The startup time may be
significant. Make sure all GEO columns have indexes
* `skip`: Skip bounds calculation. The bounds will be set to the whole
world
* `-b` is now mapped to `--auto-bounds` param, but it will fail if used
by itself because it now requires a value.
Fixes#955
It seems the automatic bbox boundary computation is frequently causes slowdowns on startup, and confusion among novice users. I personally also experienced it. Let's make bounds computation disabled by default.
Changes
--bounds
enum config option with valuesnone
(default) andauto
. TBD: Should it befull
,world
,all
orplanet
instead ofnone
?--disable_bounds
option, or at least make it deprecated for now, and prevent its usage at the same time as--bounds
bounds: auto
in addition tobounds: [-180,-90,180,90]
disabled_bounds
and instead add abounds
value to theauto_publish.tables
section - fromPgConfig
toPgCfgPublishType
default_srid
,max_feature_count
to theauto_publish.tables
section.To consider
It might be good to do asynchronous bounds computation, where it gets done after Martin startup, and initially Martin uses full bounds until the computation is done... This might be a lot trickier though, because we will need to modify how all sources are stored and updated. At the moment, all sources are immutable and exist for the entire duration of the program, but this may change as part of the source auto-refresh work (ability to re-query the database to add new sources on the fly #288)
See also:
The text was updated successfully, but these errors were encountered: