terrestris / ol-util

A set of helper classes for working with OpenLayers
https://terrestris.github.io/ol-util
BSD 2-Clause "Simplified" License
48 stars 22 forks source link

REQUEST: Implementation stubs and a demonstrable sampling of utils #572

Open NerdyDeedsLLC opened 2 years ago

NerdyDeedsLLC commented 2 years ago

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. 💔

marcjansen commented 2 years ago

Hi @NerdyDeedsLLC, thanks for your feedback. Rest assured that we do not take it negatively; no one was offended AFAICT.

I think I should clarify some things that might be not as clear as possible.

This repository contains helper classes and functions for working with OpenLayers; we do not consider ourself to be striving to provide "all and every" "bells and whistles" for OpenLayers.

We created this repository to scratch our own itch (i.e. solving our recurring challenges in a sane matter), not to be the number one go to OpenLayers utility package.

I'd gladly see this repo be improved at certain points you mention, and I'd really like your input here. Do you think that links in the API documentation would already help? If so, please tell us what made you stagger specifically, and we'll see what we can do. Also please list pain points which might be adressed in the README (with more general know-how you think is needed to understand this package). Of course we'd appreaciate any PRs in this direction, ;-)

I hope this clarifies our motivation behind this project and helps a bit; or at least lays out a path on how we can improve together.