Bug

Describe the bug
The SLD parser appears to not parse the text color properly and resets it to #000000. This happens with SLDs from QGIS as well as the SLD generated by the demo app.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://geostyler.github.io/geostyler-demo/
2. Edit Rule 1 to be of Kind: Text and choose a color other than black
3. Copy the SLD in the Code Editor to clipboard
4. Reload the page and paste the SLD from clipboard
5. Observe that the CSS parameter fill in Fill changes from your chosen color to #000000

Expected behavior
The SLD parser should recognize the the color and not change it to the default.

Additional context
I had a quick glance through the code of the SLD parser and I couldn't immediately see what is going wrong as it tries to extract the fill and fill-opacity from the CSS parameters.

Bug

surce code
[CssParameter]: [{
'#text': textSymbolizer.opacity || '1',
}],
':@': {
'@_name': 'fill-opacity'
}
expectation
The original value was 0.

Thank you for making the change.

Question

• My System Qgis-Server 3.10.x LTR for WMS,WFS
• get the sld-Style with a WMS-request
  http://localhost:8085/projekt/qgis_mapserv.fcgi.exe?SERVICE=WMS&VERSION=1.3.0&request=GetStyles&layers=Absperrschieber_GL
• output-xml is SLD-Version 1.1.0 -> a square with rotation 45°

<StyledLayerDescriptor xmlns="http://www.opengis.net/sld" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:se="http://www.opengis.net/se" version="1.1.0" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/StyledLayerDescriptor.xsd"> <NamedLayer> <se:Name>Absperrschieber_GL</se:Name> <UserStyle> <se:Name>default</se:Name> <se:FeatureTypeStyle> <se:Rule> <se:Name>Single symbol</se:Name> <se:PointSymbolizer> <se:Graphic> <se:Mark> <se:WellKnownName>square</se:WellKnownName> <se:Fill> <se:SvgParameter name="fill">#7bb084</se:SvgParameter> </se:Fill> <se:Stroke> <se:SvgParameter name="stroke">#3d8035</se:SvgParameter> <se:SvgParameter name="stroke-width">1</se:SvgParameter> </se:Stroke> </se:Mark> <se:Size>12</se:Size> <se:Rotation> <ogc:Literal>45</ogc:Literal> </se:Rotation> </se:Graphic> </se:PointSymbolizer> </se:Rule> </se:FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>

the problem is the rotation will not be parsed
<se:Rotation> <ogc:Literal>45</ogc:Literal> </se:Rotation>

tested with your geostyler-demo copy&paste -> rotation removed
Support the geostyler-sld-parser only sld-version 1.0.0 or is a bug?

Thanks a lot!

Currently the sld-parser only parses the fill and stroke property of the polygons in a sld rule and doesn't consider other cssParameters such as stroke-dasharray or GraphicFill. In addition the parser fails to consider multiple PolygonSymbolizers.

Example Sld is a sample SLD that the parser needs to be able to parse.

Sub-issues / related issues to complete this:

• Support for pattern fill in FillSymbolizer https://github.com/terrestris/geostyler/issues/214
• Support for multiple symbolizers (gs-style) geostyler/geostyler#248
• Support multiple symbolizer (SLD-Parser) geostyler/geostyler#85
• Support for further cssParameters geostyler/geostyler#249

In contrast to the geoserver sld-documentation, GraphicFill and GraphicStroke are exclusive. Thus, only one of both can be set at a time. This can be seen in the sldSchema:

<xsd:complexType>
  <xsd:sequence>
    <xsd:choice minOccurs="0">
      <xsd:element ref="sld:GraphicFill"/>
      <xsd:element ref="sld:GraphicStroke"/>
    </xsd:choice>
    <xsd:element ref="sld:CssParameter" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

geostyler-sld-parser and the UI should be updated accordingly.

• Updated geostyler-sld-parser
• Updated UI

Bug

Describe the bug
We try using geostyler-sld-parser on a VueJS application.
Code on local machine works well using vue-cli-service serve (based on webpack-dev-server).

Production code is bundled using Rollup.js we got a warning during build due to a circular dependencies in xmlbuilder dependencies which must be imported by geostyler-sld-parser.
Once deployed code failed Uncaught TypeError: Cannot read property 'prototype' of undefined" on the xml paser part.

To Reproduce
Steps to reproduce the behavior:

1. Rollup config

import vue from "rollup-plugin-vue";
import alias from '@rollup/plugin-alias';
const json = require("@rollup/plugin-json");
import importResolver from "rollup-plugin-import-resolver";
import nodePolyfills from 'rollup-plugin-node-polyfills';
import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import { i18n } from "./lib/index.js";

const postcss = require("rollup-plugin-postcss");
const ComponentVue = [
  "./src/lib/modules/msec-visualisation-block/msec-visualisation-block.vue",

  // Module below contains :
  // import SLDParser from "geostyler-sld-parser";
  // import OpenLayersParser from "geostyler-openlayers-parser";
  "./src/lib/modules/rrp-visualisation-block/rrp-visualisation-block.vue"
];

