Gaps show in the components overview but not in the editing view

[atdservicebot]

What application are you using?

Moped

Describe the problem.

Gaps showed in the components overview but not in the editing view. Check the project indicated in link and screenshot

Is there anything else we should know?

No

Website Address

https://mobility.austin.gov/moped/projects/52?tab=map

Internet Browser: Firefox

Requested By
Nathan W.

Attachment (296.92kb)

Request ID: DTS21-102365

[amenity]

So strange! I can verify this is happening for me, too.

[sergiogcx]

The Problem

So I've been taking a look at this issue, specifically at the function handleLayerClick:

  /**
   * Adds or removes an interactive map feature from the project's feature collection and selected IDs array
   * @param {Object} e - Event object for click
   */
  const handleLayerClick = e => {
    const layerName = getLayerSource(e);

    // If a user clicks a drawn point in the map, open draw UI
    if (drawnLayerNames.includes(layerName)) {
      setIsDrawing(true);
    }

    if (!layerName || !getClickEditableLayerNames().includes(layerName)) return;

    const clickedFeatureId = getFeatureId(e.features[0], layerName);
    const selectedFeature = getGeoJSON(e);

    [...]

This function receives a PointerEvent click, so I inspected the event and specifically the getGeoJSON function, which retrieves the set of coordinates that make up the shape of the feature.

The problem does not seem to be with those functions, they appear to be running as expected; however, while testing the event object itself (e), it does not contain the complete shape. This is for example a path near the Krieg Field Softball Complex:

The strange thing is that when I click on one side of the same feature, mapbox returns a line made up of 52 coordinates, when I click on the opposite side it returns 49. It would seem to be that the whole feature consists of all 49+52 coordinates, but we only get a fraction every time we click.

https://images.zenhubusercontent.com/140626918/c32b418f-dc7d-4acf-9257-be29f5242ec8/2021_08_17_17_51_29.mp4

Things I've attempted to find a fix:

• At first, I attempted to see if we can find any additional data from the event object, but it only returns one set of coordinates. So no luck getting the rest of the feature.

• Secondly, I read some documentation about using queryRenderedFeatures as a way to retrieve features under the mouse, but this only gave me only one (the same we are retrieving through the event object.

• Thirdly, I attempted updating the library to 6.1.16, but that breaks the streets map & features (except for aerial view for some reason), the latest 5.x version is 5.3.16 which works but it doesn't fix the issue.

Moving Forward

• I wonder if that feature is actually two separate features that share the same id?
• I would like for a GIS person to inspect that feature for me, and determine if anything seems out of the ordinary.

[sergiogcx]

@patrickm02L @amenity @mateoclarke I am going to put this in blocked for now. I think this needs GIS inspection, and if they determine it looks fine then I can continue debugging.

Feature details:

id: 58520
layer: {id: "ctn-lines", type: "line", source: "jsx-source-0", source-layer: "CTN", layout: {…}, …}
LINE_TYPE: "Off-Street"
PROJECT_EXTENT_ID: 158520
source: "jsx-source-0"

[amenity]

@sergiogcx - gotcha. Thanks for all the research. Asking @johnclary what to do with this next...

[johnclary]

thanks for the research @sergiogcx. i'm going to to a little digging based on what you found and may pass it to Alan.

[johnclary]

@sergiogcx read here for an explanation of why features are being split. Because our layer source is a a vector tileset - features are arbitrarily split into tiles.

I think this is not noticeable visually when selecting features because Mapbox is styling the hover effect based on a feature ID that is common to both halves of the feature.

Here is a long thread discussing possible changes to the tile specification to address this—but it is dormant and does not present any current workarounds.

This is going to be tricky. There's nothing we can do on the GIS side to process the tiles in a way that will preserve features entirely. Some googling may turn up examples from folks that have solved it. A few ideas:

1. Render a geojson source (instead of vector tiles) at high zoom levels. Afaik geojson features will not be split. But I'm doubtful this is viable. The geojson data for this layer will be very large—dozens of megabytes at least. Mapbox is smart enough to only render features in the map extent, but i believe we would still need to load the entire street network geojson in-memory. Probably dozens of MB of data. It would probably be worth testing this. Our GIS team could get us the complete geojson data.

2a. Create an onClick callback function that filters all map features based on the clicked feature ID and merges their geometry before saving. This would involve interating through all (most?) features in the layer, and I assume it would be quite slow. I think this is the approach taken in the GIS stack exchange thread I posted above.

2b. Possibly involving turfjs—query features within x distance of a clicked feature. this radius could be fairly large—e.g. 1000 meters, and filters those features for split features based on feature ID. Essentially the same as option 2a but we would filtering a smaller number of features. Mapbox example.

3. Create an onClick callback function that queries the arcgis online REST API for the complete geojson feature data based on the clicked feature ID. There would be some network latency, but this may work pretty well. I'll follow-up here with an example API call.

I'm curious if @alan-deanda or @frankhereford have any ideas as well. Perhaps we should meet.

[frankhereford]

I agree that this is a tricky problem. Features broken over tiles is one of those recurring things you see when you least want to. Take this idea with a grain of salt, just spit-balling here.

Since both portions of the feature are available in memory and can be identified due to the common feature ID field, it may be possible to utilize TurfJS' combine method to create a multilinestring out of the individual linestrings. This would at least get you a single feature that represents the entire geometry, but it may also introduce complexities from adding a new geometry datatype into the mix.

I'll look into some stuff I've done in the past working with features that come down via vector tiles and report back if I find anything useful. Also, I'd be more than happy to meet on the issue if you all feel that would be helpful.

[amenity]

Is this the same issue? If so, I hadn't seen it at this scale before:

[johnclary]

@amenity - yes. thanks @frankhereford. i just ran a few tests and was able to get split features with queryRenderedFeatures. i won't have a chance to package it up for another day or so but will post back here and maybe open a PR.