Skip to content

Conversation

nakul-py
Copy link
Contributor

@nakul-py nakul-py commented Aug 18, 2025

Description

This PR adds opacity as a generic property of all JGIS layers, defined once in the schema packages/schema/src/schema/project/jgis.json.

Now opacity is the exact same type of property as visible

Screencast.From.2025-08-19.21-28-23.mp4

Closes #829

Checklist

  • PR has a descriptive title and content.
  • PR description contains references to any issues the PR resolves, e.g. Resolves #XXX.
  • PR has one of the labels: documentation, bug, enhancement, feature, maintenance
  • Checks are passing.
    Failing lint checks can be resolved with:
    • pre-commit run --all-files
    • jlpm run lint

📚 Documentation preview: https://jupytergis--879.org.readthedocs.build/en/879/
💡 JupyterLite preview: https://jupytergis--879.org.readthedocs.build/en/879/lite

Copy link
Contributor

Binder 👈 Launch a Binder on branch nakul-py/jupytergis/fix%23829

Copy link
Contributor

github-actions bot commented Aug 18, 2025

Integration tests report: appsharing.space

@arjxn-py arjxn-py added the enhancement New feature or request label Aug 18, 2025
@nakul-py nakul-py marked this pull request as draft August 19, 2025 04:00
@nakul-py nakul-py marked this pull request as ready for review August 19, 2025 16:44
@nakul-py
Copy link
Contributor Author

nakul-py commented Aug 20, 2025

bot please update snapshots!!!

Copy link
Member

@martinRenou martinRenou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for starting this!

Since this is a big schema change, we should probably bump the schema version and have some backward compatibility here https://github.com/geojupyter/jupytergis/blob/main/python/jupytergis_core/jupytergis_core/jgis_ydoc.py#L56

Something like: if the schema version is the old one (when opacity was in the layer parameters) then patch valueDict['layers'] there accordingly by moving the opacity attribute out of the parameters.

This will allow us to continue opening the old file format without error.

@nakul-py nakul-py requested a review from martinRenou August 26, 2025 15:25
Comment on lines +64 to +65
if file_version < Version("0.8.1"):
for _layer_id, layer in valueDict.get("layers", {}).items():
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinRenou currently we are using the latest JupyterGIS version 0.8.1 to update the schema. But I am wondering if anyone has an old version, how could we handle that situation? I also use SCHEMA_VERSION instead of latest, but it didn't work.

Copy link
Member

@mfisher87 mfisher87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your work on this, Nakul! Haven't had time to go deep on this yet, but some questions immediately came to mind. My biggest thought right now is that we should push as much of this as possible into the sharedModel API, as it seems to not be robust enough to support what we're trying to do. Specifically, I think we need the ability to deep-merge state updates (and a DeepPartial generic type to support that).

i.e.

  // new update method
  updateObject(
    id: string,
    value: DeepPartial<IJGISLayer> | DeepPartial<IJGISSource>,
  ) { 
    // DEEP merge `value` with the current state of object.
  }

// ...

// updated call would _only_ change the specified properties
this.props.model.sharedModel.updateObject(myLayerId, {
  opacity: true,
  parameters: {
    symbologyState: {
      colorRamp: "viridis"
    }
  },
});

(or, maybe better, use the updateLayer, updateSource methods for this)

How do you all feel about this? @martinRenou @arjxn-py @gjmooney more thoughts on this in a comment below.

@@ -111,6 +111,14 @@ export class CreationForm extends React.Component<ICreationFormProps, any> {
layerSchema['required'] = ['name', ...layerSchema['required']];
layerSchema['properties'] = {
name: { type: 'string', description: 'The name of the layer' },
opacity: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? It should already be part of the object, right?

maximum: 1,
},
};
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can omit this since it's defined in the jsonSchema, right?

@@ -112,6 +112,7 @@ export const LayerBrowserComponent: React.FC<ILayerBrowserDialogProps> = ({
source: sourceId,
},
visible: true,
opacity: 1.0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want, we can omit this since the default is 1

this.props.layer,
params,
);
}
Copy link
Member

@mfisher87 mfisher87 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that a change like this is necessary makes me wonder if we're on the wrong path (I'm not saying your approach is wrong, more that our architecture needs work ;) ) with this change. We have an API for updating layer/source parameters, and moving opacity out of the parameters key is causing us to work around that API. That makes this change much more extensive than I expected. Perhaps the right path here is to update the sharedModel API to support more selective updates.

Perhaps the updateObjectParameters method could be updated to look like this?

  updateObject(
    id: string,
    value: Partial<IJGISLayer> | Partial<IJGISSource>,
  ) { 
    // DEEP merge `value` with the current state of object.
  }

Perhaps it's making our life a bit more complicated to have updateObjectParameters capable of acting on layers or sources, and we should instead have updateLayer, updateSource, etc. (these already exist, but they require you to pass a full layer object in, and replace it in the model) as the sole API method for doing updates of these nested objects?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move layer opacity one level up in the project file
4 participants