const confFile = ComponentVue.map(componentpath => {
  const confFileName = componentpath.split("/").reverse()[0];
  return {
    input: componentpath,
    output: {
      file: "modules/" + confFileName + ".esm.js",
      format: "esm"
    },
    moduleContext: {
      'node_modules/sax/lib/sax.js': 'window'
    },
    external: ["vue-i18n","vue"],
    plugins: [
      alias({
        entries: {
          ['@']: __dirname + '/src' 
        }
      }),
      nodePolyfills(),
      commonjs({
        include: /node_modules/
      }),
      resolve(),
      importResolver({ extensions: [".js", ".vue"] }),
      postcss(),
      json(),
      i18n(),
      vue({ customBlocks: ["i18n"] })
    ]
  };
});
export default confFile;

Dependencies version in package.json

  "dependencies": {
    "@mapbox/geojson-extent": "^1.0.0",
    "axios": "^0.19.2",
    "core-js": "^3.6.4",
    "dotenv": "^8.2.0",
    "geojson-extent": "^0.3.2",
    "geostyler": "^4.6.0",
    "geostyler-openlayers-parser": "^2.1.0",
    "geostyler-sld-parser": "^2.0.1",
    "lodash": "^4.17.15",
    "marked": "^0.8.0",
    "moment": "^2.24.0",
    "ol": "^5.3.0",
    "ol-ext": "^3.1.16",
    "ol-tilecache": "^3.0.2",
    "openlayers-ext": "^3.1.5",
    "raw-loader": "^4.0.2",
    "rollup": "^1.31.0",
    "rollup-plugin-import-resolver": "^1.0.4",
    "vue": "^2.6.11",
    "vue-axios": "^2.1.5",
    "vue-i18n": "^8.0.0",
    "vue-router": "^3.1.5",
    "vuelayers": "^0.11.28",
    "vuetify": "^2.3.4",
    "vuex": "^3.1.2"
  },
  "devDependencies": {
    "@intlify/rollup-plugin-vue-i18n": "^0.1.0",
    "@kazupon/vue-i18n-loader": "^0.3.0",
    "@rollup/plugin-alias": "^3.0.1",
    "@rollup/plugin-commonjs": "^12.0.0",
    "@rollup/plugin-json": "^4.0.2",
    "@rollup/plugin-node-resolve": "^7.1.1",
    "@rollup/plugin-yaml": "^2.1.0",
    "@vue/cli-plugin-babel": "~4.2.0",
    "@vue/cli-plugin-eslint": "~4.2.0",
    "@vue/cli-plugin-router": "~4.2.0",
    "@vue/cli-plugin-vuex": "~4.2.0",
    "@vue/cli-service": "~4.2.0",
    "babel-eslint": "^10.0.3",
    "eslint": "^6.7.2",
    "eslint-plugin-vue": "^6.1.2",
    "lint-staged": "^9.5.0",
    "rollup-plugin-analyzer": "^3.2.2",
    "rollup-plugin-commonjs": "^10.1.0",
    "rollup-plugin-import-resolver": "^1.0.4",
    "rollup-plugin-includepaths": "^0.2.3",
    "rollup-plugin-node-polyfills": "^0.2.1",
    "rollup-plugin-node-resolve": "^5.2.0",
    "rollup-plugin-postcss": "^2.5.0",
    "rollup-plugin-vue": "^5.1.4",
    "rollup-pluginutils": "^2.8.2",
    "sass": "^1.19.0",
    "sass-loader": "^8.0.0",
    "sedoo-static-upload-plugin": "^0.1.3",
    "vue-cli-plugin-i18n": "~0.6.1",
    "vue-cli-plugin-vuetify": "~2.0.5",
    "vue-template-compiler": "^2.6.11",
    "vuetify-loader": "^1.3.0",
    "webpack-cdn-upload-plugin": "^2.1.0",
    "webpack-cli": "^3.3.11"
  },

2. npm run build:modules

> [email protected] build:modules /home/tromuald/git/theiacomponents
> rm -rf ./modules && rollup --config rollupBuildAllComponents.config.js

./src/lib/modules/msec-visualisation-block/msec-visualisation-block.vue → modules/msec-visualisation-block.vue.esm.js...
created modules/msec-visualisation-block.vue.esm.js in 488ms

./src/lib/modules/rrp-visualisation-block/rrp-visualisation-block.vue → modules/rrp-visualisation-block.vue.esm.js...
(!) Circular dependencies
node_modules/xmlbuilder/lib/XMLNode.js -> node_modules/xmlbuilder/lib/XMLElement.js -> node_modules/xmlbuilder/lib/XMLNode.js
node_modules/xmlbuilder/lib/XMLNode.js -> node_modules/xmlbuilder/lib/XMLElement.js -> node_modules/xmlbuilder/lib/XMLAttribute.js -> node_modules/xmlbuilder/lib/XMLNode.js
node_modules/xmlbuilder/lib/XMLNode.js -> node_modules/xmlbuilder/lib/XMLElement.js -> node_modules/xmlbuilder/lib/XMLAttribute.js -> /home/tromuald/git/theiacomponents/node_modules/xmlbuilder/lib/XMLNode.js?commonjs-proxy -> node_modules/xmlbuilder/lib/XMLNode.js
...and 9 more
created modules/rrp-visualisation-block.vue.esm.js in 3.9s
[tromuald@F-L050-B007 theiacomponents]$ 

