This function takes layer as input, but doesn't use it. Can you explain why?

@Sahil-Chhoker do you know how this works?

@EwoutH Sorry for the late reply, I was working on fixing the merge conflicts.

To answer your question: I kept the test simple because I just wanted to verify that the renderer accepts the new PropertyLayerStyle class, so inspecting the specific layer logic wasn't necessary for this fixture.

I have opened a fresh PR here: #2920 to handle the merge conflicts cleanly. In that new PR, I renamed the argument to _ as suggested to indicate it is unused. Was facing merge conflicts there as well. I will try to fix that as well.

@Sahil-Chhoker do you know how this works?

Yeah, the property layer portrayal behaves exactly like agent portrayal, it taken in a layer and calls the portrayal function on every layer and you can pass different portrayals for different layers, in this case all layers are called with only one portrayal function.

Thanks @Sahil-Chhoker for the explanation, I understand it now. The layer parameter enables conditional styling based on layer properties (name, data values, etc.), similar to how agent portrayal works. For this test, it's simply verifying that the renderer accepts PropertyLayerStyle objects, so the parameter isn't needed.

This PR is good to merge as-is.

However, I'm wondering if we should consider improving this API in a follow-up. The current design feels a bit awkward:

• Simple cases require writing a function wrapper that always returns the same object
• The function --> class pattern isn't the most intuitive

Right now users must write:

def propertylayer_portrayal(layer):
    return PropertyLayerStyle(colormap="viridis", colorbar=True)

Where the function wrapper adds no value when the style is uniform across all layers.

What if we allowed the visualization to accept either:

1. A PropertyLayerStyle instance directly (for simple uniform styling)
2. A callable function (for conditional/per-layer styling)

Similar to how Python's sorted() accepts both key=str.lower and key=lambda x: complex_logic(x).

Not urgent at all, but might be worth following up on.

Thanks @EwoutH for the detailed write-up, I also think the API can be improved and your approach is pretty good, but currently I'm a little busy with my exams, I'll be able to take a careful look by the end of this month.

Perfect, split it off in a new issue: #2923