{"id":6609,"date":"2018-10-09T04:31:16","date_gmt":"2018-10-09T02:31:16","guid":{"rendered":"http:\/\/www.sigterritoires.fr\/?p=6609"},"modified":"2018-10-17T12:00:59","modified_gmt":"2018-10-17T10:00:59","slug":"the-geoserver-explorer-plugin-for-qgis-2-limitations","status":"publish","type":"post","link":"https:\/\/www.sigterritoires.fr\/index.php\/en\/the-geoserver-explorer-plugin-for-qgis-2-limitations\/","title":{"rendered":"The Geoserver Explorer plugin for QGis ( 2): limitations"},"content":{"rendered":"\n

Continuing the following article: The Geoserver\nExplorer plugin QGis (1) installation and configuration, we will discuss\nthe\nlimitations of the plugin. <\/p>\n\n\n\n

Limitations of the plugin<\/strong>\n<\/p>\n\n\n\n

Here is a list\nof limitations and problems likely\nto come up. <\/p>\n\n\n\n

Limitations<\/strong> related<\/strong> to the SRC<\/a>.<\/strong>\nGeoServer\ncan\nexperience\nproblems when a custom SRC system\nis\nbeing used by QGIS. The SRC definition that works\ncorrectly\nwhen\nrendering the QGIS layer, may not work when importing the layer\nto\nGeoServer\n. Usually this results in a layer\nthat is published but that does not have a SRC set\nand it is not activated. You can correct\nit\nmanually\nby\nselecting\nthe layer in the Explorer tree\nand\namending\nits CRS. <\/p>\n\n\n\n

Note that the layers are imported\nby\nusing\nthe SRC defined in the original data source\n(i.e.,\nthe file prj if you\nuse\na\n shapefile<\/a>).\nDefining\na different SRC by using the option Set Layer CRS<\/strong>\nin\nthe QGIS table of contents will not have any effect when\nimporting the layer to GeoServer , except\nif\nyou\nsave\nthe layer with this SRC so that the SRC definition is stored\nwith the data layer. <\/p>\n\n\n\n

Limitations<\/strong> related<\/strong> to the<\/strong>\nlayers<\/strong> names.<\/strong>\nGeoServer\nExplorer uses the GeoServer REST API to get the list of layers in the catalogue.\nThe REST API describes the layers without working space,\nwhich means that if you have\ntwo\nlayers with the same name and in different workspaces\n(for example , ws1:<\/em> macouche<\/em> and ws2:<\/em> macouche<\/em> ),\nthey will be displayed just\nas one ( macouche<\/em> in this\ncase\n). <\/p>\n\n\n\n

When this is the case, the\nsituation is ambiguous and GeoServer\nExplorer cannot differentiate the layers depicting the same name but\nbelonging\nto different workspaces. The layer, as described by the\nREST API, is added to the explorer tree,\nbut it represents only one of several layers that share the\nsame name. To denote this special situation, the layer is\ndisplayed\nwith a warning icon, and a warning message appears\nin\nthe layer description. <\/p>\n\n\n\n

Style limitations<\/strong>\n<\/p>\n\n\n\n

Another important\nlimitation is due to the different\nversions of the SLD supported by QGIS and GeoServer . \nThe\nGeoServer explorer\nallows to edit the style of a\nlayer\nGeoServer\ndirectly\nfrom the QGIS interface. It can\nconvert\na defined QGIS style into a downloaded from the GeoServer\ncatalogue and use GeoServer styles for the QGIS layers. This\ntwo-way conversion is, however,\nlimited.\nThis is, mainly, due\nto the different versions of SLD supported by QGIS and GeoServer , as well as\nto\nsome\nGeoServer and QGIS limitations. SLD is in use\nas\na common format by GeoServer Explorer to describe the styles in the QGIS and\nGeoServer layers, but some incompatibilities\nexist. To increase the compatibility between them, specific\nroutines have been added\nto the explorer GeoServer . However,\nin some case, a defined style\nin\nQGIS may not be compatible with the elements supported\nby GeoServer explorer , and the publication of a layer\nwill be executed with a modified style , or even\nby\nusing\na default style. <\/p>\n\n\n\n

This problem exists even\nwhen\nusing the latest version of GeoServer, but older versions of GeoServer\ncan\npresent\nmore incompatibilities and do not validate\na\ngreat\npart\nof the SLD produced by the GeoServer explorer. <\/p>\n\n\n\n

As a general rule, the basic style\nfor vector layers should operate\nwithout problems in both ways,\nbut a more complex symbology\nwill\nbe\npartially\nor\ncompletely\ninconsistent, leading to differences between, for example, the style you\nset\nin\nQGIS and the style that the GeoServer layer will depict. Raster\nlayers have a more limited support. <\/p>\n\n\n\n

Incidentally, I had to set a style for a QGis project and\nload it into Geoserver with the plugin.\nThe style was correct for GeoServer (what\ncan be double checked with the option Layers Preview). But when\nwe tried to reload the layer into QGis, the style was not accepted\nby QGis… <\/p>\n\n\n\n

Here is a list\nof acknowledged limitations for the LTC management:\n<\/p>\n\n\n\n

Raster layers<\/strong> <\/p>\n\n\n\n

The raster style is taken in\ncharge only from QGIS towards GeoServer . It\nmeans\nthat\na raster style can be created\nby\nusing\nthe\nQGIS user interface and downloaded towards GeoServer,\nbut a raster style from GeoServer cannot be used\nfor a QGIS layer . When a GeoServer\nlayer\nis added to an ongoing QGIS project with the assistance of GeoServer Explorer,\nits symbology will be used only\n\u00a0if it is\na\nvector\nlayer, but will be ignored in the case of a\nraster\nlayer and the default QGIS style will be used . \nOnly\npseudo colour Single Band<\/em> Gray<\/em> and\nSingleband<\/em> are used.\nIn\nthis\nlatter\ncase,\nthe correct colour interpolation is not supported, but the\nmodes Linear<\/em> and Discrete<\/em> are employed.<\/p>\n\n\n\n

The use of the plugin is a\nvery interesting alternative in relation to the classic\nloading process of a <\/a>\u00a0 Geoserver<\/a> style .\n<\/p>\n\n\n\n

Vector<\/strong> layers<\/strong> <\/p>\n\n\n\n

When converting a GeoServer style into\na\nQGIS style, the style is always defined\nas\na style based on rules. This means\nthat even if the style is created using a different\ntype, such as graduated<\/em> when it is downloaded into\na GeoServer catalogue and re-modified from QGIS it\nwill\nnot appear as a Graduate<\/em> style. This is due to the way QGIS includes\nthe LTC styles, by, always, interpreting always as\na\nRule-based\ntype symbology. \nBasic\nlabelling is employed, but all\nlabels (labels) will not be exported QGIS to LTC and downloaded GeoServer.\nIn\nparticular,\nthe advanced labelling is dependent on the\ndata is not used. \nImporting\na\npoints\nlayer with a QGIS SVG style towards Geoserver generates\na\nWMS\nlayer that respects this SVG symbol.\nThe same is not supported for the time being if the layer is\nreimported\nas\na WFS layer . <\/p>\n\n\n\n

In the next article we will discuss how to use the Geoserver\nExplorer plugin . <\/p>\n","protected":false},"excerpt":{"rendered":"