terrestris/basigx

BasiGX is an ExtJS package used to create modern GIS-Applications based on ExtJS 6, GeoExt 4 and OpenLayers 6.5.0. It consists of multiple components that helps the developer to put together a customized app quickly.

basigx's Issues

CoordinateMousePositionPanel starts with NaN

The BasiGX.view.panel.CoordinateMousePositionPanel starts with the X and Y text boxes displaying NaN and a red error underline as shown below:

To avoid the red error underlining when opening the app the view model can be set to show zeros instead:

            viewModel: {
                data: {
                    xVal: 0,
                    yVal: 0
                }

Alternatively the map's starting center could be used (pull request to follow).

Release v1.0.5 / v1.1.0

It would be very helpful to have another release (either v1.0.5 or better v1.1.0), so the very cool
CSW-form to retrieve WMS layers through an OGC CSW (3d0f9c6) would become usable with a npm installed version of BasiGX.

Thanks for this cool feature!

Dependency for 'ux' cannot be resolved when installing BasiGX

Very likely introduced by #65:

sencha package get BasiGX

Sencha Cmd v6.0.2.14
[ERR] Cannot satisfy requirements for "ux"!
[ERR]    The following versions cannot be satisfied:
[ERR]       BasiGX: ux (No matches!)
[ERR] Cannot resolve package requirements

Add examples to show the functionality / widgets that BasiGX provides

In order to show how to use this package, we should have simple examples of mostly everything we have in this package.

This would also testing of PRs way easier.

Failing build pipeline

The build pipeline is currently failing, see e.g. here:

Run actions/setup-ruby@v1
------------------------
NOTE: This action is deprecated and is no longer maintained.
Please, migrate to https://github.com/ruby/setup-ruby, which is being actively maintained.
------------------------
Error: Version 2.[6](https://github.com/terrestris/BasiGX/actions/runs/4042246182/jobs/6949723574#step:8:7) not found

Update gh-pages

Since travis is not usable any more we need a gh-action to update this.

Make hardcoded UI-strings translatable

Currently a lot of string that'll end up visible to the user are not configurable or translatable. We need to change that.

Remove eslint-config-openlayers dependency

Obviously the latest version of eslint-config-openlayers isn't compatible with BasiGX anymore, e.g. it is assumed that the project runs inside an ES6 environment. Therefore we should remove the dependency while preserving the desired ESlint configurations by merging them into the project's .eslintrc.

See #277.

Remove duplicate methods in SLD utils

The two classes
https://github.com/terrestris/BasiGX/blob/master/src/util/SLD.js
and
https://github.com/terrestris/BasiGX/blob/master/src/util/SldOpenlayersConverter.js
have some duplicated methods.
This should be cleaned up

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

v1.0.4 not published at npmjs.com

The version v1.0.4 of BasiGX is not publishes at https://www.npmjs.com/package/@terrestris/basigx

Create util / parent class for form AddWms and CSW

Both mentioned classes share some amount of identical code. We should make a util or parent class for them.

Version management / update strategy

I wondered if there is (or if there are plans) for a version management of BasiGX. Since the version number is 1.0.0 from the beginning the automatic upgrade of this package with Sencha CMD seems to be difficult.

Are there any stategies how this is handled at the moment by other devs?
Are there plans to introduce a sustainable version management?

HsiButton should use pressed state of ExtJS button

Currently the "HsiButton" (BasiGX.view.button.Hsi) does not use the toggle mechanism of its base class Ext.Button. Instead a custom handler function is applied which toggles a custom member variable buttonPressed. This has the effect that if the pressed state of the HsiButton is changed programatically via btn.setPressed(...) the functionality is not deactivated.

By using a toggle listener this could be fixed. The current state is available by the property pressed so no need for a custom property. This would be more intuitive and will integrate better to the whole framework.

`karma-chrome-launcher` does not work with node > 12

If karma-chrome-launcher gets installed with node > 12, it does not work. That means npm test fails because it cannot connect to the browser. If it is however installed with node <= 12, it does work, even if the npm test command was called with node > 12.

I added node <= 12 to the package.json engines field.

Invalid BasiGX.view.form.AddWms when using combobox for URLs

BasiGX.view.form.AddArcGISRest and BasiGX.view.form.AddWms both allow a URL to be entered in a textbox, or via a URL. The form however is only valid if the textbox has a value - when using a combobox this is never the case.

A workaround is to add the following listener to the forms:

  listeners: {
      render: function () {
          var me = this;
          var cmb = me.down('combobox[name=urlCombo]');
          cmb.on('select', function () {
              var val = cmb.getValue();
              // following field is not used when there is a combobox but the form is invalid when set to blank
              me.down('textfield[name=url]').setValue(val);
          });
      }
  }

WFS Filters not working with a MapServer 7 backend

The OGC filters currently generated by BasiGX.util.WFS cause errors when requesting features from MapServer (with a GET request) such as:

msWFSGetFeature(): WFS server error. Invalid or Unsupported FILTER in GetFeature : <Filter><BBOX><PropertyName>msGeometry</PropertyName><Envelope><gml:lowerCorner>-1399714.8619581475 6740828.650413123</gml:lowerCorner> <gml:upperCorner>-289237.7150311069 7405525.048381017</gml:upperCorner></gml:Envelope></ogc:BBOX><gml:Envelope xmlns:gml=http://www.opengis.net/gml srsName=EPSG:3857><gml:lowerCorner>-1399714.8619581475 6740828.650413123</gml:lowerCorner><gml:upperCorner>-289237.7150311069 7405525.048381017</gml:upperCorner><Envelope></BBOX><Filter>

It appears these are caused by the following:

• any namespace properties in a tag e.g. xmlns:gml=http://www.opengis.net/gml
• an additional AND wrapper around the filter
• use of BBOX and Intersects?

An example of a working BBOX filter is:
<Filter><BBOX><PropertyName>msGeometry</PropertyName><Box%20srsName='EPSG:3857'><coordinates>-1009073.7780155,6855880.1040363 -754844.22198452,6990867.8959637</coordinates></Box></BBOX></Filter>

The above problems may be a MapServer issue rather than invalid filters.

Closure Compiler Warnings

In ExtJS 6.2 the following warnings are shown when building BasiGX:

[WRN] C1005: Closure Compiler Warning (Unnecessary escape: '\{' is equivalent to just '{') -- lib\BasiGX\src\plugin\Hover.js:51:46
[WRN] C1005: Closure Compiler Warning (Unnecessary escape: '\{' is equivalent to just '{') -- lib\BasiGX\src\plugin\Hover.js:51:48
[WRN] C1005: Closure Compiler Warning (Unnecessary escape: '\}' is equivalent to just '}') -- lib\BasiGX\src\plugin\Hover.js:59:46
[WRN] C1005: Closure Compiler Warning (Unnecessary escape: '\}' is equivalent to just '}') -- lib\BasiGX\src\plugin\Hover.js:59:48

Release a new version (maybe 3.2.0)

Since the last release of the version 3.1.0 a lot of things happened, see v3.1.0...master. In order to use this changes easily via npm a new release would be very helpful. Maybe a version 3.2.0, since there are no breaking changes at first sight, but might be double checked before the release.

What do you think @terrestris/devs ?

Unknown definition for dependency: BasiGX.view.button.Base

The dependenxy for BasiGX.view.button.Base can not be resolved when building an application (sencha app build).

[ERR] Failed to resolve dependency BasiGX.view.button.Base for file BasiGX.view.button.ZoomIn
[ERR] 
[ERR] BUILD FAILED
[ERR] com.sencha.exceptions.ExNotFound: Unknown definition for dependency : BasiGX.view.button.Base

http://epsg.io no longer accepts COR requests

Used by the BasiGX.view.panel.CoordinateMousePositionPanel if a site is served over http the following errors are logged:

Access to XMLHttpRequest at 'http://epsg.io/?q=29902&format=json&_dc=1659951158351' from origin 'http://localhost:1841' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The easy fix is to ensure requests are also https (pull request to follow).

It would also be useful to avoid any reliance on epsg.io for the tool to avoid external requests, however the way the tool is currently figured requires promises that return JSON in the same format as epsg.io (with the required properties being name, unit, code and proj4:

{
    "number_result": 1,
    "results": [
        {
            "accuracy": "",
            "area": "World between 85.06°S and 85.06°N.",
            "authority": "EPSG",
            "bbox": [
                85.06,
                -180.0,
                -85.06,
                180.0
            ],
            "code": "3857",
            "default_trans": 0,
            "kind": "CRS-PROJCRS",
            "name": "WGS 84 / Pseudo-Mercator",
            "proj4": "+proj=merc...",
            "trans": [
                9189,
                9690,
                9691,
                15960
            ],
            "unit": "metre",
            "wkt": "PROJCS[\"WGS 84 /..."
        }
    ],
    "status": "ok"
}

Initial tests in a branch at https://github.com/terrestris/BasiGX/compare/master...geographika:BasiGX:epsg?expand=1

moveFeature in util.Animate not working in production build of ol3

The moveFeature method fails when using a production build of ol3, as the property flatCoordinates of a geometry only exists in a ol-debug version:

https://github.com/terrestris/BasiGX/blob/master/src/util/Animate.js#L103

Add tests for our components

We need way more real tests, as we currently have.

Changes in GeoExt are not considered

As the BasiGX.pkg contains the GeoExt.pkg changes to GeoExt are not considered.

This leeds to the following problem:

Having an app which requires BasiGX (and GeoExt) you can not get the current GeoExt.pkg because if you build your app sencha fetches the packages and gets GeoExt (outdated) from BasiGX and not from the correct GeoExt repo.

Maybe this is realted to the changes from c1a15d9

Wrong version number published to npm

Using the current release script will lead to a release with an invalid version number on npmjs.com.

Reason: Because the target files will be copied to the dist folder before the version number will be increased by np, the package will be released with the preexisting verison number.

Note: The release of version 1.1.0 has been fixed manually.

Update outdated install info in README

We should not be advocating the sencha package way any longer