Re: [Geoserver-devel] GSIP-162: WMTS cascading

+1 Regards, Alessio Fabiani == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax:

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hi all, I added a commit in the PR in order to fix build breaks in community modules due to the change of the CatalogVisitor interface. Again, please note that the travis check is failing because of the missing GeoTools modules still in PR. Also note the the GeoTools PR has been updated as

Re: [Geoserver-devel] GSIP-162: WMTS cascading

It just seems odd that for vector and raster stores we can have an extendable approach - but not for web services. But I do understand - I think it is more that WMS is exceptional with support for more operations (example GetFeatureInfo) while all other web services will look similar to WMTS

Re: [Geoserver-devel] GSIP-162: WMTS cascading

In that case, I guess the current approach is fine. Torben On Tue, Jul 18, 2017 at 3:40 AM, Emanuele Tajariol wrote: > Hi Torben! Hi Jody! > > IMHO I don't see a big advantage in such a refactoring: > - Most of the if/elseif chains contain different logic in the WMS/WMTS

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hi Torben! Hi Jody! IMHO I don't see a big advantage in such a refactoring: - Most of the if/elseif chains contain different logic in the WMS/WMTS blocks, so the refactoring in a single class (WebServiceInfo + wstype) would only add nested IF blocks inside the existing chains. Ugly to see (but

Re: [Geoserver-devel] GSIP-162: WMTS cascading

On Fri, Jul 14, 2017 at 10:20 AM, Jody Garnett wrote: > Torben could we do this without introducing additional "info" objects? > > > Change it so that WebSeviceInfo contains has a "wstype" (similar to > "dbtype") that is used to to configure WebServiceInfo with either >

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hi Andrea, >- If you have not done so already, please send a formal proposal mail to >geotools-devel too (for the geotools part) Yep, the thread is here: http://osgeo-org.1560.x6.nabble.com/JIRA-GEOT-5766-Create-a-CoverageReader- for-remote-WMTS-td5326189.html#a5326285 It's linked in

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hi Torben, while your suggestion makes sense and I have asked Emanuele to take into account I am also a bit reluctant to follow it. We tried to stick to the current structure (not saying it is good or bad, it is just the way it is) and doing a general refactor now might give us more harm than

Re: [Geoserver-devel] GSIP-162: WMTS cascading

I'm pretty sure I tried that approach but ran into issues further down the line. I'm travelling to Paris at present and my laptop is in the hold but I'll check and see if I can find what the issue was. Ian On 14 Jul 2017 17:35, "Torben Barsballe" wrote: > Hello

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Torben could we do this without introducing additional "info" objects? Change it so that WebSeviceInfo contains has a "wstype" (similar to "dbtype") that is used to to configure WebServiceInfo with either WMSProtocolStratagy or WMTSProtcolStratagy responsible for speaking the correct protocol

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hi Emanuele, it seems like the implementation mimics 1-1 the WMS approach, looks good to me. Some remarks: - If you have not done so already, please send a formal proposal mail to geotools-devel too (for the geotools part) - The change seems to have GeoServer core refer to a GeoTools

Re: [Geoserver-devel] GSIP-162: WMTS cascading

Hello Emanuele, There is one immediate concern I see with this change: There are a number of places, both in core code as well as extensions and community modules, in the GeoServer codebase that use the following pattern: if ( r instanceof FeatureTypeInfo ) { ... }