But I doubt that parse an SVG file is probably a heavy workload if we implement a complete (not rough) parser. (?)
And it probably difficult to determine which shapes are needed to be user interactive if the SVG is very complicated. (for example, highlight when hovering). So I think could we render the SVG directly into HTML document? Meanwhile, if user interaction is required, the designer can provide a separate SVG file, which including only <path> elements, to specify all of the <path>s that are needed to be interactive. (This idea comes from Dingding, and TianYu agrees that). ------------------------------ Su Shuang (100pah) ------------------------------ 2018-05-04 12:34 GMT+08:00 沈毅 <[email protected]>: > Use SVG directly means parse SVG file and rendered it with Canvas? I think > it's better because it can be resolution independent. Also we can change > the style of each element to encode the data. > > > SHUANG SU <[email protected]> 于2018年5月2日周三 下午2:29写道： > > > Shen Yi, > > > > Using image as geo background, will cause distortion when zooming. > > May be, it is a better way to use SVG directly on the browser (make a > > zrender/graphic/SVGImage) ? > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > Su Shuang (100pah) > > ------------------------------ > > > > > > 2018-04-30 2:45 GMT+08:00 SHUANG SU <[email protected]>: > > > > > > > > (1) > > > > And if background image > > > > has SVG image source, will the node information in SVG been parsed > and > > > > displayed? > > > > > > Does the simple way appropriate? > > > ```js > > > var img = new Image() > > > img.src = 'some.svg'; > > > // drawImage to canvas. > > > ``` > > > > > > There might be some compatible issue for old browser ( > > > https://caniuse.com/#feat=svg-img) in this way, > > > but I think it might bring complexity if imclude SVG parsing code to > > > echarts, > > > and not necessary if not need to interact with the inner shape of a > SVG. > > > > > > > > > (2) > > > > Are background and backgroundCoord general properties for the geo > > > > component? Can they be used with mapType property > > > > > > I think that both the `background` and `mapType` can be specified on > > > option. > > > The view rect can be calculated by union the `backgroundCoord: {x, y, > > > width, height}` > > > and the GeoJSON (specified by `mayType`, if the user needs it). > > > > > > But for this part, consider a scenario: > > > The background is a shopping mall map, and the user might need some > > > polygons > > > to describe some area (which can be interactive, like, highlight when > > > hovering). > > > If the polygons are described using GeoJSON, the option should be: > > > > > > ```js > > > echarts.registerMap('mall', thePolygonsGeoJSON); > > > > > > var option = { > > > geo: { > > > background: 'mall.png', > > > backgroundCoord: {x: 0, y: 0, width: 1000, height: 600}, > > > mapType: 'mall' > > > } > > > } > > > ``` > > > > > > where the GeoJSON 'mall' and background image 'mall.png' are specified > in > > > different styles. > > > Is it a little strange? > > > > > > Or, another approach: > > > the users can describe the polygons not in GeoJSON (since it is a > little > > > difficult to make > > > GeoJSON), but using a custom series, or a series type 'polygon' (or > > > 'lines', that already exists). > > > > > > ```js > > > var option = { > > > geo: { > > > background: 'mall.png', > > > backgroundCoord: {x: 0, y: 0, width: 1000, height: 600}, > > > }, > > > series: [{ > > > type: 'polygon', // or type: 'lines' > > > data: [ > > > // points of a polygon > > > [[px0,py0], [px1,py1], ...], > > > // Or even a SVGPath ? (which is more convenient for > > > designers?) > > > 'path://M164,210.677v33.47l154.656,66.356L468,243z', > > > ... > > > ] > > > }] > > > }; > > > > > > Is it appropriate? > > > I am thinking that how to make it easier for designers to convert the > SVG > > > or Adobe Illustrator path to the input of the echarts. > > > In echarts 2, special tag needed to be markd on a SVG shape if it is > > > needed to be parsed and be interactive in echarts. > > > But adding special tags is not convenient I think. > > > > > > > > > > > > > > > > > > ------------------------------ > > > Su Shuang (100pah) > > > ------------------------------ > > > > > > > > > > > > 2018-04-29 23:57 GMT+08:00 沈毅 <[email protected]>: > > > > > >> Some questions. > > >> > > >> Are background and backgroundCoord general properties for the geo > > >> component? Can they be used with mapType property? And if background > > image > > >> has SVG image source, will the node information in SVG been parsed and > > >> displayed? > > >> > > >> SHUANG SU <[email protected]> 于2018年4月29日周日 上午12:29写道： > > >> > > >> > Pissang and All, > > >> > > > >> > > > >> > Currently, geo coordinate system only supports GeoJson, which is not > > >> > convenient in some scenario that the base map might be the shopping > > mall > > >> > map, airport map, airplane seat map, topographic map, etc., where > > using > > >> > image or SVG is an easy and conventional way. > > >> > > > >> > So, should we provide "echarts option" like the snippet below for > this > > >> > feature? > > >> > > > >> > > > >> > ```js > > >> > var option = { > > >> > geo: { > > >> > > > >> > // Use as background image, which can be zoomed and moving > in > > >> the > > >> > geo coordSys. > > >> > background: 'shopping-mall.png', // or 'shopping-mall.svg' > > >> > > > >> > // Specify how the background is located in this geo. > > >> > // Essentially the value is geo coords of the background > rect. > > >> > the image width/height, where the geo > > >> > backgroundCoord: { > > >> > x: 0, > > >> > y: 0, > > >> > // Conventionally, we can use the image size as the geo > > >> coords > > >> > here. > > >> > width: 1000, > > >> > height: 600 > > >> > }, > > >> > > > >> > // In this case, we do not need to provide a GeoJSON and > > spcify > > >> > "mapType" here. > > >> > > > >> > }, > > >> > ... > > >> > }; > > >> > ``` > > >> > > > >> > In fact, this feature (using a roamable background image on geo) can > > be > > >> > implemented > > >> > by the "custom series", but it is not convenient (after all, it > > require > > >> > users to provide a GeoJSON to specify the bounding rect). > > >> > > > >> > Or any other ideas? > > >> > > > >> > > > >> > ---------------------------- > > >> > Su Shuang (100pah) > > >> > ---------------------------- > > >> > > > >> > > >> > > >> -- > > >> Yi Shen > > >> Senior Developer > > >> Baidu, Inc. > > >> > > > > > > > > > > > -- > Yi Shen > Senior Developer > Baidu, Inc. >
