Suggestion: We should integrate semantic-release for automatic releases.

For example, https://github.com/terrestris/react-geo already supports it

When I use ol-util in a vanilla Vue3 app, I get this error:

It seems to be a problem with the dependency shpjs and maybe also in combination with vite . I could not find a solution yet.

How to reproduce:

Create a new Vue3 app

npm create vue@latest

Select this options:

install dependencies

npm i
npm i ol  @terrestris/ol-util

in App.vue add this to the <script> tag:

<script setup>
import HelloWorld from './components/HelloWorld.vue'
import TheWelcome from './components/TheWelcome.vue'
import {onMounted} from 'vue'
import TileWMS from 'ol/source/TileWMS'
import { LayerUtil } from '@terrestris/ol-util'


onMounted(() => {
   const wmsSource = new TileWMS()
   const result =  LayerUtil.isOlSourceTileWMS(wmsSource)
   console.log(result)
})

</script>

then run the app:

npm run dev

then the error from above should appear.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Current state: ol-util supports js-doc types which can be checked via typecheck. There were already several improvements by @simonseyock:

• #635
• #631
• #630
• #624

Do you think ol-utli could be migrated to typescript entirely?

In my opinion, full typescript support will make writing and importing types easier when working with other typescript projects.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

The method getFeatureTypeNameFromGetFeatureInfoUrl should be rewritten to become more generic in its usage for other OGC requests or should at least extend the functionality of a generic method. For example it should also possible to pass other requests like an WMS GetMap or an WFS GetFeature to obtain the list of a given parameter, e.g. the LAYERS values. The signature could look like:

getValueFromRequestParameter(request: String, parameter: String)

See #147 (comment)

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Hello, i'm trying to run this lib with Angular. But i'm not being able to run it properly.

Error that occurs

core.mjs:6406 ERROR Error: Uncaught (in promise): ReferenceError: global is not defined
ReferenceError: global is not defined
    at 62271 (browser.js:2:16)
    at __webpack_require__ (bootstrap:19:1)
    at 31628 (browser.js:2:17)
    at __webpack_require__ (bootstrap:19:1)
    at 56586 (binaryajax-browser.js:2:17)
    at __webpack_require__ (bootstrap:19:1)
    at 74579 (binaryajax-fetch.js:2:18)
    at __webpack_require__ (bootstrap:19:1)
    at 78162 (index.js:7:20)
    at __webpack_require__ (bootstrap:19:1)
    at resolvePromise (zone.js:1211:31)
    at resolvePromise (zone.js:1165:17)
    at zone.js:1278:17
    at _ZoneDelegate.invokeTask (zone.js:406:31)
    at Object.onInvokeTask (core.mjs:26510:33)
    at _ZoneDelegate.invokeTask (zone.js:405:60)
    at Zone.runTask (zone.js:178:47)
    at drainMicroTaskQueue (zone.js:585:35)

To make it work I had to put this script in index.html

<script>
    if (global === undefined) {
      var global = window;
    }
  </script>

There is some other way to make it work without this workaround?

Currently, multiple filter attributes are supported that all check for the same search term. It would be nice if it would also be possible to handle multiple search terms on 1..N attributes. Could be useful, e.g. if you want to get multiple features by id within a single request.

If a placeholder in a templateString is null or undefined, the resulting string then also contains null and/or undefined. IMHO it would be nicer if an empty string would be added, instead.

Example:
templateString "{{name}} ({{id}})"
with name=null and id=25
returns null (25)

should return (25)

Suggestion to add a new WFS utility class with methods to get and parse WFS requests.
Starting with :

• DescribeFeatureType
• GetFeature

Maybe create a joint WFS Util class that would include the already existing WfsFilterUtil

Okay, I totally get that you guys have docs (auto-generated, meaning your code is commented, too 💕), but here's the thing: everything in this library presupposes a deal of pre-existing comprehension about what these things do and what these terms mean. "Helper class to parse capabilities of WMS layers" means nothing if you know neither what a "WMS layer" is, nor the possible capabilities the layer could possess are. Though I suspect I could intuit both with an example.

I can absolutely sit down and read the code, install the package, then try to scrape together some working PoC's to see if its actually doing what I'm interpreting your docs to mean. The problem is, I'm trying to evaluate if OpenLayers is going to even be capable of serving our needs (and since, like most users of such a mapping system, I have specific things I need to make the map DO). I literally 5 minutes ago was in a huddle with a couple of our other devs and spoke the following words:
"Hey awesome! There's a utilities extension library with animation stuff, and geometry stuff... this sounds like it might be perfect! I'll check it out!"

Exxxxxxcept I can't actually see or understand what any of these things ARE without fully implementing both OL and this repo, and then coding examples. At which point, if I'm WRONG, it's already too late.

Please, please understand me here: I'm not trying to be entitled or ungrateful. I contribute in and to the OS ecosystem too, and the last thing I'd want is some jerk stomping in and making demands of the FREE code we've put weeks into. It's not like that. What I'm saying is the package itself will have a LOT more traction when its use doesn't mean days of afterhours guesswork (because my employer is sure AF not gonna PAY me to tinker with it for dozens of hours) just to see if this is actually even feasible.

Speaking just for myself, here: as the stated official "bells and whistles" source for OL, this repo WOULD BE - and I say this as a potential user in this exact position - the decisive tipping point between "these are the droids I'm looking for" and "move along". I'm like 90% that OL is the way to go on this particular req, but - and I know every one of you can relate to this - we've been given 4 weeks' work to do in 3 weeks' time, with only 2 weeks' notice, and working from one SERIOUSLY weak set of specs, and I can't take any chances. While I suspect this will simply result in my wasting still MORE time trying to hunt down alternatives, my employer's policy is unless a package 100% satisfies a critical need, we have to eval a minimum of 3, then have a quorum to get buy-in from the other devs.

I dunno. Like I said: I'm neither criticizing nor insisting, and I'm honestly sorry if I've offended anyone. Thank you for your hard work, and for being cool enough to open it up to the community. I simply feel it's a tragedy when countless hours of code that is very likely perfect for a need that it was very likely written specifically to address is passed on, simply because there's no way to quickly see it in action. 💔

Currently, there's no ability to choose different units (only in km/m) for two methods formatLength(), formatArea() in MeasureUtil. It would be great if you could add an option to handle different units (cm/mm/...).

splitByLine function in GeometryUtil produces erroneous results for input geometry that is not WGS84 (for example EPSG:25832) since geometry is transformed to WGS84 before. In particular:

• some polygons are missing after split operation
• segments of original polygon are transformed twice and therefore they will not be the same as in the original geometry

jsts would be better alternative here

The devDependency babel-eslint was updated from 10.0.3 to 10.1.0.

🚨 View failing branch.

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

babel-eslint 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 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.8.0 to 7.8.3.

• The devDependency @babel/core was updated from 7.7.7 to 7.8.0.
• The devDependency @babel/preset-env was updated from 7.8.0 to 7.8.2.
• The devDependency @babel/preset-react was updated from 7.7.4 to 7.8.0.

🚨 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 🌴