I like the DataTable concept you've presented a lot; this is simple and flexible.
-Nathan On Monday, March 7, 2016 at 4:48:36 PM UTC-5, Sergey wrote: > > We did in fact consider layers. However, if we were to do layers, we would > have to do it in a way that is applicable for all charts (so that we > maintain a consistent API). One of the issues that your API design has is > that it would make layers inaccessible via ChartWrapper and Dashboard. > Another issue is that we wouldn't know how many layers to create without > another signal to the chart (i.e. chart.setLayers(2)), or always provide > some N layers. This also makes the chart not serializable, since there > exists some state that is defined outside of the DataTable and options. > > Generally, we try to steer away from adding new functions/properties to > our charts (although we've made compromises in this direction with adding > getImageUri() and setAction()). > > In my opinion, the most sensible way to add what you're asking for would > be to have fully composable charts (i.e. have a polygon layer and a markers > layer, but this could be applied to any chart). We've been pondering this > approach, but it's something that would require a complete overhaul of our > implementation. > > The next most sensible option (in terms of fitting into the constraints of > the existing API) is to have a combined DataTable Format that allows you to > specify either a region or a lat/long, something like: > [Region Code] | [Latitude] | [Longitude] | [Location Name] | [Value 1] | > [Value 2] | [Display Type] > > With certain columns being optional (like "Location Name", "Value 1" and > "Value 2"). This would allow you to specify 'null' for the region code > where you specify lat/long, or "Region Code" could be an address if > "Display Type" is 'markers' or 'text'. "Location Name" would apply to > either lat/long or region code. "Value 1" would map to the color of the > data, and "Value 2" would map to the size of the marker/text. "Display > Type" would be one of "region", "marker", "text", or null (to take the > current 'displayType'). > > I feel that this approach allows the best interoperability with our > current APIs and utilities, without adding too many new features, and still > maintaining clear control over how things are rendered. This method would > also allow users to draw marker data from both addresses and lat/long > coordinates. > > On Mon, Mar 7, 2016 at 4:23 PM Nathan Meryash <[email protected] > <javascript:>> wrote: > >> Hi Sergey, >> >> Thank you for the quick and comprehensive response. It's encouraging to >> know thought has been made here and to understand the challenges you face >> balancing a number of objectives. >> >> Have you considered adding support for layers, perhaps as children to a >> chart object? Syntax wise, something like the following with the ability to >> define layer order and blending properties (not shown): >> >> chart.layer1.draw(regionsData, regionsOptions); >> chart.layer2.draw(markersData, markersOptions); >> >> Regards, >> >> Nathan >> >> >> On Monday, March 7, 2016 at 9:56:44 AM UTC-5, Sergey wrote: >> >>> Hi Nathan, >>> >>> We have talked internally at length about combining the different ways >>> of rendering the GeoChart, and have thought long and hard about how to do >>> this. We eventually chose to punt on this issue. >>> >>> Personally, I don't like the idea of passing an array of things to >>> chart.draw very much, since that results in an inconsistent API, and this >>> is one of the things many of the users of our API (including our own >>> Controls and Dashboards) depend on. Adding a new form of arguments to >>> chart.draw would make things more complicated and confusing in that >>> respect. Our preference would be to either specify this information in one >>> DataTable or via options, but we were not able to decide on a consistent >>> way to do this. >>> >>> The Goole Maps API vs Charts is a much deeper issue than I'd like to get >>> into here, but suffice it to say that these two APIs are developed by >>> different teams, that ultimately have different goals and use cases. >>> >>> On Sun, Mar 6, 2016 at 12:28 PM Nathan Meryash <[email protected]> >>> wrote: >>> >> It would be great if the chart.draw() method supported arrays so that one >>>> could draw regions and markers on the same map. It seems necessary as one >>>> needs to call different options arguments for regions and markers. >>>> Especially the displayMode. >>>> >>>> Example: >>>> >>>> chart.draw([ >>>> [regionsData, regionsOptions], >>>> [markersData, markersOptions] >>>> ]); >>>> >>>> You called the draw() method with an Array rather than a DataTable or >>>> DataView >>>> >>>> It's also not clear why Google Maps Javascript API >>>> <https://developers.google.com/maps/documentation/javascript/>and >>>> Charts >>>> <https://google-developers.appspot.com/chart/interactive/docs/gallery/map> >>>> aren't consolidated into one full featured API? >>>> >>>> There are also partially featured custom Maps in Google Maps and Google >>>> Sheets, it would be great to have more features by combining these two. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Google Visualization API" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To post to this group, send email to [email protected]. >>> >>> >>>> Visit this group at >>>> https://groups.google.com/group/google-visualization-api. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/google-visualization-api/a9a2de6c-3014-4952-acc6-2c49fca4188d%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/google-visualization-api/a9a2de6c-3014-4952-acc6-2c49fca4188d%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> >>> *[image: unnamed.gif]• Sergey Grabkovsky• Software Engineer• Google, >>> Inc• [email protected]* >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Google Visualization API" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at >> https://groups.google.com/group/google-visualization-api. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-visualization-api/97f5a581-5d1e-4fe5-97b2-c95844444419%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-visualization-api/97f5a581-5d1e-4fe5-97b2-c95844444419%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *[image: unnamed.gif]• Sergey Grabkovsky• Software Engineer• Google, Inc• > [email protected] <javascript:>* > > -- You received this message because you are subscribed to the Google Groups "Google Visualization API" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-visualization-api. To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/179b44d6-3564-43bd-98ce-f3811a459d99%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
