You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by SHUANG SU <su...@gmail.com> on 2018/05/02 06:29:05 UTC
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
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 <su...@gmail.com>:
>
> (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 沈毅 <sh...@gmail.com>:
>
>> 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 <su...@gmail.com> 于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.
>>
>
>
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by 沈毅 <sh...@gmail.com>.
1) If we have some problem when parsing and displaying the SVG file. We can
improve the parser or tell the developer how to work around it. But if we
choose to abandon the cross-platform feature, developers can do nothing if
they want to use the SVG map on other platforms like WeChat and NodeJS
2) SVG data in this case is a data source like GeoJSON, not a rendering
method. So I think echarts should handle the SVG file consistently all
platforms.
SHUANG SU <su...@gmail.com> 于2018年5月5日周六 下午7:59写道：
> typo: "resolution" -> "solution", stupid mistake :)
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
> 2018-05-05 19:58 GMT+08:00 SHUANG SU <su...@gmail.com>:
>
> >
> > (1)
> > > About the complexity, we've tried it in ECharts 2. I think it's not
> that
> > > complex and it works fine to me.
> >
> > The SVG parser in ECharts2 only supports "convert certain SVG to zrender
> > shape".
> > I've tested some of the SVG files downloaded from the web on ECharts2 SVG
> > parser.
> > Some of them cannot be rendered correctly.
> > For example:
> > https://upload.wikimedia.org/wikipedia/commons/9/98/Santorini-topo.svg
> > https://upload.wikimedia.org/wikipedia/commons/3/3a/Tehran_topo.svg
> >
> > If we use a "simple SVG parser" like ECharts2 did, we probably have to
> > make some rules or restrictions about:
> > "if the SVG file can be parsed and rendered correctly, it should be like
> > this xxx, and should not contain xxx".
> > but I think it is difficult for developers or designers to make an SVG
> > file following the rules or restrictions.
> >
> > If we implement a "complete SVG parse", be able to parse any SVG file
> > against the SVG specification,
> > I am afraid it is probably a difficult job (?) and brings lots of code.
> > If we can do that, we are actually implementing a SVG renderer, which
> > seems should not be the job of
> > ECharts, but the job of browsers.
> >
> >
> > (2)
> > > Render SVG directly into HTML is not friendly to other platforms.
> >
> > For the feature "getDataURL", I think it might be resolved by some trick.
> > For headless rendering, generally, I think there is rarely scenario that
> > using SVG in a
> > headless environment that not support SVG. If so, it seems not the job of
> > ECharts to
> > give the resolution of "rendering an SVG on a headless environment that
> > not support SVG".
> >
> > (3)
> > About the user interaction, it is actually another topic. We can discuss
> > them soon in another thread.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------
> > Su Shuang (100pah)
> > ------------------------------
> >
> >
> > 2018-05-04 17:08 GMT+08:00 沈毅 <sh...@gmail.com>:
> >
> >> Render SVG directly into HTML is not friendly to other platforms.
> >> Cross-platform is always important when we choose the solution. That's
> >> also
> >> what we considered when implementing the rich text label.
> >>
> >> I can't get your concern about determining which shapes are needed to be
> >> user
> >> interactive. It's more about how we designing the interface. I don't
> think
> >> it's relative to the underlying implementation.
> >>
> >> About the complexity, we've tried it in ECharts 2. I think it's not that
> >> complex and it works fine to me.
> >>
> >> SHUANG SU <su...@gmail.com> 于2018年5月4日周五 下午3:18写道：
> >>
> >> > 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 沈毅 <sh...@gmail.com>:
> >> >
> >> > > 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 <su...@gmail.com> 于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 <su...@gmail.com>:
> >> > > >
> >> > > > >
> >> > > > > (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 沈毅 <sh...@gmail.com>:
> >> > > > >
> >> > > > >> 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 <su...@gmail.com> 于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.
> >> > >
> >> >
> >>
> >>
> >> --
> >> Yi Shen
> >> Senior Developer
> >> Baidu, Inc.
> >>
> >
> >
>
--
Yi Shen
Senior Developer
Baidu, Inc.
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by SHUANG SU <su...@gmail.com>.
typo: "resolution" -> "solution", stupid mistake :)
------------------------------
Su Shuang (100pah)
------------------------------
2018-05-05 19:58 GMT+08:00 SHUANG SU <su...@gmail.com>:
>
> (1)
> > About the complexity, we've tried it in ECharts 2. I think it's not that
> > complex and it works fine to me.
>
> The SVG parser in ECharts2 only supports "convert certain SVG to zrender
> shape".
> I've tested some of the SVG files downloaded from the web on ECharts2 SVG
> parser.
> Some of them cannot be rendered correctly.
> For example:
> https://upload.wikimedia.org/wikipedia/commons/9/98/Santorini-topo.svg
> https://upload.wikimedia.org/wikipedia/commons/3/3a/Tehran_topo.svg
>
> If we use a "simple SVG parser" like ECharts2 did, we probably have to
> make some rules or restrictions about:
> "if the SVG file can be parsed and rendered correctly, it should be like
> this xxx, and should not contain xxx".
> but I think it is difficult for developers or designers to make an SVG
> file following the rules or restrictions.
>
> If we implement a "complete SVG parse", be able to parse any SVG file
> against the SVG specification,
> I am afraid it is probably a difficult job (?) and brings lots of code.
> If we can do that, we are actually implementing a SVG renderer, which
> seems should not be the job of
> ECharts, but the job of browsers.
>
>
> (2)
> > Render SVG directly into HTML is not friendly to other platforms.
>
> For the feature "getDataURL", I think it might be resolved by some trick.
> For headless rendering, generally, I think there is rarely scenario that
> using SVG in a
> headless environment that not support SVG. If so, it seems not the job of
> ECharts to
> give the resolution of "rendering an SVG on a headless environment that
> not support SVG".
>
> (3)
> About the user interaction, it is actually another topic. We can discuss
> them soon in another thread.
>
>
>
>
>
>
>
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
> 2018-05-04 17:08 GMT+08:00 沈毅 <sh...@gmail.com>:
>
>> Render SVG directly into HTML is not friendly to other platforms.
>> Cross-platform is always important when we choose the solution. That's
>> also
>> what we considered when implementing the rich text label.
>>
>> I can't get your concern about determining which shapes are needed to be
>> user
>> interactive. It's more about how we designing the interface. I don't think
>> it's relative to the underlying implementation.
>>
>> About the complexity, we've tried it in ECharts 2. I think it's not that
>> complex and it works fine to me.
>>
>> SHUANG SU <su...@gmail.com> 于2018年5月4日周五 下午3:18写道：
>>
>> > 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 沈毅 <sh...@gmail.com>:
>> >
>> > > 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 <su...@gmail.com> 于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 <su...@gmail.com>:
>> > > >
>> > > > >
>> > > > > (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 沈毅 <sh...@gmail.com>:
>> > > > >
>> > > > >> 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 <su...@gmail.com> 于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.
>> > >
>> >
>>
>>
>> --
>> Yi Shen
>> Senior Developer
>> Baidu, Inc.
>>
>
>
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by SHUANG SU <su...@gmail.com>.
(1)
> About the complexity, we've tried it in ECharts 2. I think it's not that
> complex and it works fine to me.
The SVG parser in ECharts2 only supports "convert certain SVG to zrender
shape".
I've tested some of the SVG files downloaded from the web on ECharts2 SVG
parser.
Some of them cannot be rendered correctly.
For example:
https://upload.wikimedia.org/wikipedia/commons/9/98/Santorini-topo.svg
https://upload.wikimedia.org/wikipedia/commons/3/3a/Tehran_topo.svg
If we use a "simple SVG parser" like ECharts2 did, we probably have to make
some rules or restrictions about:
"if the SVG file can be parsed and rendered correctly, it should be like
this xxx, and should not contain xxx".
but I think it is difficult for developers or designers to make an SVG file
following the rules or restrictions.
If we implement a "complete SVG parse", be able to parse any SVG file
against the SVG specification,
I am afraid it is probably a difficult job (?) and brings lots of code.
If we can do that, we are actually implementing a SVG renderer, which seems
should not be the job of
ECharts, but the job of browsers.
(2)
> Render SVG directly into HTML is not friendly to other platforms.
For the feature "getDataURL", I think it might be resolved by some trick.
For headless rendering, generally, I think there is rarely scenario that
using SVG in a
headless environment that not support SVG. If so, it seems not the job of
ECharts to
give the resolution of "rendering an SVG on a headless environment that not
support SVG".
(3)
About the user interaction, it is actually another topic. We can discuss
them soon in another thread.
------------------------------
Su Shuang (100pah)
------------------------------
2018-05-04 17:08 GMT+08:00 沈毅 <sh...@gmail.com>:
> Render SVG directly into HTML is not friendly to other platforms.
> Cross-platform is always important when we choose the solution. That's also
> what we considered when implementing the rich text label.
>
> I can't get your concern about determining which shapes are needed to be
> user
> interactive. It's more about how we designing the interface. I don't think
> it's relative to the underlying implementation.
>
> About the complexity, we've tried it in ECharts 2. I think it's not that
> complex and it works fine to me.
>
> SHUANG SU <su...@gmail.com> 于2018年5月4日周五 下午3:18写道：
>
> > 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 沈毅 <sh...@gmail.com>:
> >
> > > 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 <su...@gmail.com> 于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 <su...@gmail.com>:
> > > >
> > > > >
> > > > > (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 沈毅 <sh...@gmail.com>:
> > > > >
> > > > >> 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 <su...@gmail.com> 于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.
> > >
> >
>
>
> --
> Yi Shen
> Senior Developer
> Baidu, Inc.
>
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by 沈毅 <sh...@gmail.com>.
Render SVG directly into HTML is not friendly to other platforms.
Cross-platform is always important when we choose the solution. That's also
what we considered when implementing the rich text label.
I can't get your concern about determining which shapes are needed to be
user
interactive. It's more about how we designing the interface. I don't think
it's relative to the underlying implementation.
About the complexity, we've tried it in ECharts 2. I think it's not that
complex and it works fine to me.
SHUANG SU <su...@gmail.com> 于2018年5月4日周五 下午3:18写道：
> 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 沈毅 <sh...@gmail.com>:
>
> > 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 <su...@gmail.com> 于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 <su...@gmail.com>:
> > >
> > > >
> > > > (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 沈毅 <sh...@gmail.com>:
> > > >
> > > >> 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 <su...@gmail.com> 于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.
> >
>
--
Yi Shen
Senior Developer
Baidu, Inc.
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by SHUANG SU <su...@gmail.com>.
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 沈毅 <sh...@gmail.com>:
> 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 <su...@gmail.com> 于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 <su...@gmail.com>:
> >
> > >
> > > (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 沈毅 <sh...@gmail.com>:
> > >
> > >> 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 <su...@gmail.com> 于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.
>
Re: [Discussion] Support image and SVG as the background of GEO
coordinate system in echarts.
Posted by 沈毅 <sh...@gmail.com>.
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 <su...@gmail.com> 于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 <su...@gmail.com>:
>
> >
> > (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 沈毅 <sh...@gmail.com>:
> >
> >> 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 <su...@gmail.com> 于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.