[MapProxy-dev] Contributing to MapProxy
Hannes Blitza
blitza at terrestris.de
Thu Feb 15 05:46:31 PST 2024
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>
More information about the MapProxy-dev
mailing list