sadpandajoe commented on code in PR #39760:
URL: https://github.com/apache/superset/pull/39760#discussion_r4401903848
##########
superset-frontend/plugins/plugin-chart-cartodiagram/src/components/OlChartMap.tsx:
##########
@@ -196,6 +325,10 @@ export const OlChartMap = (props: OlChartMapProps) => {
addLayers(layerConfigs);
}, [olMap, layerConfigs]);
+ useEffect(() => {
+ applyMapExtentView(olMap, currentMapMaxExtent);
Review Comment:
This replaces the map's `View` (via `olMap.setView(...)`) whenever the max
extent changes, but the zoom-sync effect further down (the
`view.on('change:resolution', ...)` subscription, deps `[olMap,
setControlValue, chartSize]`) bound to `olMap.getView()` once and is not re-run
for a new view. After picking CUSTOM or clicking "Use current extent", zooming
no longer reaches `onViewChange`, so `chart_size.configs.zoom` (and the
"Current Zoom" display / zoom-relative size editing) stays stale until
something else retriggers this effect. Should the view (or
`currentMapMaxExtent`) be part of this effect's dependencies?
##########
superset/config.py:
##########
@@ -3492,6 +3492,83 @@ def EMAIL_HEADER_MUTATOR( # pylint:
disable=invalid-name,unused-argument # noq
},
}
+# Map projections of the datasources. If not provided, only
+# EPSG:3857 and EPSG:4326 are supported. The projection definitions
+# can be found on https://epsg.io in the Proj.4 section and should
+# be added here in following structure:
+#
+# {'EPSG:Code': 'definition'}
+#
+# e.g.
+#
+# {
+# 'EPSG:25832': (
+# '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m '
+# '+no_defs +type=crs'
+# ),
+# 'EPSG:25833': (
+# '+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m '
+# '+no_defs +type=crs'
+# ),
+# }
+#
+MAP_PROJECTIONS = {}
+
+# Default layers that will be added to all visualizations of
plugin-chart-cartodiagram.
+# For a list of supported types, and configuration details see the README.md
+# of plugin-chart-cartodiagram.
+MAP_DEFAULT_LAYERS = [
+ {
+ "type": "WMS",
+ "version": "1.3.0",
+ "url": "https://ows.terrestris.de/osm-gray/service";,
+ "layersParam": "OSM-WMS",
+ "title": "OpenStreetMap",
+ "attribution": (
+ "© Map data from "
+ '<a href="https://openstreetmap.org/copyright";>OpenStreetMap</a>. '
Review Comment:
The default `attribution` here contains `<a href=...>` markup, but the
plugin always runs attributions through `escapeAttribution` before handing them
to OpenLayers, so on the map users will see the literal `<a
href="https://openstreetmap.org/copyright";>OpenStreetMap</a>` text rather than
links. Should this default (and the documented pattern operators will copy) be
plain text, or should operator-supplied layers be allowed trusted HTML?
##########
superset-frontend/plugins/plugin-chart-cartodiagram/src/util/layerUtil.tsx:
##########
@@ -158,6 +173,35 @@ export const createWfsLayer = async (wfsLayerConf:
WfsLayerConf) => {
});
};
+/**
+ * Create a DATA layer.
+ *
+ * @param dataLayerConf The layer configuration
+ *
+ * @returns The created DATA layer
+ */
+export const createDataLayer = async (dataLayerConf: DataLayerConf) => {
+ const { attribution, style } = dataLayerConf;
+ const dataSource = new VectorSource({
+ attributions: attribution,
Review Comment:
`createDataLayer` passes the creator-supplied `attribution` straight to
`VectorSource`, while the WMS, XYZ and WFS paths run it through
`escapeAttribution` because OpenLayers renders attributions via `innerHTML`. A
saved chart whose `layer_configs` contains `{"type":"DATA","attribution":"<img
src=x onerror=...>"}` would execute script in any viewer's browser when the
attribution control renders (the renderer picks DATA purely from `type`,
regardless of whether the Explore UI offers it). Should this use
`escapeAttribution(attribution)` like the other layer types?
##########
superset-frontend/plugins/plugin-chart-cartodiagram/src/util/transformPropsUtil.ts:
##########
@@ -79,6 +144,7 @@ export const createColumnName = (columns: string[],
ignoreIdx: number[]) =>
export const groupByLocationGenericX = (
Review Comment:
`groupByLocationGenericX` now has WKT/WKB branches (geometry detected inside
timeseries `label_map` entries, then stripped from the series label), but every
`groupByLocationGenericX` test still passes `GeometryFormat.GEOJSON`; the new
WKT/WKB tests only cover the column detectors and non-timeseries
`getChartConfigs`. If the WKT/WKB grouping or label-stripping broke, nothing
would fail. Could a test feed a `label_map` like `['SRID=4326;POINT(8 53)',
'A']` with WKT and the WKB equivalent, asserting each location gets the right
series values and the geometry is absent from the resulting column name?
##########
superset-frontend/src/explore/components/controls/LayerConfigsControl/geoStylerUtil.ts:
##########
@@ -0,0 +1,187 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import { FeatureCollection, GeoJsonGeometryTypes } from 'geojson';
+import { VectorData } from 'geostyler-data';
+import { GeoStylerContextInterface, GeoStylerLocale, locale } from 'geostyler';
+
+import { Style, Symbolizer } from 'geostyler-style';
+import { ColTypeMapping } from './types';
+import { SupersetTheme } from '@apache-superset/core/theme';
+
+/**
+ * Map Superset column type to GeoStyler column type.
+ * @param colType The Superset columntype
+ * @returns The GeoStyler column type.
+ */
+export const colTypeToGeoStylerType = (colType: string) => {
+ // TODO add missing types
+ switch (colType) {
+ case 'LONGINTEGER':
+ case 'INTEGER':
+ return 'integer';
+ case 'STRING':
+ return 'string';
+ case 'DATETIME':
+ case 'DATE':
+ case 'FLOAT':
+ case 'DECIMAL':
+ return 'number';
+ default:
+ return colType;
+ }
+};
+
+/**
+ * Map Superset column types to GeoStyler data.
+ * @param colTypes The superset column types.
+ * @returns A geotyler-data object.
+ */
+export const colTypesToGeoStylerData = (
+ colTypes: ColTypeMapping,
+ dataFeatureCollection: FeatureCollection = {
+ type: 'FeatureCollection',
+ features: [],
+ },
+) => {
+ const data: VectorData = {
+ schema: {
+ type: 'object',
+ properties: Object.keys(colTypes).reduce(
+ (prev, cur) => ({
+ ...prev,
+ [cur]: {
+ type: colTypeToGeoStylerType(colTypes[cur]),
+ },
+ }),
+ {},
+ ),
+ },
+ exampleFeatures: dataFeatureCollection,
+ };
+ return data;
+};
+
+/**
+ * Create a GeoStylerContext.
+ *
+ * Sets the locales, GsData, and enables and disables certain features
+ * depending on given data and their geometries.
+ *
+ * @param gsLocale The locales of the active language.
+ * @param data The GeoStyler Data.
+ * @param geomTypes List of distinct geometry types.
+ * @returns The GeoStylerContext.
+ */
+export const createGeoStylerContext = (
+ gsLocale: GeoStylerLocale,
+ data: VectorData | undefined,
+ composition: GeoStylerContextInterface['composition'],
+) => {
+ const context: GeoStylerContextInterface = {
+ locale: gsLocale,
+ composition: composition ?? {},
+ };
+
+ if (data) {
+ context.data = data;
+ }
+
+ if (!context.composition!.Rules) {
+ context.composition!.Rules = {};
+ }
+ // If disableClassification is not explicitly set to true,
+ // determine its value based on the presence of example features.
+ if (context.composition?.Rules.disableClassification !== true) {
Review Comment:
`context.composition` is the memoized `MAP_GEOSTYLER_COMPOSITION` object
itself, and this block mutates it. On first render `data` is undefined, so
`Rules.disableClassification` is written as `true`; when the WFS features
arrive, the same object is passed back in and the `!== true` check reads that
generated value as an explicit operator setting, so classification stays
disabled even though example features now exist. Could the composition be
cloned before deriving `disableClassification`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
