Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For #111 : dynamic layers in Wegue format #113

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

justb4
Copy link
Collaborator

@justb4 justb4 commented Mar 13, 2020

Introduces a new Wegue Layer type LAYERCOLLECTION which is mainly a URL pointing to a remote endpoint (or file local to the Wegue App) that contains an array of Wegue Layers (which in theory could even again contain LAYERCOLLECTIONs).

  • As the loading of the URL (via fetch()) is asynchronous, several functions are now async/await (ES2015 syntax).
  • test added, NB final version needs to point to Wegue GH link

Later similar "expanding layer types" could be added for WMS, WFS etc (via GetCapabilities) and even OGC OpenAPI Features ("WFSv3").

@justb4 justb4 changed the title #111 dynamic layers in Wegue format For #111 : dynamic layers in Wegue format Mar 13, 2020
Copy link
Collaborator

@chrismayer chrismayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @justb4. Two questions:

1.) Why was it necessary to delete test/unit/specs/ol/Map.spec.js
2.) Any reason you removed the alias me for this in the existing code? Creates a lot of unrelated diffs in your changeset.

@justb4 justb4 mentioned this pull request Mar 25, 2020
13 tasks
@justb4
Copy link
Collaborator Author

justb4 commented Apr 1, 2020

@chrismayer sorry, your questions escaped me.

ad 1) test/unit/specs/ol/Map.spec.js was a duplicate of test/unit/specs/components/ol/Map.spec.js.

ad 2) me = this is uneccessary in ES2015 with arrow functions

Ok strictly not part of issue, but cleanup which I considered too minor for issue/PR.

@chrismayer
Copy link
Collaborator

Thanks for clarification.

One further point: Due to asynchronous handling the position in the mapLayers array is not resprected for type LAYERCOLLECTION. In the app-conf.json the demo layer for a LAYERCOLLECTION is laced somewhere in the middle of the mapLayers array but is rendered topmost in the layer stack.

@justb4
Copy link
Collaborator Author

justb4 commented Apr 9, 2020

Hmm, yes. The Layers coming from the LAYERCOLLECTION are reversed as to have them internally added bottom to top just like the regular Layers. But yes, the async nature could lead these always added as last/topmost. Tough problem to solve, if ever a problem in practice: 1) usually the entire app is configured from a single LAYERCOLLECTION or the latter is a series of overlay Layers on top of regularly configured baselayers (Geolicious use case).

Solution would be to "stack" any remaining regular Layers (not adding them) after the LAYERCOLLECTION and add them after the async finishes. Would be interesting with multiple LAYERCOLLECTIONs....

As an alternative, for progress, we could merge this PR and open a new issue for "LAYERCOLLECTION messes up Layer stack ordering"...

@JakobMiksch JakobMiksch marked this pull request as draft February 2, 2022 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants