<div dir="ltr"><div><span style="box-sizing:border-box">I had a chance to take a look at the code developed by </span>Even and I do agree that it is too specific to be added to MapProxy master.</div><div><span style="box-sizing:border-box">It</span> <span style="box-sizing:border-box">would</span> <span style="box-sizing:border-box">be</span> <span style="box-sizing:border-box">great</span> <span style="box-sizing:border-box">to</span> <span style="box-sizing:border-box">add a plugin infrastructure to MapProxy for such use cases.</span><br></div><div><span style="box-sizing:border-box"><br></span></div><div>+1<br></div><div><br></div><div>Denis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 22, 2022 at 1:52 PM Johannes Weskamm <<a href="mailto:weskamm@terrestris.de">weskamm@terrestris.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Even and PSC members,<br>
<br>
<br>
I am forwarding this email to the dev list as changes / features like<br>
these need to be voted on by the PSC.<br>
<br>
When it comes to the conclusion that things get integrated in mapproxy,<br>
me and the PSC of course can review the code.<br>
<br>
@PSC:<br>
<br>
Please read through the mail below and provide your thoughts and votes<br>
regarding the general idea of having a plugin system in mapproxy.<br>
<br>
I think the technical details need to be discussed afterwards on this list.<br>
<br>
<br>
Greetings,<br>
<br>
Johannes Weskamm<br>
<br>
<br>
<br>
<br>
<br>
-------- Weitergeleitete Nachricht -------<br>
<br>
Hello,<br>
<br>
I don't think we've already met before, so let me introduce quickly. I'm<br>
Even Rouault, the lead developer of GDAL/OGR and owner of a small<br>
consultancy in France, Spatialys (<a href="http://www.spatialys.com/en/about/" rel="noreferrer" target="_blank">http://www.spatialys.com/en/about/</a>).<br>
<br>
Recently I've done an exploratory work for CNES to add new capabilities<br>
to MapProxy, to add the support for a new standard, called HIPS, used by<br>
the planetology and astronomy communities, as a MapProxy source and<br>
service, and bridging with the traditional OGC protocols (WMS, WMTS...):<br>
that is e.g. exposing a WMS source as a HIPS service, and vice-verca.<br>
The sponsor has presented a bit this context in<br>
<a href="https://lists.osgeo.org/pipermail/mapproxy-dev/2022-March/000039.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/mapproxy-dev/2022-March/000039.html</a> .<br>
<br>
This work has been done in a branch forked from MapProxy master and<br>
which lives at <a href="https://github.com/rouault/mapproxy/tree/hips" rel="noreferrer" target="_blank">https://github.com/rouault/mapproxy/tree/hips</a><br>
<br>
We acknowledge that the field domain of HIPS is probably too specific to<br>
gain enthusiasm for the overall MapProxy community to be merged into<br>
MapProxy master. So I was thinking that one way of solving this would be<br>
to put the HIPS specific code in a separate Python project, that would<br>
be managed outside of the MapProxy community. To do so, we need first to<br>
add to MapProxy capabilities of handling plugins, as unless I've missed<br>
something, this is not available currently. That is when MapProxy sees<br>
in its configuration file a service type or source type, it doesn't<br>
handle, it would query registered plugins and delegate to them. We would<br>
need plugin capabilities to also handle add new entries in the /demo<br>
service as well, and register new commands to mapproxy-util.<br>
<br>
It looks like you're one of the currently active developers of MapProxy,<br>
so I was wondering if, assuming you think it would be a good idea and an<br>
accepted approach, you would be interested in:<br>
<br>
a) either reviewing and merging future code I would develop to add such<br>
plugin infrastructure to MapProxy that I would develop (the way that<br>
pytest uses a dedicated entry_point to register a plugin to pytest core<br>
seemed an interesting idea to borrow:<br>
<a href="https://docs.pytest.org/en/6.2.x/writing_plugins.html#making-your-plugin-installable-by-others" rel="noreferrer" target="_blank">https://docs.pytest.org/en/6.2.x/writing_plugins.html#making-your-plugin-installable-by-others</a>)<br>
<br>
b) or do that work yourself<br>
<br>
and what the associated cost would be.<br>
<br>
In either case, the creation of the mapproxy-hips plugin itself would<br>
remain on my side.<br>
<br>
Option a) would have my slight preference given that it would minimize<br>
back-and-forth interaction and I could make sure that the plugin<br>
capabilities added to the core meet the needs of the plugin<br>
<br>
I'm happy to further discuss with you if you have interest and questions.<br>
<br>
Best regards,<br>
<br>
E. Rouault<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
<br>
_______________________________________________<br>
MapProxy-dev mailing list<br>
<a href="mailto:MapProxy-dev@lists.osgeo.org" target="_blank">MapProxy-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapproxy-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapproxy-dev</a><br>
</blockquote></div>