[feature] Add API endpoint for indoor map coordinates #828

[dee077]

Implemented API to return device coordinates for a given location ID.

Fixes #828

Checklist

• I have read the OpenWISP Contributing Guidelines.
• I have manually tested the changes proposed in this pull request.
• I have written new test cases for new code and/or updated existing tests for changes to existing code.
• I have updated the documentation.

Reference to Existing Issue

Closes #828

Description of Changes

I have created an endpoint to fetch the indoor coordinates of a floorplan for a given location ID, with an optional filter for floors. However, I'm unsure about the ideal response structure. Currently, I am returning all data from DeviceLocationSerializer, but I’m considering whether to refine the response or create a new serializer specifically for this use case.

Additionally, I have included a test case that generates two responses in an array. Once the response structure is finalized, I will write comprehensive test cases, including subtests for all variations under test_floorplan_coordinates.

Could you help me structure the response correctly and advise on whether to use the existing serializer or create a new one?

Current sample response:

{
  "devices": [
    {
      "location": {
        "id": "ab423599-95f1-48b4-9700-58cd014a243f",
        "type": "Feature",
        "geometry": {
          "type": "Point",
          "coordinates": [12.512124, 41.898903]
        },
        "properties": {
          "type": "indoor",
          "is_mobile": false,
          "name": "test-location",
          "address": "Via del Corso, Roma, Italia"
        }
      },
      "floorplan": {
        "id": "e19da20f-40b7-4acc-8852-eb6bc5bed4b6",
        "name": "test-location 1st Floor",
        "floor": 1,
        "image": "http://testserver/media/floorplans/e19da20f-40b7-4acc-8852-eb6bc5bed4b6.jpg",
        "created": "2025-01-31T16:18:03.920860+01:00",
        "modified": "2025-01-31T16:18:03.920860+01:00"
      },
      "indoor": "-140.38620,40.369227"
    },
    {
      "location": {
        "id": "ab423599-95f1-48b4-9700-58cd014a243f",
        "type": "Feature",
        "geometry": {
          "type": "Point",
          "coordinates": [12.512124, 41.898903]
        },
        "properties": {
          "type": "indoor",
          "is_mobile": false,
          "name": "test-location",
          "address": "Via del Corso, Roma, Italia"
        }
      },
      "floorplan": {
        "id": "0f882cec-84ef-4bb1-8efb-8d8ae9566052",
        "name": "test-location 2nd Floor",
        "floor": 2,
        "image": "http://testserver/media/floorplans/0f882cec-84ef-4bb1-8efb-8d8ae9566052.jpg",
        "created": "2025-01-31T16:18:03.928718+01:00",
        "modified": "2025-01-31T16:18:03.928718+01:00"
      },
      "indoor": "-140.38620,40.369227"
    }
  ],
  "available_floors": [1, 2]
}

[coveralls]

coverage: 98.888% (-0.01%) from 98.899%
when pulling 1754156 on dee077:feature/828-api-indoor-map-coordinates
into 129a42f on openwisp:master.

[nemesifier]

@dee077 Isn't this part of the GSoC project idea for the indoor map?

[dee077]

Yes, this aligns with the GSoC project idea for the indoor map. However, at the time, it didn’t have the gsoc-idea label, so I wasn’t aware that it would be proposed as a GSoC idea for 2025.