Subdivide this repository

[boeckMt]

Currently we have a mix of different mapping libraries and many things in this repository.

To simplify dependency management and maintenance, maybe it would be good to remove all mapping library dependent things.
These could then be published in separate repositories.

E.g.

ukis-core

• projects/base-layers-raster
• projects/core-ui
• projects/layer-control
• projects/services-layers
• projects/services-map-state
• projects/services-ogc
• projects/services-util-store
• projects/shared-assets
• projects/utils-browser
• projects/utils-ogc

@dlr-eoc/map-ol

• projects/map-ol
• projects/utils-maps/src/lib/ol
• projects/utils-ogc/src/lib/wms
• projects/map-tools/src/lib/mouse-position
• projects/services-ogc/src/lib/owc

@dlr-eoc/map-three

• projects/map-three

demo-maps

• projects/demo-maps

demo-auth and @dlr-eoc/user-info

• projects/demo-auth
• projects/user-info

and other upcoming mapping libraries

@dlr-eoc/map-leaflet

• currently internal and not as many features as map-ol

@dlr-eoc/map-maplibre

• currently internal and not as many features as map-ol

@dlr-eoc/map-cesium

• currently internal and not as many features as map-ol

---

Disadvantages

• Potential dependency conflicts can arise when the same dependency is used in different projects with different versions
• The projects can only use the core (ukis-core) as npm dependencies or with some cloning and path mapping
• The other projects must be updated manually.
  On the one hand, that's good because we don't have to update all projects at one time but we'll have to update them later anyway.
  This can lead to different versions e.g. angular of ukis-core@14.1.0, @dlr-eoc/map-ol@14.0.0 and @dlr-eoc/map-cesium@14.2.12 which can result to different behavior.

---

• Versions (Angular, rxjs, ...) of projects can be different -> we don't have to update all at the same time
  -> However, this can lead to more difficult migrations if a project waits too long.
  -> Shared libraries must work for all versions of the projects or the projects must be updated when the libraries change
  -> Fixes in shared libraries are not so easy to integrate -> Fix, publish, then include (npm) -> needs more automation in deployment

Advantages

• separate development and deployment
• separate architectural choices

[boeckMt]

@lucas-angermann, @voinSR, @MichaelLangbein, @kambrium what do you think about this?

[MichaelLangbein]

The projects can only use the core (ukis-core) as npm dependencies

Didn't quite understand that aspect - could you elaborate?
Otherwise, maybe this is worth having a meeting so we can more easily spitball ideas and see aspects which might not immediately come up.

That said, having ukis a bit more modular seems like a good thing, and maybe this does make development of the cesium- and maplibre-branches a bit faster.

[boeckMt]

The projects can only use the core (ukis-core) as npm dependencies

If we have a separate repository e.g. ukis-core (with the contents I have listed above) and someone works e.g. on @dlr-eoc/map-three it's not as easy to fix or change things in ukis-core to test ist with @dlr-eoc/map-three.

Right now you just need to change the code and it will affect your project. If the repositores are split, you would have to clone ukis-core and link it inside your project like described in "Developing libraries and frontend side by side".