[MapProxy-dev] Contributing to MapProxy

Sat Dec 2 04:49:46 PST 2023

Hi Johannes: correct, that will also work in terms of a bridging
mechanism.  A WMTSFacade would be valuable in this regard.

As an example, we implemented both options for OGC API - Maps support in
pygeoapi, i.e. a WMSFacade as a bridging mechanism, and a MapServer
MapScript provider which talks directly to MapServer's
libraries to generate a map.

I think both options are valuable and viable for the different use cases.

Thanks

..Tom

On Fri, Nov 24, 2023 at 8:42 AM Johannes Weskamm <weskamm at terrestris.de>
wrote:

> Hi Tom,
>
> Ah thats another option you mention, did not even think about that.
>
> Right, one could add, for example, an mbtiles provider for API Tiles, that
> reads the cache generated by mapproxy directly, without talking to mapproxy.
>
> But my thoughts now are to use the existing endpoints of mapproxy for
> that, so that features like "lazy-caching" will still work. We e.g. have
> TMS and WMTS endpoints in mapproxy which serve the data tiled (x/y/z like)-
>
> I think it would be nice to have support on the side of pygeoapi for WMTS
> or TMS Services which could then be accessed via OGC API Tiles.
>
> Not sure if i have a correct understanding here, but that way pygeoapi
> would not have to bother with different tile storage formats and instead
> talk via the "old" standards with the sources, similar as the "WMSFacade"
> already does.
>
>
> What do you think?
>
>
> Greetings,
>
> Johannes
>
>
> Am 24.11.23 um 13:24 schrieb Tom Kralidis:
>
> Johannes: thanks for this analysis, good ideas here!
>
> If I understand correctly, this means that a MapProxy cache is already
> seeded, and a pygeoapi MapProxy tile provider would translate the OGC API -
> Tiles requests into the given MapProxy cache.
>
> pygeoapi could then define such a provider with:
>
> providers:    - type: tile      name: MapProxyCache      data: /path/to/cache.gpkg
>       options:          metadata_format: default          zoom:              min: 0              max: 5          schemes:              - WorldCRS84Quad
>           type: geopackage
>           table_name: tiles_table      format:          name: png          mimetype: image/png
>
>
> Another interesting option would be to have a pygeoapi MapProxy
> lazy-caching option (where tiles are generated as needed).  Of course, this
> would require more configuration on the underlying service(s) to be cached
> by MapProxy.
>
> Thanks
>
> ..Tom
>
>
> On Fri, Nov 24, 2023 at 4:02 AM Johannes Weskamm via MapProxy-dev <
> mapproxy-dev at lists.osgeo.org> wrote:
>
>> Hi,
>>
>> So here are my first findings on the topic of OGC API and pygeoapi.
>>
>> You can already publish cached WMS that come from MapProxy through
>> pygeoapi via OGC API Map (
>> https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-maps.html).
>>
>> I think that is a bit inefficient, as OGC API Tiles could potentially
>> access the tiles directly as they have been stored in the chosen MapProxy
>> backend (mbtiles, files, ...).
>>
>> So in order to avoid the image assembling and rescaling in mapproxy (and
>> do it in the client instead, which may not perform better, maybe even
>> worse), support for those tile backends need to be implemented in pygeoapi.
>>
>> Currently the only provider for OGC API Tiles in pygeoapi seems to be the
>> MVT-Provider, which obviously does not work with mapproxy. So a provider /
>> reader like mbtiles, xyz structures or similar for non vector data needs to
>> be implemented. Some things do exists in pygeoapi which should help to get
>> on the train quickly.
>>
>> I think that an implementation in pygeoapi would solve your needs most
>> efficient.
>>
>> Afterwards we could provide documentation and examples how to use
>> MapProxy and pygeoapi together to be OGC-API comaptible.
>>
>> My 2 cents,
>>
>> Greetings,
>>
>> Johannes
>>
>>
>> Am 22.11.23 um 16:18 schrieb Johannes Weskamm:
>>
>> Hi,
>>
>> This sounds very good in my opinion! Having OGC API Support in MapProxy
>> would be a really nice feature and enable MapProxy to catch up with the
>> future of OGC Standards.
>>
>> In general, Pull Request are always welcome and the features you
>> mentioned sound interesting, so i see no obvious reasons that would block
>> your contributions.
>>
>> Some bigger goals, like OGC API Support, would need some discussion
>> before starting with development. Before reinventing the wheel one should
>> examine what pygeoapi has to offer.
>>
>> The current documentation (
>> https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-tiles.html)
>> even mentions MapProxy as a possible data source, but the examples are
>> lacking, so i am not sure if support already exists or needs to be done.
>> But even if its still missing, i guess it would be the more elegant way to
>> use pygeoapi together with mapproxy or implement and extend the relevant
>> classes, as the main thing is already done in pygeoapi and updated
>> regularly.
>>
>>
>> I may find some time in the upcoming weeks to shed some more light on
>> that.
>>
>> I am also interested what other people think about that.
>>
>>
>> Greetings,
>>
>> Johannes
>>
>>
>>
>> Am 13.11.23 um 09:52 schrieb Alistair Everett via MapProxy-dev:
>>
>>
>> Hi all,
>>
>> At the Norwegian Meteorological Institute we're considering using
>> MapProxy to provide model and other map based data to some of our frontend
>> services. I'm aware we've been somewhat involved with MapProxy before and
>> used it for some of our services, unfortunately most of those involved
>> aren't working here anymore so we're looking at building from scratch and
>> modernising our services. First with a new WMS offering, but we would also
>> like to be able to provide OGC API endpoints in the future.
>>
>> There are a couple of features which we would be interested in having in
>> MapProxy, particularly related to dimensions - for example, other forms of
>> caching (S3 and mbtiles), seeding, and potentially reading available
>> dimensions from WMS sources. I know some of these features are available as
>> standard but I believe they currently don't necessarily work with
>> dimensions. As part of this project I'm hoping that we will have some
>> developer time to put into this, so I'm interested in hearing what the
>> community thinks of this, how it might fit in with any roadmap the MapProxy
>> community might already have, and if you are open to us submitting our own
>> MRs for these features?
>>
>> I'm also interested in what the community thinks of OGC-API endpoints, do
>> you see this as something which MapProxy would like to offer, if the
>> resources were available to develop it? Or do you see this as something
>> which would rather be offered through other packages, for example pygeoapi
>> with MapProxy providing a tile cache in the background?
>>
>> Interested to hear your thoughts,
>>
>> Kind regards,
>> Alistair
>>
>> --------------
>> *Dr Alistair Everett*
>> Senioringeniør / Senior Software Engineer
>> Avdeling for Geoutvikling
>>
>> *Phone:* +47 939 68 985
>> *Email:* alistair.everett at met.no <alistaire at met.no>
>>
>> *Meteorologisk Institutt*,
>> Henrik Mohns plass 1,
>> 0313 Oslo
>>
>>
>> _______________________________________________
>> MapProxy-dev mailing listMapProxy-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapproxy-dev
>>
>> --
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy-dev/attachments/20231202/aeb41bd1/attachment.htm>