GeoJSON Feature properties stringified in map events

[shishkin]

maplibre-gl-js version: 2.1.9

browser: Chromium 101.0.4951.64

Steps to Trigger Behavior

1. Add GeoJSON source with a Point Feature and properties like:

{
    type: "FeatureCollection",
    features: [{
      type: "Feature",
      geometry: {
        type: "Point",
        coordinates: [0, 0],
      },
      properties: {
        foo: {bar: "baz"}
      },
    }],
  }

2. Make source layer interactive and handle map mouse events.
3. Get typeof e.features[0].properties.foo

Link to Demonstration

https://codepen.io/sergey-shishkin/pen/YzazqxO

Expected Behavior

Event feature properties should have same structure as original data source.

Actual Behavior

Event feature properties turned to strings.

[HarelM]

I think there was a similar issue related to ids of geojson features.
If I need to guess this is probably related to some serialization and deserialization due to data passing between the worker and the main thread.
But I would recommend investigating it and sending a PR in case you find the root cause :-)

[shishkin]

Thanks @HarelM, could you point me to the direction of investigation? I'm not familiar with the codebase. I've already looked through the code of GeoJSON sources and workers but couldn't spot anything obviously wrong.

[HarelM]

Geojson source and worker would be my guess as well...

[rduivenvoorde]

Does this not be because of the fact that originally geojson (see geojson.org) defines so called ‘ OpenGIS Simple Features Implementation Specification’ features, in which properties almost always is a table like (not tree like) structure?
What do other geojson libs do with your not so standard geojson?

[shishkin]

GeoJSON.js supports object properties just fine: https://codepen.io/sergey-shishkin/pen/gOegopW.

[rotu]

The serialize/deserialize implementations seem fishy to me.

I don't see a reason not to use structuredClone. Could probably result in some perf gains too.

Edit: I missed the obvious; this does rest on the structured clone algorithm but it does more work to maintain object classes. It still looks like a footgun in places (like as a side effect, it implicitly guts the buffers of the source object).

I would look at the custom deserializer of FeaturePositionMap. That seems to be a possible culprit.

[guimochila]

I am facing the same problem and I have to confess that it took me awhile to understand that was Maplibre who was "stringifying" the properties property. =/

Edit: Any object inside properties are being serialized.

[guimochila]

@HarelM @rotu I have been trying to debug this issue but it is bit more complex than I initially thought.

I might be wrong but the issue here seems to come from @mapbox/vector-tile package. On feature_index.ts line 100, it starts a new VectorTiles:

loadVTLayers(): {[_: string]: VectorTileLayer} {
        if (!this.vtLayers) {
            this.vtLayers = new vt.VectorTile(new Protobuf(this.rawTileData)).layers;
            this.sourceLayerCoder = new DictionaryCoder(this.vtLayers ? Object.keys(this.vtLayers).sort() : ['_geojsonTileLayer']);
        }
        return this.vtLayers;
    }

The properties property is already deconstructed and any object is stringified:

On line 203 feature is serialized:

        const sourceLayerName = this.sourceLayerCoder.decode(sourceLayerIndex);
        const sourceLayer = this.vtLayers[sourceLayerName];
        const feature = sourceLayer.feature(featureIndex);

All objects inside properties are returned as stringified:

I am not sure how to approach for a solution as it seems to be in a mapbox library. Maybe a function to try to deserialize the properties in properties? Assuming that the issue is really from where I am saying. 😆

[HarelM]

Ahh, that's interesting.
The geojson source is transforming the geojson into tiles so what you say makes a lot of sense.
If you think the bug is in the serialization or deserialization of the vt mapbox library you should be able to create a test there to show the problem (without all the wrapping that is done in the geojson source etc in this lib).
If you manage to do that, you can consider opening a PR to that library. Once this PR is merged and there is a new version of this library we could bump the version here and have that fix here too.
Does this sound like a good plan to you?

[guimochila]

@HarelM That sound good, I have just worked in a workaround, tell me what do you think?

import vt from '@mapbox/vector-tile';

export function deserializeFeature(feature: vt.VectorTileFeature) {
    if (!feature || Object.keys(feature.properties).length === 0) {
        return feature;
    }

    for (const key in feature.properties) {
        if (typeof feature.properties[key] === 'string') {
            try {
                feature.properties[key] = JSON.parse(feature.properties[key] as string);
            } catch (e) {
                continue;
            }
        }
    }

    return feature;
}

This actually works and I will probably need to implement this in my project so I can make it work. But with this code GeoJSONFeature already returns all objects. It can be more detailed and check if there is an object inside the string but I am not sure about performance though.

[shishkin]

@guimochila I use a similar approach but use superjson to ensure Date's are serialized and deserialized correctly:

function serializeFeature(f: Feature): Feature {
  return {
    ...f,
    properties: {
      ...f.properties,
      _json: superjson.stringify(f.properties),
    },
  };
}

function deserializeFeature(f: Feature): Feature {
  const json = f.properties._json as string;
  if (!json) return f;

  const properties = superjson.parse(json) as FeatureProperties;
  f.properties = Object.assign({}, f.properties, properties);
  return f;
}

serializeFeature is used before setting GeoJSON source and deserializeFeature is used when I need original feature object inside maplibre-gl event handlers.

This is likely not the most efficient way though.

[guimochila]

@shishkin That looks nice, however I agree with you this is maybe not the most efficient way and I guess the issue still in the @mapbox/vector-tile deserialization.