mapproxy-util-autoconfig(1)

πŸ’– mapproxy-util-autoconfig πŸ’–

okay bestie, gather round, because this one is genuinely fun β€” it's the mapproxy-util-autoconfig page from the mapproxy-util-autoconfig(1) manual and it's literally about making MapProxy and MapProxy-seeding configurations out of thin air ✨


🌸 NAME 🌸

mapproxy-util-autoconfig β€” creates MapProxy and MapProxy-seeding configurations 🫢


πŸŽ€ SYNOPSIS πŸŽ€

mapproxy-util autoconfig [OPTIONS]

πŸ¦‹ DESCRIPTION πŸ¦‹

so basically, mapproxy-util autoconfig creates MapProxy and MapProxy-seeding configurations based on WMS capabilities documents that already exist. no cap, it just reads them and ✨generates✨.

It creates a source for each available layer. The source will include a BBOX coverage from the layer extent, legendurl for legend graphics, featureinfo for querlyable layers, scale hints and all detected supported_srs. Then it duplicates the layer tree into the layers section of the MapProxy configuration, including the name, title and abstract. iconic behavior, honestly πŸ’…

The tool will create a cache for each source layer and supported_srs if there is a grid configured in your --base configuration for that SRS. (yes, that's why --base slaps.)

The MapProxy layers will use the caches when available, otherwise they will use the source directly (cascaded WMS). both? both. it's giving resourceful πŸ’β€β™€οΈ

Note πŸ“Œ The tool can help you create new configurations, but it can't predict how you will use the MapProxy services. The generated configuration can be highly inefficient, especially when multiple layers with separate caches are requested at once. Please make sure you understand the configuration and check the documentation for more options that are useful for your use-cases.

like fr fr, read your config before you ship it, that's the vibe check πŸ‘‘


🌈 OPTIONS 🌈

  • --capabilities url|filename β€” URL or filename of the WMS capabilities document. The tool will add REQUEST and SERVICE parameters to the URL as necessary. (it handles that for you, no stress 🫢)
  • --output filename β€” Filename for the created MapProxy configuration.
  • --output-seed filename β€” Filename for the created MapProxy-seeding configuration.
  • --force β€” Overwrite any existing configuration with the same output filename. ⚠️ bye bye old file
  • --base filename β€” Base configuration that should be included in the --output file with the base option.
  • --overwrite filename, --overwrite-seed filename β€” YAML configuration that overwrites configuration options before the generated configuration is written to --output/--output-seed. (this is the main character of the second half of this page, keep reading πŸ’œ)

✨ EXAMPLE ✨

Print configuration on console:

mapproxy-util autoconfig \
    --capabilities http://osm.omniscale.net/proxy/service

Write MapProxy and MapProxy-seeding configuration to files:

mapproxy-util autoconfig \
    --capabilities http://osm.omniscale.net/proxy/service \
    --output mapproxy.yaml \
    --output-seed seed.yaml

Write MapProxy configuration with caches for grids from base.yaml:

mapproxy-util autoconfig \
    --capabilities http://osm.omniscale.net/proxy/service \
    --output mapproxy.yaml \
    --base base.yaml

🧚 OVERWRITES 🧚

It's likely that you need to tweak the created configuration β€” e.g. to define another coverage, disable featureinfo, etc. You can do this by editing the output file of course, or you can modify the output by defining all changes to an overwrite file. Overwrite files are applied every time you call mapproxy-util autoconfig. every single time, bestie, it's a whole lifestyle πŸ”

Overwrites are YAML files that will be merged with the created configuration file.

The overwrites are applied independently for each services, sources, caches and layers section. That means, for example, that you can modify the supported_srs of a source and the tool will use the updated SRS list to decide which caches will be configured for that source. the way it just knows πŸ˜­πŸ’–

✨ EXAMPLE ✨

Created configuration:

sources:
  mysource_wms:
    type: wms
    req:
        url: http://example.org
        layers: a

Overwrite file:

sources:
  mysource_wms:
    supported_srs: ['EPSG:4326'] # add new value for mysource_wms
    req:
        layers: a,b  # overwrite existing value
        custom_param: 42  #  new value

Actual configuration written to --output:

sources:
  mysource_wms:
    type: wms
    supported_srs: ['EPSG:4326']
    req:
        url: http://example.org
        layers: a,b
        custom_param: 42

ate. no crumbs left 🍽️✨

πŸ’… SPECIAL KEYS πŸ’…

There are a few special keys that you can use in your overwrite file. these are the secret menu items, iykyk 🀫

  • All β€” The value of the __all__ key will be merged into all dictionaries. The following overwrite will add sessionid to the req options of all sources:
sources:
  __all__:
    req:
      sessionid: 123456789
  • Extend β€” The values of keys ending with __extend__ will be added to existing lists.

To add another SRS for one source:

sources:
    my_wms:
      supported_srs__extend__: ['EPSG:31467']
  • Wildcard β€” The values of keys starting or ending with three underscores (___) will be merged with values where the key matches the suffix or prefix.

For example, to set levels for osm_webmercator and aerial_webmercator and to set refresh_before for osm_webmercator and osm_utm32:

seeds:
    ____webmercator:
        levels:
          from: 0
          to: 12

    osm____:
        refresh_before:
            days: 5

and that's the whole page, babe!! πŸŽ€ mapproxy-util-autoconfig(1) β€” this is the 17 July 2026 edition, straight out of the mapproxy-util-autoconfig manual. go forth and autoconfig, you absolute legend πŸ‘‘πŸ’…βœ¨

πŸ“¦ where this page comes from