Not conflating incoming buildings with existing buildings (ArcGIS NZ buildings)

[TLDuhamel]

Description

When using RapiD, I expect that the incoming RapiD building features will not display where there are already buildings. This is important in order to see where there are existing buildings and to not add duplicate features. However in this alpha I am seeing the RapiD buildings (yellow) loading over the existing buidings (red)

Before enabling RapiD layer - buildings have already been added on north of Andrew Road:

After enabling RapiD layer - do not want the yellow features to show on north of Andrew Road.

Version

2.0-alpha

What browser are you seeing the problem on? What version are you running?

Edge v104.0

Steps to reproduce

Start a fresh session of RapiD, with only the default RapiD layers enabled.
Navigate to an area of New Zealand where some buildings are already mapped.
Click on the RapiD logo, Add/Manage Datasets, Add the "New Zealand Buildings" RapiD layer.

The browser URL at the time you encountered the bug

https://mapwith.ai/rapid-v2-alpha#background=Bing&datasets=ef9136b079e24bbfb432be9bbdd246ff&disable_features=points,indoor,boundaries,water,rail,pistes,aerialways,power,past_future,others&map=18.44/-36.90574/174.92279

[TLDuhamel]

This occurs when starting from a 'fresh' session, and adding the New Zealand Buildings layer the first time.
Clicking on the link which has the dataset configured in the URL parameters will NOT recreate the bug.

[Bonkles]

After a brief investigation I was able to reproduce this exactly. By clicking the URL with the dataset pre-filled, the buildings conflated away properly.

By manually adding the dataset, the buildings appeared to be overlaid on top of the OSM ones.

The actual network mechanism we are using to obtain the features seems to be different.

In the successful case (pre-filled dataset URL) we are obtaining the building shapes with a call to the ml_roads service (as expected):

https://mapwith.ai/maps/ml_roads?conflate_with_osm=true&theme=ml_road_vector&collaborator=fbid&token=ASZUVdYpCkd3M6ZrzjXdQzHulqRMnxdlkeBJWEKOeTUoY_Gwm9fuEd2YObLrClgDB_xfavizBsh0oDfTWTF7Zb4C&hash=ASYM8LPNy8k1XoJiI7A&result_type=osm_xml&sources=esri_building.ef9136b079e24bbfb432be9bbdd246ff&bbox=174.92431640624997,-36.910372213522514,174.9298095703125,-36.90597988519295

In the failing case, it appears we are obtaining the building shapes directly from the ARCgis backend, which explains why there's no attempt at conflation:

https://services-ap1.arcgis.com/iA7fZQOnjY9D67Zx/arcgis/rest/services/LINZ_NZ_Buildings/FeatureServer/0/query?f=geojson&geometry=174.90234375,-36.91476428895592,174.92431640624997,-36.89719446989034&geometryType=esriGeometryEnvelope&outSR=4326&outfields=*&resultOffset=0&resultRecordCount=2000

[Bonkles]

After further investigation I found that the data picker was setting 'conflate' to 'no' when the user first clicks it. This was supposed to be a temporary thing we did while testing (just to make loading data faster).

I have fixed this in commit fa996c8afba54f88d3064f9e4f10c903accf507e and it should appear in the 2.01 release of the alpha.

[Bonkles]

Thanks @TLDuhamel for this very excellent bug writeup!