[MapProxy] New MapProxy 1.5.0 and yaml

[A.Pirard.Papou]

On 2013-03-15 12:59, Oliver Tonnhofer wrote :

Thanks a lot for your answers, Oliver.

> Hi,
>
> sorry to hear that you had trouble installing MapProxy, suggestions and patches for the documentation are always welcomed.
I don't know Python but I have done in my life surprising things with 
languages I know little about (like an extremely useful watch dog for a 
blocking prone Internet access control system).
I'm in a good position to fill the doc gaps with what beginners need to 
be said to understand.
But alas, you don't say how those contributions can be transmitted. 
Neither does mapproxy.org.
So, I have put a proposed documentation update on this list, but that 
was without any reaction.
Angelos Tzotsos provided a rpm module without any reaction.
Before knowing the real problem, I mentioned my DEB patch without any 
reaction.
To the question put here "how do I know if that and which yaml thing is 
installed" the only answers came from the Web, and mostly "write this 
program" or such things, until I found a so simple (but hack like)  "pip 
freeze | grep ...".

Read below for specifics.

> On 15.03.2013, at 02:25, A.Pirard.Papou wrote:
>> problem #1
>> My problem was that, somehow, PyYAML==3.10 was installed out of aptitude control.
>> When installing the 1.x.0 DEB, python-yaml-3.09 was installed on top and played havoc with 3.10.
>> pip uninstall  is undocumented (!), but it did uninstall 3.10, which put an end to war.
>> Conclusion: one should never mix two installation systems.
>> Either mapproxy should install DEBs (they are very strongly managing conflicts and requirements)
>> or pip and other installers should install python or other stuff by constructing temporary DEBs.
> MapProxy itself does not install anything, it's pip. pip is a package manager for Python and you find its documentation here: http://www.pip-installer.org/en/latest/
>
> The MapProxy documentation suggests to install MapProxy and its Python dependencies inside a virtualenv to avoid issues with conflicting isntallations.
MapProxy is in no way responsible for a stranded yaml package installed 
abnormally (without apt knowing it) (how?).
In that sense, my remark is a solution that anyone with the problem 
could find on your list.
The problem is a python problem: they should not install anything 
without telling apt.
BTW, I have seen that a DEB installation *does* warn python of what's 
being changed to it.
I wonder if I, not a python programmer, should be the one to introduce 
that bug/suggestion (and where).

This said, virtualenv is a sort of hacker's kludge to avoid apparently 
frequent conflicts when using pip.
I have installed quite a number of products without even the faintest 
knowledge that they are using python.
Let alone virtualenv.
All were installed with DEBs.  I'm always striving to find one to save 
myself nightmares.
DEBs are simplicity and confidence.
You never fear to try something because you can uninstall it completely 
(rarely local preferences).

So, I recommend Mapproxy to fully support DEB and RPM installation (85% 
of the Linux world).
- either click on Mapproxy.DEB as usual
- or install this and that DEB, create a virtual environment, use pip... 
and don't ask what KISS means.
(You already quite rightly install pip prerequisites with DEBs in a few 
clicks; why not just one?).

>> problem #2
>> Well, now to the 1.5.0 config problem (1.4.0 uses the same config nicely):
>>
>> mapproxy.service.wmts - WARNING - grid 'global_geodetic_sqrt2' is not compatible with WMTS, skipping for layer 'osm'
>>
>> Same message for another layer.
>> Many Google hits for this message, but none seems to apply.
> TMS and WMTS have different tile origins and you can configure grids where you cannot just flip the y-axis. global_geodetic_sqrt2 is such a grid that only works for services with origin south-west/lower-left but not with origin north-west/upper-left (like WMTS).
>
> I agree that it is a bit unfortunate that the default configuration issues warnings and we will update the base-config with 1.6.
>> I fear that if maxproxy
>> 	• believes that WMTS is used while it is not
> You can disable the wmts service by removing it from the services section.
>> 	• does not understand the grid used by the cache
>> it could destroy something and I returned to 1.4.0.
> No, this layer is then just not available for WMTS.
Oops.
The bottom line here is what frequently happens when who-knows says 
something without imagining at all that who-doesn't can be totally 
driving on another lane and why ;-)
When I read that message, I understood from "skipping for layer osm, and 
for layer XXX" that global_geodetic_sqrt2  isn't compatible with a WMTS 
*source* and I feared that mapproxy was believing that my sources are 
WMTS !!!
I plead guilty for having overlooked "mapproxy.service.wmts", but yet, I 
suggest "is not compatible with WMTS *service*" to put the explanation 
fully where the reader has his eyes in the message.

Thanks for your help,
Hoping this helped,
On to 1.5.0 now,
Cheers,

André.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20130315/f9c07fca/attachment-0001.html>