Provide a more declarative maps API

[spliffone]

Prerequisites

• I have read the Contributing Guidelines.
• I have not leaked any internal/restricted information like screenshots, videos, code snippets, links etc.

Feature request

Beside the existing functionality to display GIS maps products require to display other types of data connected to a WMS service e.g. siteplans. The existing map component only provide the openlayers map but does not offer the ability the describe different sources, layers and controls in a declarative way.

A declarative approach allows consumers to build complex scenarios without challenging the open layers API and introducing complex services.

Alternative

An alternative approach is to provide the theming and examples for an existing open-source map components which already provide a declarative API e.g.:

• ngx-maplibre-gl
• ngx-openlayers

Example API

Here a basic idea of a possible API.

• maybe sources should be reuseable, means the definition is outside a layer

<div style="height: 600px">
  <!-- The main component manager inputs like zoom, center, projection, rotation, ... -->
  <si-map [center]="[0.0,0.0]" [extent]="[-53.6,-139.7,46.4,-90.5]" [projection]="{type: 'mercator'}" [style]="https://map-style.json" [zoom]="13" (olClick)="mapOnClick($event)">

    <!-- WMS Layer -->
    <si-map-layer-image>
      <si-map-source-imagewms>
              url="http://localhost:8280/cgi/dwg.fcgi"
              [params]="{
                 LAYERS: 'obj664,ddd666,jjhh767'   <!-- WMS Standard - siteplan internal layers-->
                 CRS: 'EPSG:3857',                             <!-- WMS Standard -->
                 BGCOLOR: '#55fs55'                        <!-- WMS Standard -->
                 MapName: '091.82.04.BAU.dwg'     <!-- proprietary -->
                 UseCache: '1'                                     <!-- proprietary -->
              }">
      </si-map-source-imagewms>
    </si-map-layer-image>

    <!-- GeoJSON Polygon Layer -->
    <si-map-layer-vector [zIndex]="10"> <!-- zIndex ensures it's above the WMS layer -->
      <si-map-source-vector [url]="'http://localhost:8123/api/zones'">
        <si-map-format-geojson />
      </si-map-source-vector>
      <si-map-style>
        <si-map-style-fill [color]="'rgba(255, 0, 0, 0.3)'" />
        <si-map-style-stroke [color]="'red'" [width]="2">
      </si-map-style>
    </si-map-layer-vector>

    <!-- GeoJSON Point Layer for Devices -->
    <si-map-layer-vector [zIndex]="20"> 
      <si-map-source-vector [url]="'assets/devices.geojson'">
        <si-map-format-geojson />
      </v-source-vector>
      <si-map-style>
        <si-map-style-circle [radius]="7">
          <si-map-style-fill [color]="'rgba(0, 150, 0, 0.8)'" />
          <si-map-style-stroke [color]="'darkgreen'" [width]="2" />
        </si-map-style-circle>
        <si-map-style-text [text]="'name'" [fill]="'white'" [stroke]="'black'" [strokeWidth]="2" [offsetY]="-15" />
      </si-map-style>
    </si-map-layer-vector>

    <!-- Controls -->
    <si-map-control label="Show layer" position="top-end" >
       <!-- Support content projection -->
       <label>
          <input type="checkbox" />Show devices
       </label>
    </si-map-control>
    <si-map-control label="Zoom in" position="bottom-end" ... />
    <si-map-control label="Zoom out" position="bottom-end" ... />
    <si-map-control label="Reset zoom" position="bottom-end" ... />
  </si-map>
</div>

Use case

For buildings:

• display siteplans and the related layers
• show/hide floor layers
• show/hide devices layers
• show hide device groups, security zones and camera angles as polygones e.g. via geo json definition

[dr-itz]

didn't look in detail into ngx-maplibre-gl, but moving away from OpenLayers to MapLibre GL would be great.

[timowolf]

We never intended to build our own map. We decided for OpenLayers, as it is very powerful and supported all use cases. The si-map is only a layer to facility the handling of ol. For complex scenarios, users should interact with ol directly.

Moving away from OL is one topic, but the other is that we always wanted to only configure existing libraries. As such, the provided declarative API seems to be too much of a facade. We should not reimplement existing APIs.