Share via

how to use spatial layer in Azure Maps from type script

Palios, Jason 81 Reputation points
2020-10-20T13:36:12.193+00:00

Hello,

We are using azure maps in our angular front end.
We want to make use OgcMapLayer.

However we cannot add this layer to our map. When
we call the method this error comes up

Argument of type 'OgcMapLayer' is not assignable to parameter of type 'Layer<LayerEvents> | Layer<LayerEvents>[]'.
Type 'OgcMapLayer' is not assignable to type 'Layer<LayerEvents>'.
Property 'id' is protected but type 'Layer<T>' is not a class derived from 'Layer<T>'.

Azure Maps
Azure Maps
An Azure service that provides geospatial APIs to add maps, spatial analytics, and mobility solutions to apps.
664 questions
0 comments
Accepted answer
  1. rbrundritt 16,551 Reputation points Microsoft Employee
    2020-10-20T16:15:01.813+00:00

    I suspect this may be an issue in the typings file. In the meantime, add //@ts-ignore above that method to get rid of the error and move forward. I'll have the team look into this issue, but it likely won't be fixed for a bit.

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Taras Vozniuk 1 Reputation point Microsoft Employee
    2021-04-12T13:43:48.527+00:00

    @rbrundritt , @Palios, Jason :

    I suspect this may be an issue in the typings file. In the meantime, add //@ts-ignore above that method to get rid of the error and move forward. I'll have the team look into this issue, but it likely won't be fixed for a bit.

    This is likely not the issue with the typing themselves, but with the fact that there are multiple versions of azure-maps-control resolved(and likely multiply present in resulting bundle depending on how the bundling is performed). When just suppressing this issue with //@ts-ignore, there might be some unintended side effects such as someLayer instanceof Layer returning false when someLayer was instantiated inside azure-maps-spatial-io or azure-maps-drawing-tools using its own version of azure-maps-control internally. (I encountered this in azure-maps-drawing-tools)

    To confirm whether this is a source of an issue run: 

       yarn list azure-*

    If you see something like: 

       ├─ azure-maps-control@2.0.32   
   ├─ azure-maps-spatial-io@0.1.3   
   │  └─ azure-maps-control@2.0.31

    there are multiple versions present. This happens as azure-maps-spatial-io and azure-maps-drawing-tools list azure-maps-control as a dependency (rather then peerDependency.), so we need to be careful to make sure yarn doesn't produce 2 modules in here at resolutions.

    Possible way to resolve this is to check whether there are no fixed versions of azure-maps-control, azure-maps-spatial-io in package.json. (i.e: "azure-maps-control": "2.0.32" or "azure-maps-spatial-io": "0.1.6"). For me, changing the dependencies to relative versions: 

    {   
 "azure-maps-control": "^2.0.32",   
 "azure-maps-drawing-tools": "^0.1.6",   
 "azure-maps-spatial-io": "^0.1.3",   
}

    fixes the yarn resolution where yarn list azure-* produces: 

       ├─ azure-maps-control@2.0.32   
   ├─ azure-maps-drawing-tools@0.1.6   
   └─ azure-maps-spatial-io@0.1.3