wegue-oss/wegue

Template and components for webmapping applications with OpenLayers and Vue.js

wegue's Issues

Wegue project logo

Having a project logo would be very nice.

One very rough first idea: since the name is pronounced like the Japanese cattle breed "Wagyū" it would be cool if the logo contains a cow / bull / cattle / buffalo / etc. And maybe something what gets the connect to the "geo" world.

Application config and directory restructure

This issue relates/depends on to #98 but goes a bit further.

A typical Wegue project will clone the Wegue GH repo, add both new custom (Vue) components and/or modify core Wegue code and components. Currently this implies changes to files under the src/ dir. Merging-in changes from upstream Wegue GH repo later gets more and more tedious and error-prone.

Ideally we would not need to touch any files under src/ but develop app-specific components and other resources under the app/ tree. This should also be a step towards making Wegue a real app-framework with a CLI to create a starter-app under any other dir/ repo i.s.o. within a clone of the Wegue repo under app/. The advantage of this process though is that one constantly have all files at disposal, also e.g. within debuggers.

Via this issue I propose the following changes:

• remove app/.gitignore
• place app-conf.json under app/static dir (via #98)
• implement/merge the simple solution which first first looks for app config under app-dir.
• put app-specific components and if possible modified Wegue components under app-dir
• make an app/components/ shadow dir with app-specific/Wegue-app-specific-modified components
• make app/static a shadow dir from static/: with app-specific resources (e.g. css, icons etc) that overwrites static in builds
• reference both app and src Vue components (requires build config changes)
• extend Wegue CLI npm run init:app

For the latter the CLI npm run init:app needs to copy the following Wegue files under app-dir: WguAppTemplate, AppFooter, AppHeader. These will be app-specific anyway at some point.

Note that we already successfully applied this restructuring within the Geolicious project for NPLH. Need to see what is the best strategy to pull-in this work via https://github.com/Geolicious/wegue.
That huge change costed little dev-time, and helps with future Wegue dev-workflows, much the way e.g. many template-systems like Django work (shadowing a subset of files with a searchpath).

Add Docker support

Also given the configuration convention coming with Wegue, a Dockerfile that runs Wegue built for/in production mode would be beneficial to users. Especially re-using that Image for custom configs that may be applied via Docker Volume Mapping, directly (-v) or through a Docker Compose file.

A minimal Wegue Dockerfile will be the first step. Already tested with a minimally-sized (35MB) Image based on node:lts-alpine as builder. Can do a PR for this as well.

Add FeatureGrid component

Add a grid (table) component which can be synchronized with a vector layer, so the features of the vector layer are shown as records in the grid.

1.) Detect an appropriate and reusable grid component for vue / vuetify

2.) Implement the FeatureGrid based on the common grid component as part of Wegue

Add (dev) discussion space for Wegue project

Currently the contact for information/support for Wegue is an email address. In order to engage at least developers, having some kind of common discussion space would be nice.

A mailing list is IMHO a bit old-fashioned. I use/like Gitter a lot, as it can be coupled to a single GH repo, also listing repo-activities like commits etc. But also Slack or even Telegram-groups are used these days. @chrismayer you can make a choice what suits you if you think such a discussion space is useful.

List public applications based on Wegue

It would be very cool to have a list of public applications , which are based on Wegue. This would give an overview what can be achieved and might motivate others totry it out or use Wegue for the next project.

Could be placed in the README in a first step.

Encapsulate app footer as own component

The app footer, which is currently defined inline in the WguApp should be modelled as an own Vue / Wegue component.

Provide sizing in Image/Icon Vector Style Layer config

Wegue Vector Layers can be configured with Style definitions. These are mapped to OpenLayers Style objects by the Wegue OLStyle.js Factory.

