From blitza at terrestris.de  Thu Feb 15 05:46:31 2024
From: blitza at terrestris.de (Hannes Blitza)
Date: Thu, 15 Feb 2024 14:46:31 +0100
Subject: [MapProxy-dev] Contributing to MapProxy
In-Reply-To: <8017c4a5-e66f-e80b-588c-837652d81a42@terrestris.de>
References: <CAFWXLWUxYH_Uu8is5ZJ5=arZoYrM-i1+ZNjBmTPG=cz4U2uXoA@mail.gmail.com>
 <8017c4a5-e66f-e80b-588c-837652d81a42@terrestris.de>
Message-ID: <c67d6d33-763f-4cde-8271-287e1a504606@terrestris.de>

Hi,

as a result of this thread we had a discussion at terrestris and started 
with some work (thanks Simon Seyock) and thoughts that are documented 
right in the discussions board on github:

https://github.com/mapproxy/mapproxy/discussions/890

So we can easily link with the discussion board at pygeoapi 
(https://github.com/geopython/pygeoapi/discussions).

Please feel free to engage and add up to the discussion.

Best, Hannes


>
> -------- Weitergeleitete Nachricht --------
> Betreff: 	Re: [MapProxy-dev] Contributing to MapProxy
> Datum: 	Sat, 2 Dec 2023 07:49:46 -0500
> Von: 	Tom Kralidis <tomkralidis at gmail.com>
> An: 	Johannes Weskamm <weskamm at terrestris.de>
> Kopie (CC): 	mapproxy-dev <mapproxy-dev at lists.osgeo.org>
>
>
>
> 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.gpkgoptions:
>>     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 <mailto:alistaire at met.no>
>>>>
>>>>         *Meteorologisk Institutt*,
>>>>         Henrik Mohns plass 1,
>>>>         0313 Oslo
>>>>
>>>>
>>>>         _______________________________________________
>>>>         MapProxy-dev mailing list
>>>>         MapProxy-dev at lists.osgeo.org
>>>>         https://lists.osgeo.org/mailman/listinfo/mapproxy-dev
>>
>>         -- 
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy-dev/attachments/20240215/b0eac705/attachment-0001.htm>