This is an object positioning issue. We have 

manual position x is 8.1% and y is 11.8% with a top-left anchor
object size is automatic and that seems to mean that it is tiny...

Switching to manual size gives us a reasonable chart. How does our 'automatic' work?

When Gnumeric makes an ods file from the .gnumeric file, I get:

        <chart:plot-area chart:style-name="GOG--0x1945030" gnm:is-position-manual="false">

Obviously the localc generated file doesn't have that tag.

localc does not have "automatic" positioning, Gnumeric does. So round tripping through localc should never give us an 'automatic' position. (And it doesn't in this case.)

I'm confused.

If I load the .gnumeric file I see automatic position and size.
If I load the .xls file I see automatic position and size.
If I load the gnumeric-generated ods file I see automatic position and size.
If I load the localc-generated ods file I manual position.

This is as expected:

there is no 'automatic position" in LO. SO they save it as manual. When we create an ODF file we store it with a foreign attribute.

If you save it as a strict (no extendion) ODF file in gnumeric and open it you should also see manual position I would guess.

We have valgrind errors in the view code.  That can't be good.

==18202== Conditional jump or move depends on uninitialised value(s)
==18202==    at 0x82A7DFB: __hypot_finite (e_hypot.c:58)
==18202==    by 0x82BD6BB: hypot (w_hypot.c:24)
==18202==    by 0x547C913: go_geometry_cartesian_to_polar (go-geometry.c:44)
==18202==    by 0x542A4BD: axis_line_get_bbox.isra.0 (gog-axis-line.c:1016)
==18202==    by 0x542E2C0: xy_process (gog-axis-line.c:1635)
==18202==    by 0x5430072: gog_axis_base_view_padding_request (gog-axis-line.c:2175)
==18202==    by 0x5426014: gog_axis_view_padding_request (gog-axis.c:3718)
==18202==    by 0x5415AF1: gog_view_padding_request_real (gog-view.c:524)
==18202==    by 0x541C1E3: gog_chart_view_size_allocate (gog-chart.c:1347)
==18202==    by 0x5415CAE: gog_view_size_allocate (gog-view.c:837)
==18202==    by 0x5415E99: gog_view_size_allocate_real (gog-view.c:562)
==18202==    by 0x54148D0: gog_outlined_view_size_allocate (gog-outlined-object.c:143)
==18202==    by 0x5417CE9: gog_graph_view_size_allocate (gog-graph.c:993)
==18202==    by 0x5415CAE: gog_view_size_allocate (gog-view.c:837)
==18202==    by 0x5452A63: gog_renderer_update (gog-renderer.c:1387)
==18202==    by 0x540213C: _goc_item_update_bounds (goc-item.c:328)
==18202==    by 0x5402CC7: goc_item_get_bounds (goc-item.c:580)
==18202==    by 0x54012D3: goc_group_update_bounds (goc-group.c:102)
==18202==    by 0x540213C: _goc_item_update_bounds (goc-item.c:328)
==18202==    by 0x5402CC7: goc_item_get_bounds (goc-item.c:580)
==18202==    by 0x54012D3: goc_group_update_bounds (goc-group.c:102)
==18202==    by 0x540213C: _goc_item_update_bounds (goc-item.c:328)
==18202==    by 0x5402CC7: goc_item_get_bounds (goc-item.c:580)
==18202==    by 0x54012D3: goc_group_update_bounds (goc-group.c:102)
==18202==    by 0x540213C: _goc_item_update_bounds (goc-item.c:328)
==18202==    by 0x5402CC7: goc_item_get_bounds (goc-item.c:580)
==18202==    by 0x53FD921: goc_canvas_draw (goc-canvas.c:57)
==18202==    by 0x58CA31D: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130)
==18202==    by 0x59EAC6F: gtk_widget_draw_marshallerv (gtkwidget.c:906)
==18202==    by 0x60BA3B6: _g_closure_invoke_va (gclosure.c:840)
==18202==    by 0x60D2E81: g_signal_emit_valist (gsignal.c:3238)
==18202==    by 0x60D3AE1: g_signal_emit (gsignal.c:3386)
==18202==    by 0x59EBE7D: _gtk_widget_draw_internal (gtkwidget.c:6165)
==18202==    by 0x59F7214: gtk_widget_send_expose (gtkwidget.c:6545)
==18202==    by 0x58CA141: gtk_main_do_event (gtkmain.c:1615)
==18202==    by 0x5E4E310: _gdk_window_process_updates_recurse (gdkwindow.c:4006)
==18202==    by 0x5E4E33F: _gdk_window_process_updates_recurse (gdkwindow.c:4051)
==18202==    by 0x5E4E33F: _gdk_window_process_updates_recurse (gdkwindow.c:4051)
==18202==    by 0x5E4BB5B: gdk_window_process_updates_internal (gdkwindow.c:4194)
==18202==    by 0x5E4BD8B: gdk_window_process_updates_with_mode (gdkwindow.c:4374)
==18202==  Uninitialised value was created by a stack allocation
==18202==    at 0x5415D37: gog_view_size_allocate_real (gog-view.c:543)

We have a disconnect between the documentation of gog_view_size_request:

 * When called @available holds the available space and @requisition is populated
 * with the desired size based on that input and other elements of the view or
 * its model's state (eg the position).

and all it's callers which provide the requisition undefined.

Implementations, such as gog_outlined_view_size_request really appears to
want the requisition defined on entry.

And that mess is at least 10 years old.

Most implementations don't seem to care what is passed in, so I am guessing
we can just go through the callers and zero the requestion before calling
gog_view_size_request.  Luckily there aren't that many.

We are setting is_plot_area_manual. I don't seem to be able to figure out how to set the size to be manual.

Valgrind complaints fixed.  It makes no visible difference as far as I can
tell.

We should be setting the graph size the manual as we are reading the chart. (ODF does not have an automatic.) I cannot figure out how to do that.

Obviously our 'automatic' doesn't work here correctly either.

In .gnumeric we have:
<property name="manual-size">size</property>
Wouldn't it make more sense to have a boolean?

The import from ODF wasn't really broken, but we now force the size to be set to manual.

I am filing a separate bug for the failure of automatic size to pick a sensible size. 

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.