For Icon Styles one can configure attributes like iconUrl, anchor etc. But there is currently no means to influence sizing (e.g. for SVG Icons), so icons get their original size on the Map.
More advanced would even be to size icons with the Map's Zoom level, but let's first keep it simple: allow a size or scale parameter in the Style config, for example:

    {
      "type": "VECTOR",
      "lid": "dutch_castles",
      "name": "Dutch Castles",
      "url": "https://demo.pygeoapi.io/master/collections/dutch_castles/items",
      "formatConfig": {
        "dataProjection": "EPSG:4326"
       },
      "format": "GeoJSON",
      "visible": true,
      "selectable": true,
      "style": {
        "iconUrl": "./static/icon/castle2.png",
        "scale: 2",      <===========================
        "anchor": [0.5, 37],
        "anchorXUnits": "fraction",
        "anchorYUnits": "pixels"
      },
      "styleSelected": {
        "iconUrl": "./static/icon/castle2-select.png",
        "scale: 2",    <===========================
        "anchor": [0.5, 37],
        "anchorXUnits": "fraction",
        "anchorYUnits": "pixels"
      }
    },

NB size did not seem to have any influence when tried in OLStyle.js, but scale has.
So scale seems best option now. A good first issue!

There are probably more parameters, this is also a bit why we are in favor of a JavaScript Wegue config.

Share function/button for permalink/map context

Issue #38 will provide permalink functionality, i.e. being able to gather, provide and load a map-context (center+zoom or extent, rotation, layers,..) using URL location query/hash.

This issue is to provide the user with a "share" option, usually via a "Share Button". This function will interwork with the permalink-function (component/ol/PermalinkController class) of #38 . The following is foreseen:

• optional permalink button in header menu
• when clicked minimally a "copy" option for the share-URL, plus:
• option: "embed" to copy an iframe for embedding into a website
• option: "embed" a mailto to email the share-URL

The existing permalink "apply" (load) can be reused when a user accesses the app with a share-URL.

An example can be found here (open the tab "Teilen").

Dynamic Layer configuration - Wegue format

The current way to configure Layers is to define these in the Wegue config file like static/app-conf.json.

But there are scenario's where a remote server provides an API Endpoint that supplies a "Layer List". OGC Standard examples are WMS Capabilities documents. The GeoExt.tree.WMSCapabilitiesLoader is an example of a client that expands this to Layer objects.

And with the new OGC REST API an OpenAPI Feature "Collections" as a JSON doc, see example here.

These should be addressed in separate issues. The issue here suggests a more direct approach and format: as Wegue Layers are already JSON nodes, a remote endpoint (or local file under e.g. static) could provide an array of Wegue Layer definitions like:

[
    {
      "type": "VECTOR",
      "lid": "dutch_windmills",
      "name": "Dutch Windmills",
      "url": "https://demo.pygeoapi.io/master/collections/dutch_windmills/items",
      "formatConfig": {
        "dataProjection": "EPSG:4326"
       },
      "format": "GeoJSON",
      "visible": true,
      "selectable": true,
      "style": {
        "iconUrl": "https://someiconserver.io/windmill2.png",
        "anchor": [0.5, 37],
        "anchorXUnits": "fraction",
        "anchorYUnits": "pixels"
      }
    },
    {
      "type": "VECTOR",
      "lid": "dutch_castles",
.
.
]

Such a Wegue Layer Def could be defined as a special Layer type with the endpoint URL and possibly some other parameters. Something at minimum:

    {
      "type": "OSM",
      "lid": "osm-bg",
      "name": "OSM",
      "isBaseLayer": true,
      "visible": true,
      "displayInLayerList": false
    },
    {
      "type": "WEGUELAYERCOLLECTION",
      "url": "https://some.server.io/api/layer_list"
    },

Add map loading progress component

Add a MapLoadingProgress component giving the user feedback that there is an ongoing loading action by a layer.

The UI should be implemented by Vuetify's Progress component. For the binding to the OL map layers see https://openlayers.org/en/latest/examples/image-load-events.html or http://terrestris.github.io/BasiGX/master/docs/#!/api/BasiGX.view.MapLoadingStatusBar as examples and inspiration.

The functionality should be provided as Vue component so it gets usable anywhere in a Wegue application. Also the colour of the MapLoadingProgress should be changed according to the base colour of the Wegue app (as it is e.g. done for zoom buttons).

Add WFS layer support

Add support for WFS layers in the mapLayers section of the application configuration.

Make AppHeader-title settings more flexible

This is a follow-up issue based on #114.

It seems that it would be useful to have the additional possibility to set custom HTML in the header title similar to the Footer component. So placing a HTML string in the app config's title property would be interpreted.

Suggestion by @justb4

<v-toolbar-title><span v-html="title"/></v-toolbar-title>

JavaScript files for Wegue app configuration

The current implementation uses a JSON file for application configuration. A JSON file is fetched at startup, read and parsed. Though at first sight this seems user-friendly, in practice this can become a rather limiting factor for the following reasons:

1. as we would define more and more rich Wegue components and especially OL Layer types (think of WMTS, Tile Grids etc), the .json config-file and its handling will need incremental updates, eventually defining all object-types and attributes as specified in e.g. OpenLayers.

2. Also a user may be in the dark to what values and types are allowed as there is no JSON Schema (like a DTD/XSD in XML). Though that could be defined.

3. It is hard to use/include multiple files, for example when components need a secret API-key and you would like to provide this or other config-parts via a separate file or API.

4. it is hard to discern among Test and Production configs, at least have some smart way to have a common config-part and a separate test and production-part for example based onlocation.href at runtime . (Think of test and production OGC services).

5. Sometimes some additional-config logic (if/then/else) is required.

6. complex object configs with (shared) subobject-configs are hard to specify as referencing needs to be done with add-hoc syntax. For example: a WMTS Layer config would need a TileGrid/Matrix spec. That TileGrid spec may need to be shared with multiple WMTS Layer specs. In JavaScript this is simply an JS object reference where the TileGrid/Matrix spec would be defined only once.

7. (minor) no comments are allowed in JSON files.

Frameworks where the core concept is to declaratively specify/construct an app from a configuration, often apply the framework's programming language as config language. Obvious examples are Python Django (uses settings.py though that is not really enforced) and many Flask applications. And what to think of Node.js-based apps like WebPack, Babel, ESLint, VueLoader, and many more. These all use JavaScript config specs!

The Heron Mapping Client framework based on GeoExt, ExtJS and OL.also uses JavaScript for configuration specification, to specify both the Layout (like a Wegue App Template) and the classes with config-values to be instantiated. Internally Heron utilizes the ExtJS (v3, yes old) xtype to automagically create and instantiate all objects without any other specific Builder/Factory logic.

Though Heron is dated in JS-technology, the underlying concept of declaratively building an Application using only .js files has appealed many users and application managers even without programming skills. The JavaScript (Object) syntax is simple enough to learn.

The main weakness in Heron config was that a "schema" was missing, making it hard for users to figure out what parameters are required. This could be overcome by using a JavaScript schema component like https://www.npmjs.com/package/schema-object. Though at some point in Heron we used JSDoc with code comments to extract that information (bit like JavaDoc).

In addition I think/propose to have the config structure/schema modeled after the actual Wegue components: so to have a Map object referring to an array of Layer objects.

In Wegue the combination of app-template coupled with a .js config for that template could become an extremely powerful, declarative way to create apps and reusable apps/configs. But using a JSON config convention may not be quickest way to get there.

I realize this is a big change, but better to move now, maybe even have a transition period (as the config internally is a big JS object assigned in main.js:
Vue.prototype.$appConfig = appConfig.

AppLogo and AppHeader-title: provide for optional hyperlink

In cases the AppLogo Wegue component implemented in AppLogo.vue should provide a hyperlink for when a user clicks the logo. This feature should be optional via a new AppLogo config attribute logoLink.
Possibly also the link target like "_blank" could be configured in logoLinkTarget.

Also can be applied to the title (v-toolbar-title) in the AppHeader implemented in AppHeader.vue: provide optional config for titleLink and titleLinkTarget.

Toggle layer visibility when clicking an item in the LayerList

Currently a layer's visibility can only be toggled by checking / unchecking the corresponding checkbox. For a better usability this should also happen, when the layer item (showing the layer name) is clicked.

Group tools in a menu

Since the toolbar might be too narrow on small screens it would be helpful to pack the tools in a menu.

main.js: OpenLayers CSS should be imported before Wegue App template

Found in Geolicious NPLH project: changing OL Zoom Button font color CSS style in Map.vue from the default (OL CSS) white to a dark, e.g. HSL 0,0,30% (RGB #4D4D4D) worked in dev mode but did not have effect in production WebPack build.

Quickly reproducable in Wegue master with example:

• in src/components/ol/Map.vue add in the <style> section:

  .ol-control button {
      color: hsl(0,0%,30%);
  }

(should make Zoom buttons dark)

• npm run dev observe zoom buttons are indeed dark
• npm run build (production build) and run in webserver: zoom buttons are still white!

Analysis:

• in the app CSS of the production build the OL CSS was included after the Wegue/Vue CSS (but not in the dev injected CSS server)
• in main.js the OL CSS was imported via a require statement after Vue/App template (.vue) imports.
• it is not related to WebPack config nor changes we made there (what we first though)

It is down-to-earth include/import ordering. So the fix is easy: in main.js change:

import Vue from 'vue';
import Vuetify from 'vuetify';
import WguApp from '../app/WguApp';
import UrlUtil from './util/Url';
import 'vuetify/dist/vuetify.min.css';

Vue.use(Vuetify);

require('../node_modules/ol/ol.css');

require('./assets/css/wegue.css');

to

import Vue from 'vue';
import Vuetify from 'vuetify';
import '../node_modules/ol/ol.css';
import WguApp from '../app/WguApp';
import UrlUtil from './util/Url';
import 'vuetify/dist/vuetify.min.css';

Vue.use(Vuetify);

require('./assets/css/wegue.css');

(Or maybe even before Vue-related imports).

Tests related to 'wgu-measuretool' raise exception

The unit tests related to wgu-measuretool raise exceptions and are therefore not executed at all. So the test suite gives an output like

Executed 158 of 182 SUCCESS

First inspection gave the hint that the cause must be in test/unit/specs/components/measuretool/MeasureWin.spec.js

Geocoder module: Show marker / bbox for selected entry

Show a marker (for point based geometries) or a bbox (if available) for the selected entry in the result list of the Geocoder module on the map. If the geometries are shown should be optional and thus a config option should be introduced.

See #29: For the general concept of the Geocoder module and #95 for the current implementation and its discussion.

Add OSM Overpass-API layer

Add a new layer type, which can take an OSM Overpass-API query and shows the result features on a map.

React on added / removed layers in LayerList

Currently the LayerList UI is only build once on initialization. It should react on added / remove layers to / from the map.

Add 'mapable' mixin

Instead of binding the OpenLayers map manually to every component, which needs a reference to it it would be useful to encapsulate this in a mixin. The mixin could be named like 'mapable' and has to do the following:

Listen to the ol-map-mounted event of the event-bus and bind the map as member variable of the component:

      WguEventBus.$on('ol-map-mounted', (olMap) => {
        // make the OL map accesible in this component
        me.map = olMap;
      });

Geocoder module: Add clearing button to remove search text

Add a clearing button to easily remove the search text from the textfield of the Geocoder module.

See #29: For the general concept of the Geocoder module and #95 for the current implementation and its discussion.

Ensure that the floating windows are visible on touch devices with small screens

At the moment the floating windows are not necessarily visible on devices with small screens. Their initial position is designed for desktop-based screens and should be adjusted for mobile devices (e.g. phones).

Add widget to add external WMS to map

A widget to add external WMS to the Wegue map would be useful, to allow users to add custom WMS layers.

The widget should accept a WMS GetCapabilities URL, parses the Capabilities and offers the WMS layers for adding to the map.

Compare-Layer

Add a new layer type, which is able to contain 2 child-layers which can be compared interactively by a swipe control. The control itself can be used from ol-ext (http://viglino.github.io/ol-ext/examples/control/map.control.swipe.html)

Add ZoomToMaxExtent Button

A button, which zooms the map to its initial center and zoom would be a nice component. The component should be named <ZoomToMaxExtentButton>.

For a first step it would be OK, if it is usable in the top toolbar (<AppHeader>).

Make floating window closable

Currently the floating windows can only be closed by pressing the corresponding button in the toolbar again.

The windows should get an icon/button in their header to close them.

Fix broken deactivation of measurement tools

While having open the measurement tool it is possible to depress both buttons (Distance and Area). But this has no effect on the measurement tool on the map. In case both buttons are deactivated the Distance tool gets activated.

Wanted behavior: Deactivate all measure tools on the map when both buttons are depressed.

Migrate to app template created with Vue-CLI v3

Since some dev-dependencies are out of date - especially webpack - and the upgrade isn't that straight forward there might be the possibility to create a new app template.

I had a quick chat with @JakobMiksch about this topic and he told me that the template Wegue was initially created with is deprecated (see https://github.com/vuejs-templates/webpack). Everything what has been done with the template should now be doable with Vue-CLI v3.

So it might be an idea to create a new application setup with Vue-CLI and apply the adaptations for Wegue, so we have an up-to-date setup with webpack and co.

Any thoughts or comments?

Add property to ignore layers in layer-list

We need to introduce a property, which is interpreted by the layer-list component to filter out layers, which should not be listed.

Suggestion for the property: displayInLayerList: [true|false]

Place windows in visible part of Viewport on small screens

At the moment the floating module- / tool-windows are placed outside the visible part of the viewport on small screens:

It should be ensured that they are visible on small screens too.

OSM basemap blurry

Wegue	osm.org

The OSM basemap looks more blurry on Wegue compared to the OpenStreetMap website

Make AppLogo component more flexible

As discussed in #114 a more flexible way to use the AppLogo component would be good:

Currently the component uses v-avatar which only allows square format images. A change to v-img or similar would make things more flexible.

Change tile provider from tile.openstreetmap.org

From my understanding one is not supposed to use tile.openstreetmap.org for OSM tile layers.
This issue is to propose an alternative OSM Layer provider. Suggestions from https://wiki.openstreetmap.org/wiki/Tile_servers with usage policies:

Wikimedia Maps AFAICS could be used: https://maps.wikimedia.org/ (?).

Affected file is static/app-conf.json. So a good First Issue!

WFS with GML3 not supporting custom SRS

The WFS layer support introduced with #105 has a know limitation: In case you are using a WFS with GML3 and a custom SRS it might happen that the loading of the features fails due to missing SRS definition (although it is defined in the projectionDefs section of the Wegue config).

The reason might be that GML has at three ways of specifying the SRS. As suggested by @justb4 one workaround would be to register (with Proj.js) all variant-names for the same SRS.

WMS to reproduce: https://geodata.nationaalgeoregister.nl/nationaleparken/wfs
FeatureType: nationaleparken:nationaleparken

Corresponding Wegue layer configuration:

    {
      "type": "WFS",
      "lid": "dutch-nat-parks",
      "name": "WFS (Dutch National Parks PDOK)",
      "url": "https://geodata.nationaalgeoregister.nl/nationaleparken/wfs",
      "typeName": "nationaleparken:nationaleparken",
      "version": "2.0.0",
      "maxFeatures": 10,
      "formatConfig": {
      },
      "format": "GML3",
      "projection": "EPSG:28992",
      "loadOnlyVisible": true,
      "visible": false,
      "selectable": true,
      "style": {
        "strokeColor": "white",
        "strokeWidth": 2,
        "fillColor": "rgba(155,153,51,0.5)"
      },
      "attributions": "<a href='https://www.pdok.nl' target='_blank'>PDOK</a> by Dutch Kadaster"
    }

Support drag 'n drop of spatial files

Since OpenLayers supports drag 'n drop for spatial data it would be easy to add this functionality to Wegue. Based on a new config option the DragAndDrop interaction could be added to the OL map within the Wegue map component.

See the official OL example as inspiration: https://openlayers.org/en/latest/examples/drag-and-drop.html

Embedded version layout broken

By introducing the overhauled layout concept for the default full-screen version with #35 the embedded version (/embedded.html) does not adapt anymore as it should.

Goal is to render the whole application into the given container element instead of using the whole viewport.

Add map permalink functionality

Goal is to add a simple permalink functionality for the map state like it is done in http://openlayers.org/en/latest/examples/permalink.html

Add ScaleLine component

Add a ScaleLine component Wrap the OpenLayers ScaleLine control (https://openlayers.org/en/latest/examples/scale-line.html) as Vue component so it gets usable anywhere in a Wegue application.
Also the background colour of the ScaleLine should be changed according to the base colour of the Wegue app (as it is e.g. done for zoom buttons).

Custom TileGrid and Projection for Tile Sources

#82 provided basic support for Maps with a custom projection. A next step is to also support tiled layers with custom OpenLayers' TileGrids (other than OSM/Google/Web Mercator global tilegrid).

At least OL TileLayer Sources like XyzSource, TileWmsSource and VectorTileSource currently supported in Wegue, support tileGrid and projection parameters (but no config support yet).

This allows also support for custom TMS ({-y}) and WMTS-RESTful Layers.
Regular KVP WMTS is more complex and should be adressed in separate issue "Support KVP WMTS", as a new Layer Type.

Basically the following additions are required:

1. config: global TileGrid(one or more?) definitions
2. config: support tileGrid (ref) and projection (ref) for XyzSource, TileWmsSource and VectorTileSource Layers
3. Layer Factory: support these new Layer definitions
4. extend the current "projected" example with tiled Layers from Dutch Kadaster/PDOK

Config-file location

Currently the config file must be placed in the static folder, whereas the rest of application-specific code is located in app.

Therefore, it would be clearer to also move the config file to the app folder. Ideally the init:app script should create this initial config file. So, the user can immediately start the application.

Unit tests for 'watch' properties failing

The unit test for the watch properties within our Vue components are failing on Travis.

On the local development setup the test are running without errors, so it seems like an issue on Travis.

Docker build fails - missing WguApp.vue

Problem

After the merge of merge 1.0.0-dev into master the Docker build fails:

ERROR in ./src/main.js
Module not found: Error: Can't resolve '../app/WguApp' in '/app/src'
 @ ./src/main.js 5:0-35

  Build failed with errors.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `node build/build.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Reason

The npm build expects app/WguApp.vue which is not present.

Solution

Provide a app/WguApp.vue during the Docker build. Maybe create a app/WguApp.vue.sample file, that is renamed/copied into Docker image?

Add window drag and drop for touch devices

At the moment dragging the floating windows is not possible on touch devices (e.g. tablets or phones). This should be implemented.

One possible solution is reported here: https://www.codeproject.com/Articles/1091766/Add-support-for-standard-HTML-Drag-and-Drop-operat

Make FeatureInfoWindow working again

FeatureInfoWindow.vue seems to be somewhat "disconnected" from the current Wegue configuration and initialization.
Even if configured, only one Layer (layerId) can be used within a Wegue App because of modules config-(keys)-convention.

This issue is to have at least the basics working again:

• enable to be configured
• enable to be initialized
• have some demo data (with info and image URL attributes)
• possibly enable for more than just one Layer (layerId)

Zoom buttons disappear after resize

The zoom buttons disappear when the window of the app is made small and afterwards made big again. See in the gif below.

Enhance toolbar concept

The way of embedding the toolbar should become more flexible. At the moment the toolbar is a Vuetify-standard component, which is rendered at the top of the map and can be filled with buttons.

A few optimizations would be good to make the usage of toolbars more flexible:

• Support horizontal and vertical toolbars
• Let the TB contain more components than buttons, e.g. combos

This issue can be seen as a master issue, which references sub-issues:

• Group tools in a menu #33

Add geocoder widget

A search widget to query a geocoder, like Nominatim, would a be a very useful component.

The UI could be a textfield with a result list below or a (possibly) existing combobox implementation , which provides the same functionality.