3. Once deployed after npm run deploy the block doesn't show up
   I can see in the browser console Uncaught TypeError: Cannot read property 'prototype' of undefined on the following part of rrp-visualisation-block.vue.esm.js

var XMLElement = createCommonjsModule(function (module) {
// Generated by CoffeeScript 1.12.7
(function() {
  var NodeType$1, XMLAttribute$1, XMLElement, XMLNamedNodeMap$1, XMLNode$1, getValue, isFunction, isObject, ref,
    extend = function(child, parent) { for (var key in parent) { if (hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; },
    hasProp = {}.hasOwnProperty;

4. See error
   Looks like like it's a known issue rollup/rollup#1767 (comment)

Expected behavior
Do you see a way to use geostyler-sld-parser with the bundler Rollup.js ?

Desktop (please complete the following information):

• OS: [CentOS 8]
• Browser [Chrome]
• Version [Version 80.0.3987.122 (Build officiel) (64 bits)]

After ther rewrite to fast-xml-parser we have to restore and rewrite the support for GeoStylerFunction and Expression.

Question

When doing some experiments with mark symbolizers using font glyphs instead of standard shapes, I realized the WellKnownName property of the symbolizer was modified to lowercase here:

This looks like it is necessary because the Geostyler format expects shapes to be named Circle, Cross etc. and the SLD standard works with circle, cross etc.

Unfortunately, this results in a very strong constraint where no upper case character can be used in well known names at all, which makes it impossible to use font glyphs like so: <WellKnownName>ttf://Webdings#0x0064</WellKnownName>.

Without the upper case, the previous example will not render correctly in GeoServer.

Would it be possible to consider making the logic more fine-grained, and for example only make the first character lowercase? or have an association of well known names such as Circle -> circle etc?

If this modification receives approval, I will create a Pull Request in that sense.

Note that this is linked to the issue on the OL parser here: geostyler/geostyler-openlayers-parser#230

Thanks a lot!

Description

It would be great if the GeoStyler would support the usage of AnchorPoint entries in the sld file:

PointPlacement

Currently the GeoStyler deletes the AnchorPoint entries when the sld file is uploaded. As a first step, it would be very useful if the GeoStyler could keep these entries and export them when the sld file is saved.

It would be even more useful if the GeoStyler could create and edit AnchorPoint entries 🙂

Example

Sample sld and geojson:
label_placement.zip

Alternatives

No response

Additional Context

No response

Feature Request

It seems that "graphicstroke" should be supported in getFillSymbolizerFromSldSymbolizer, but is there a reason it is missing?

Bug

Description:
Missing label properties in the TextSymbolizer.

Example:

  <sld:NamedLayer>
    <sld:Name>HistoryLayer_style</sld:Name>
    <sld:UserStyle>
      <sld:Name>HistoryLayer_style</sld:Name>
      <sld:Title>HistoryLayer_style</sld:Title>
      <sld:FeatureTypeStyle>
        <sld:Name>name</sld:Name>
        <sld:Rule>
          <sld:Name>1-*-MyRule2</sld:Name>
          <sld:LineSymbolizer>
            <sld:Stroke>
              <sld:CssParameter name="stroke">#00e6ff</sld:CssParameter>
              <sld:CssParameter name="stroke-linecap">round</sld:CssParameter>
              <sld:CssParameter name="stroke-linejoin">round</sld:CssParameter>
              <sld:CssParameter name="stroke-width">3</sld:CssParameter>
            </sld:Stroke>
          </sld:LineSymbolizer>
        </sld:Rule>
        <sld:Rule>
          <sld:Name>2-*-MyRule2</sld:Name>
          <sld:TextSymbolizer>
            <sld:Label>ок</sld:Label>
            <sld:Font>
              <sld:CssParameter name="font-family">Couirer New</sld:CssParameter>
              <sld:CssParameter name="font-size">10</sld:CssParameter>
              <sld:CssParameter name="font-style">normal</sld:CssParameter>
              <sld:CssParameter name="font-weight">normal</sld:CssParameter>
            </sld:Font>
            <sld:LabelPlacement>
              <sld:PointPlacement>
                <sld:Displacement>
                  <sld:DisplacementX>5</sld:DisplacementX>
                  <sld:DisplacementY>5</sld:DisplacementY>
                </sld:Displacement>
                <sld:Rotation>5</sld:Rotation>
              </sld:PointPlacement>
            </sld:LabelPlacement>
            <sld:Halo>
              <sld:Radius>1.0</sld:Radius>
              <sld:Fill>
                <sld:CssParameter name="fill">#000000</sld:CssParameter>
              </sld:Fill>
            </sld:Halo>
            <sld:Fill>
              <sld:CssParameter name="fill">#4f00fa</sld:CssParameter>
            </sld:Fill>
          </sld:TextSymbolizer>
        </sld:Rule>
      </sld:FeatureTypeStyle>
    </sld:UserStyle>
  </sld:NamedLayer>
</sld:StyledLayerDescriptor>```

variable equals to: 

``` {
  "name": "HistoryLayer_style",
  "rules": [
    {
      "name": "1-*-MyRule2",
      "symbolizers": [
        {
          "kind": "Line",
          "color": "#00e6ff",
          "cap": "round",
          "join": "round",
          "width": 3
        }
      ]
    },
    {
      "name": "2-*-MyRule2",
      "symbolizers": [
        {
          "kind": "Text",
          "color": "#4f00fa",
          "haloWidth": 1,
          "haloColor": "#000000",
          "offset": [
            5,
            5
          ],
          "rotate": 5,
          "font": [
            "Couirer New"
          ],
          "size": 10,
          "fontStyle": "normal",
          "fontWeight": "normal"
        }
      ]
    }
  ]
}```

Feature Request

Is your feature request related to a problem? Please describe.

Currently we always write SLD 1.0.0, even though a SLD 1.1.0 was initially given. We also downgrade some 1.1.0 features e.g. SvgParameter vs CssParameter.

Describe the solution you'd like

We should clearly distinguish between the different SLD versions and be able to read/write both properly.

We should either create two completely distinct parsers for each version, respectively, or add a switch to distinguish between the different versions.

Hello,
I wonder whether the parser supports uom in the Symbolizer element,
I got a SLD 1.1 style containing this LineSymbolizer

          <se:LineSymbolizer uom="http://www.opengeospatial.org/se/units/metre">
            <se:Stroke>
              <se:SvgParameter name="stroke">#333333</se:SvgParameter>
              <se:SvgParameter name="stroke-width">1600</se:SvgParameter>
              <se:SvgParameter name="stroke-linejoin">round</se:SvgParameter>
              <se:SvgParameter name="stroke-linecap">round</se:SvgParameter>
            </se:Stroke>
          </se:LineSymbolizer>

and I get verrrry wide lines so that the screen is filled. Another LineSymbolizer in the same style without uom and a small width works fine.
I read the SLD style and wrote it to a MB Style and displayed it in MapLibre.

Description

GeoStyler appears to throw away the fill-opacity when the opacity is zero, resulting in polygons being displayed with maximum opacity.

QGIS displays polygons with 0 opacity as transparent. Using the SLD exported from QGIS, GeoStyler displays the same polygons as fully opaque. This causes confusion when styling and previewing a layer in QGIS, exporting the SLD, and seeing the layer displayed differently in GeoStyler.

Expected behaviour

I expect the fill-opacity to not be removed/discarded. I expect GeoStyler to respect the SLD as supplied, and to display polygons as they appear in QGIS.

How to reproduce

1. go to https://geostyler.github.io/geostyler-demo/
2. load data - upload polygon.json (see zip file)
3. load style - upload polygon.sld (see zip file)

Note that the fill-opacity is automatically removed from the SLD and the polygon is displayed with maximum opacity.

polygon.zip

Possible Solution

Don't discard the fill-opacity from the SLD.

Additional Context

No response

Describe the bug
Testing the Demo Version I found found false SLD 1.1.0 Output

To Reproduce

Output via Geostyler:

<UserStyle>
	<se:Name>Kegelrobbe_K_Means</se:Name>
	<se:Title>Kegelrobbe_K_Means</se:Title>
	<se:FeatureTypeStyle>

Expected behavior

<UserStyle>
	<se:Name>Kegelrobbe_K_Means</se:Name>
	  <se:Description>
		<se:Title>Kegelrobbe_K_Means</se:Title>
		<se:Abstract>K-Means Algorithmus Berechnung der Kegelrobbenverteilung</se:Abstract>
	   </se:Description>
	<se:FeatureTypeStyle>

The Abstract element is additional included

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update actions/cache action to v4
• chore(deps): update commitlint monorepo to v19 (major) (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update dependency conventional-changelog-conventionalcommits to v8
• chore(deps): update dependency eslint to v9
• chore(deps): update dependency semantic-release to v23
• chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): update vitest monorepo to v1 (major) (@vitest/coverage-istanbul, vitest)
• chore(deps): update wagoid/commitlint-github-action action to v6
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency vite to v4.5.3 [security]
• chore(deps): update dependency semantic-release to v22.0.12
• chore(deps): update vitest monorepo to v0.34.6 (@vitest/coverage-istanbul, vitest)
• chore(deps): update babel monorepo to v7.24.6 (@babel/core, @babel/preset-env, @babel/preset-typescript)
• chore(deps): update commitlint monorepo to v18.6.1 (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update dependency @types/node to v20.12.12
• chore(deps): update dependency eslint to v8.57.0
• chore(deps): update dependency typescript to v5.4.5
• chore(deps): update typescript-eslint monorepo to v6.21.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency fast-xml-parser to v4.4.0
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Question

你们版本更新为什么获取的数据会被添加output 从2.4.0到3.0.1版本更新后出现的问题 数据格式改了嘛？

The parser currently breaks when feeding with an PropertyIsNull filter, as the following line
https://github.com/terrestris/geostyler-sld-parser/blob/c2ac49b2a74a3876d3a2020a596939bef54153f9/src/SldStyleParser.ts#L156
tries to read a literal which does not exist in this case.

Should be fixed just by using

let value = null;
if (sldOperatorName !== 'PropertyIsNull') {
  value = sldFilter.Literal[0];
}

The devDependency @types/node was updated from 12.7.12 to 12.11.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Bug

Describe the bug

The CI fails for the latest tests even though they should pass. The error already occurs before any test is run and is based on some incompatibility between node v12.17/v13.13 and some babel packages.

To Reproduce

Check the CI pipelines, e.g. https://travis-ci.org/github/geostyler/geostyler-sld-parser/builds/692156105

Expected behavior

Tests should at least start. A solution was posted here babel/babel#11439 (comment). Therefore, we should update the said packages accordingly.

Also, we should wait with merging any PRs until our CI runs properly again.

Screenshots

none

Desktop (please complete the following information):

travis CI with node version 12

Smartphone (please complete the following information):

none

Additional context

Feature Request

Is your feature request related to a problem? Please describe.
currently wildcard, singleChar and escape values are hard coded.

Describe the solution you'd like
option to pass wildcard, singleChar and escape values, while creating comparison filter PropertyIsLike

There have been updates to the babel7 monorepo:

• • The devDependency @babel/core was updated from 7.7.7 to 7.8.0.

• The devDependency @babel/plugin-proposal-class-properties was updated from 7.7.4 to 7.8.0.
• The devDependency @babel/plugin-proposal-object-rest-spread was updated from 7.8.0 to 7.8.3.
• The devDependency @babel/polyfill was updated from 7.8.0 to 7.8.3.
• The devDependency @babel/preset-env was updated from 7.8.0 to 7.8.2.
• The devDependency @babel/preset-typescript was updated from 7.7.4 to 7.7.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Feature Request

It would be a nice feature to read the SLD version when reading an SLD automatically.

@rdewit mentioned here: #682 (comment)

The reason that I'm asking is because when we use the SLD parser in our code, we now 'manually' extract it with using the following (also using fast-xml-parser) just to get that version information:
[...]
We then feed that version value as option in the constructor of the SLD parser. It seems that automatically extracting it from the SLD would be a logical next step.

Feature Request

Is your feature request related to a problem? Please describe.
I've been looking for a js library to validate a SLD XML string.

Describe the solution you'd like
I'd like to a method which takes an xml string and returns a boolean as to whether it's valid or not.

const isValid = geostylerSldParser.isSldValid(xmlString)

Describe alternatives you've considered
Doesn't look like there are any other js libs out there working on SLD stuff :(

Additional context
Add any other context or screenshots about the feature request here.

Thanks for sharing what looks like an interesting library!

Feature Request

Is your feature request related to a problem? Please describe.

Only one image can be applied for features in a layer. To have different icons, we need to either create multiple rules or have multiple layers for each image.

Describe the solution you'd like

Icon url should be decided based on feature attribute values and {{ templates }} in a similar way how the label for TextSymbolizer is created.

Describe alternatives you've considered

Walkaround is to create multiple rules and filters with one IconSymbolizer per each rule-filter pair.

Additional context

This is a copy of geostyler/geostyler-openlayers-parser#363 by @raitisbe. See also geostyler/geostyler-openlayers-parser#364

Bug

Describe the bug

The <Format> tag is missing when converting from geostyler to SLD.

To Reproduce

const { SldStyleParser } = await import("geostyler-sld-parser");
const geostyle = {
  rules: [
    {
      name: 'MissingFormat',
      symbolizers: [{kind: "Icon", image: '/path/to/icon.png'}],
    },
  ]
}
const parser = new SldStyleParser({ builderOptions: { format: true }});

parser.writeStyle(geostyle).then(({ output: sld }) => console.log(sld));

Result:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StyledLayerDescriptor version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd" xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:se="http://www.opengis.net/se">
  <NamedLayer>
    <Name/>
    <UserStyle>
      <Name/>
      <Title/>
      <FeatureTypeStyle>
        <Rule>
          <Name>MissingFormat</Name>
          <PointSymbolizer>
            <Graphic>
              <ExternalGraphic>
                <OnlineResource xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="/path/to/icon.png"/>
              </ExternalGraphic>
            </Graphic>
          </PointSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Expected behavior

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<StyledLayerDescriptor version="1.0.0" xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd" xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:se="http://www.opengis.net/se">
  <NamedLayer>
    <Name/>
    <UserStyle>
      <Name/>
      <Title/>
      <FeatureTypeStyle>
        <Rule>
          <Name>MissingFormat</Name>
          <PointSymbolizer>
            <Graphic>
              <ExternalGraphic>
                <OnlineResource xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="/path/to/icon.png"/>
                <Format>image/png</Format>
              </ExternalGraphic>
            </Graphic>
          </PointSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Additional context
Node v20.8.0
Debian
geostler-sld-parser v5.1.0

My fix

diff --git a/src/SldStyleParser.ts b/src/SldStyleParser.ts
index 0373158..eb0ccfa 100644
--- a/src/SldStyleParser.ts
+++ b/src/SldStyleParser.ts
@@ -1739,13 +1739,13 @@ export class SldStyleParser implements StyleParser<string> {
         case 'png':
         case 'jpeg':
         case 'gif':
-          graphic[0][ExternalGraphic][0][Format] = [`image/${iconExt}`];
+          graphic[0][ExternalGraphic][1] = { [Format]:  [{ '#text': `image/${iconExt}` }] };
           break;
         case 'jpg':
-          graphic[0][ExternalGraphic][0][Format] = ['image/jpeg'];
+          graphic[0][ExternalGraphic][1] = { [Format]:  [{ '#text': `image/jpeg` }] };
           break;
         case 'svg':
-          graphic[0][ExternalGraphic][0][Format] = ['image/svg+xml'];
+          graphic[0][ExternalGraphic][1] = { [Format]:  [{ '#text': `image/svg+xml` }] };
           break;
         default:
           break;

PS: Thank you for your awesome work !!

PARSER

SLD

FEATUREREQUEST

Description:

The Builder class of xml2js accepts several renderOpts in order to influence the created XML (SLD in our case). The SLD-parser should be able to accept these and use them when creating the SLD in the writeStyle function.
By #207 the render option pretty was introduced as specific member. This could be replaced by the more generic approach of passing in a complete renderOpts config as described above.

Bug

The geostyler-style and SLD handle the Y value of the offset/displacement contrary.

SLD: A value of 20 in SLD means 20 pixel above the acutal position
geostyler-style: A value of 20 means 20 pixel below the actual position

Expected behavior

The visual output should be more or less the same.

To fix

The Y values of the offset/displacement have to be negated when parsing.

Additional context

Bug found by @yang6626 here geostyler/geostyler-openlayers-parser#432

Is this plugin still compatible with the newest outputs from qgis. We have been trying to get it to export correctly to no avail.

Example:
<?xml version="1.0" encoding="UTF-8"?> <StyledLayerDescriptor xmlns="http://www.opengis.net/sld" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/StyledLayerDescriptor.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1.0" xmlns:se="http://www.opengis.net/se"> <NamedLayer> <se:Name>county_boundaries</se:Name> <UserStyle> <se:Name>county_boundaries</se:Name> <se:FeatureTypeStyle> <se:Rule> <se:Name>Single symbol</se:Name> <se:PolygonSymbolizer> <se:Fill> <se:SvgParameter name="fill">#8d5a99</se:SvgParameter> <se:SvgParameter name="fill-opacity">0</se:SvgParameter> </se:Fill> <se:Stroke> <se:SvgParameter name="stroke">#ff0101</se:SvgParameter> <se:SvgParameter name="stroke-width">1</se:SvgParameter> <se:SvgParameter name="stroke-linejoin">bevel</se:SvgParameter> </se:Stroke> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>

when running const { output: geostylerStyle } = await sldParser.readStyle(self.SLDFile) it outputs the following:

[ { "name": "Single symbol", "symbolizers": [ { "kind": "Fill" } ] } ]

We did notice that if we manually edited this._sldVersion = '1.1.0'; We were able to get better results but it duplicated the fill twice. Is there something we are doing wrong or a compatibility issue we need to work on.

Currently the sld-parser only parses the fill and stroke property of the polygons in a sld rule and doesn't consider other cssParameters such as stroke-dasharray or GraphicFill. In addition the parseer fails to consider multiple PolygonSymbolizers.
Example Sld is a sample sld that the parser needs to be able to parse.

Question

Has Internet Explorer 11 support been "officially" dropped for geostyle-sld-parser?

The package.json currently contains the following:

The npm builds include syntax that throws errors in IE11 e.g. 2 ** 24 which would need to be replaced with Math.pow(2, 24) (as per https://stackoverflow.com/a/33284586/179520). I presume there could be some way of building IE11 compatible versions using babel.

No problems if support has been dropped - we're just assessing how feasible it is to continue IE11 support.

PARSER

SLD

BUG

Description:

The SLD parser (or specifically the underlying xml2js library) does not properly support element order. For reading this could work if we'd use the appropriate xml2js options, but for writing these are not supported. This means that writing out a style like this may rearrange elements. Example:

{
  "name": "Demo Style",
  "rules": [
    {
      "name": "Rule 1",
      "symbolizers": [
        {
          "kind": "Text",
          "label": "Your Label{{value}}My label{{name}}{{other}}Something",
          "size": 12
        }
      ]
    }
  ]
}

Paste this in the demo, switch to SLD, copy the SLD, reload and paste the SLD back in and you'll get:

{
  "name": "Demo Style",
  "rules": [
    {
      "name": "Rule 1",
      "symbolizers": [
        {
          "kind": "Text",
          "label": "Your Label{{value}}My label{{name}}Something{{other}}",
          "size": 12
        }
      ]
    }
  ]
}

This is currently the only place I can think of where it might cause problems, but once we'll support functions which get a list of parameters this will cause problems.

It's also not very nice on the filter level because filters of the same type on the same level will always be grouped together, regardless of the original definition.

IMHO we should switch to a different way of XML generation.

PARSER

SLD

FEATUREREQUEST

Description:

Following the SLD specification the color property of a Symbolizer must be specified as hex-code. However, other styles (e.g. openlayers, mapbox) allow a multitude of formats e.g. words ('green'), hsl() and rgba().

The geostyler-style only specifies the property color as a string.

It would be nice if the SLD parser would be able to parse before mentioned formats to hex-codes so that we do not have to limit allowed formats for the other parsers.

Question

Hey. I think I found an issue when working with Sld and OpenLayers parsers. Sld parses fill-opacity to fillOpacity field:

case 'fill-opacity':
          fillSymbolizer.fillOpacity = parseFloat(value);
          break;

However later on opacity field is also set:

if (!fillSymbolizer.color) {
      fillSymbolizer.opacity = 0;
    }

I also found out that in OpenLayers parser, when creating Polygon symbolizer from Fill symbolizer, opacity field is used, which won't work because the opacity will be null because the color is set, therefor the color will always be solid:

 getOlPolygonSymbolizerFromFillSymbolizer(symbolizer: FillSymbolizer): OlStyleFill {
    let fill = symbolizer.color ? new this.OlStyleFillConstructor({
      color: (symbolizer.opacity !== null && symbolizer.opacity !== undefined) ?
        OlStyleUtil.getRgbaColor(symbolizer.color, symbolizer.opacity) : symbolizer.color
    }) : null;

Am I correct in thinking that this is not right? If this is an issue, is it an issue of Sld or OpenLayers parser?

Bug

Describe the bug

4 tests fail due to line ending differences:

• SldStyleParser implements StyleParser › #writeStyle › creates the correct order in a text symbolizer './data/slds/1.0/unsupported_properties.sld'
• SldStyleParser implements StyleParser › #writeStyle › creates the correct order in a text symbolizer './data/slds/1.1/unsupported_properties.sld'
• SldStyleParser with Symbology Encoding implements StyleParser › #writeStyle › adds unsupportedProperties to the write output './data/slds/1.0/point_styledLabel_elementOrder.sld'
• SldStyleParser with Symbology Encoding implements StyleParser › #writeStyle › adds unsupportedProperties to the write output './data/slds/1.1/point_styledLabel_elementOrder.sld'

All the above test cases

      880 |       expect(warnings).toEqual(warningsGot);
      881 |       const sld = fs.readFileSync('./data/slds/1.0/unsupported_properties.sld', 'utf8');
    > 882 |       expect(sldString).toEqual(sld.trim());

It is caused by the following function:

This writes out to the SLD using LF rather than CRLF, which then makes the comparison fail.
Are the line endings added by .join('');?

Note my git settings checkout files using CRLF so all other files are passing. One "fix" is to change the failing test cases to use LF.
Another hacky fix is to get rid of all whitespace in the comparisons (but that makes

Tests:       4 failed, 182 passed, 186 total

To Reproduce

On a Windows machine:

npm test

Bug

Describe the bug
Svg Base64 Icon Image Format in SLD files is not parsed (version 4.0.1)

To Reproduce

QGIS generates the following SLD v1.1.0 code piece:

<se:PointSymbolizer>
            <se:Graphic>
              <!--Parametric SVG-->
              <se:ExternalGraphic>
                <se:OnlineResource xlink:type="simple" xlink:href="base64:PHN2ZyBoZWlnaHQ9IjEwOS41cHQiIHZpZXdCb3g9IjAgMCAxMDkuNSAxMDkuNSIgd2lkdGg9IjEwOS41cHQiPjxnIGZpbGw9IiMwMDA0MDAiIHN0cm9rZT0iIzAwMCI+PHBhdGggZD0ibTc0LjA2MyA1NC43NWMwLTEwLjg3My04LjgxNC0xOS42ODgtMTkuNjg4LTE5LjY4OHMtMTkuNjg3IDguODE1LTE5LjY4NyAxOS42ODggOC44MTQgMTkuNjg4IDE5LjY4OCAxOS42ODggMTkuNjg4LTguODE0IDE5LjY4OC0xOS42ODh6IiBmaWxsPSIjMDA3ZjBhIiBzdHJva2U9IiMwMDdhMGEiLz48cGF0aCBkPSJtMTA5IDU5LjVoLTEwOC41di05aDEwOC41eiIvPjxwYXRoIGQ9Im01OSAxMDloLTkuMjV2LTEwOC41aDkuMjV6Ii8+PC9nPjwvc3ZnPg==?fill=%23232323&amp;fill-opacity=1&amp;outline=%23232323&amp;outline-opacity=1&amp;outline-width=1"/>
                <se:Format>image/svg+xml</se:Format>
              </se:ExternalGraphic>
              <!--Plain SVG fallback, no parameters-->
              <se:ExternalGraphic>
                <se:OnlineResource xlink:type="simple" xlink:href="base64:PHN2ZyBoZWlnaHQ9IjEwOS41cHQiIHZpZXdCb3g9IjAgMCAxMDkuNSAxMDkuNSIgd2lkdGg9IjEwOS41cHQiPjxnIGZpbGw9IiMwMDA0MDAiIHN0cm9rZT0iIzAwMCI+PHBhdGggZD0ibTc0LjA2MyA1NC43NWMwLTEwLjg3My04LjgxNC0xOS42ODgtMTkuNjg4LTE5LjY4OHMtMTkuNjg3IDguODE1LTE5LjY4NyAxOS42ODggOC44MTQgMTkuNjg4IDE5LjY4OCAxOS42ODggMTkuNjg4LTguODE0IDE5LjY4OC0xOS42ODh6IiBmaWxsPSIjMDA3ZjBhIiBzdHJva2U9IiMwMDdhMGEiLz48cGF0aCBkPSJtMTA5IDU5LjVoLTEwOC41di05aDEwOC41eiIvPjxwYXRoIGQ9Im01OSAxMDloLTkuMjV2LTEwOC41aDkuMjV6Ii8+PC9nPjwvc3ZnPg=="/>
                <se:Format>image/svg+xml</se:Format>
              </se:ExternalGraphic>
              <!--Well known marker fallback-->
              <se:Mark>
                <se:WellKnownName>square</se:WellKnownName>
                <se:Fill>
                  <se:SvgParameter name="fill">#232323</se:SvgParameter>
                </se:Fill>
                <se:Stroke>
                  <se:SvgParameter name="stroke">#232323</se:SvgParameter>
                  <se:SvgParameter name="stroke-width">1</se:SvgParameter>
                </se:Stroke>
              </se:Mark>
              <se:Size>32</se:Size>
            </se:Graphic>
          </se:PointSymbolizer>

When I inspect the SLD parser output I obtain this symbolizers object:

[
    {
        "kind": "Icon",
        "image": "base64:PHN2ZyBoZWlnaHQ9IjEwOS41cHQiIHZpZXdCb3g9IjAgMCAxMDkuNSAxMDkuNSIgd2lkdGg9IjEwOS41cHQiPjxnIGZpbGw9IiMwMDA0MDAiIHN0cm9rZT0iIzAwMCI+PHBhdGggZD0ibTc0LjA2MyA1NC43NWMwLTEwLjg3My04LjgxNC0xOS42ODgtMTkuNjg4LTE5LjY4OHMtMTkuNjg3IDguODE1LTE5LjY4NyAxOS42ODggOC44MTQgMTkuNjg4IDE5LjY4OCAxOS42ODggMTkuNjg4LTguODE0IDE5LjY4OC0xOS42ODh6IiBmaWxsPSIjMDA3ZjBhIiBzdHJva2U9IiMwMDdhMGEiLz48cGF0aCBkPSJtMTA5IDU5LjVoLTEwOC41di05aDEwOC41eiIvPjxwYXRoIGQ9Im01OSAxMDloLTkuMjV2LTEwOC41aDkuMjV6Ii8+PC9nPjwvc3ZnPg==?fill=%23232323&fill-opacity=1&outline=%23232323&outline-opacity=1&outline-width=1",
        "size": 32
    }
]

Where the "format" property is missing.

Expected behavior

[
    {
        "kind": "Icon",
        "image": "base64:PHN2ZyBoZWlnaHQ9IjEwOS41cHQiIHZpZXdCb3g9IjAgMCAxMDkuNSAxMDkuNSIgd2lkdGg9IjEwOS41cHQiPjxnIGZpbGw9IiMwMDA0MDAiIHN0cm9rZT0iIzAwMCI+PHBhdGggZD0ibTc0LjA2MyA1NC43NWMwLTEwLjg3My04LjgxNC0xOS42ODgtMTkuNjg4LTE5LjY4OHMtMTkuNjg3IDguODE1LTE5LjY4NyAxOS42ODggOC44MTQgMTkuNjg4IDE5LjY4OCAxOS42ODggMTkuNjg4LTguODE0IDE5LjY4OC0xOS42ODh6IiBmaWxsPSIjMDA3ZjBhIiBzdHJva2U9IiMwMDdhMGEiLz48cGF0aCBkPSJtMTA5IDU5LjVoLTEwOC41di05aDEwOC41eiIvPjxwYXRoIGQ9Im01OSAxMDloLTkuMjV2LTEwOC41aDkuMjV6Ii8+PC9nPjwvc3ZnPg==?fill=%23232323&fill-opacity=1&outline=%23232323&outline-opacity=1&outline-width=1",
        "size": 32,
        "format":"image/svg+xml"
    }
]

Bug

Describe the bug
vue3 + vite
import SLDParser from "geostyler-sld-parser";
const parser = new SLDParser();
return error when call parser.readStyle

but when i use <script src="/node_modules/geostyler-sld-parser/browser/sldStyleParser.js"></script> work fine;

Screenshots

Additional context
Add any other context about the problem here.

Using ts packaging can cause third-party type errors

position:
node_modules\fast-xml-parser\src\xmlbuilder\orderedJs2Xml.js
error:
TypeError: (0 , w1.default)(...).find is not a function

Bug

opacity disappears when parsing from Json to sld (PolygonSymbolizer, TextSymbolizer)

can check in your example: https://geostyler.github.io/geostyler-demo/