<div dir="ltr"><div><div><div><div>Ben,<br><br>1. Exporting data like this was never an intended use => I understand your point. In fact if calling the underlying C++ code for tricontour had been easy I would happily have skipped the call to MPL. All I'm interested in is the polygons coordinates really.<br><br></div>2. good news :)<br><br></div>3. please find the script attached.<br><br></div>thanks <br></div>Francis<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-01 22:33 GMT+01:00 Benjamin Root <span dir="ltr"><<a href="mailto:ben.v.root@gmail.com" target="_blank">ben.v.root@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Francis,<br></div><div><br>1. Keep in mind, matplotlib is a plotting library first. Path simplification takes into account the resolution of the output device when used for drawing and essentially simplifies out any unresolvable features, which greatly reduces drawing time for complex plots. Exporting data like this was never an intended use.<br><br></div>2. I will have to respectfully disagree with Ian on this point. to_polygons() is not a private method and it is perfectly reasonable to expect it to be used by people outside the matplotlib codebase. As a developer, I would reject any patches that changes the output semantics of to_polygons() without going through a lengthy deprecation cycle. Plus, the primary use of this method is for easy input to Polygon artist objects, which has a constructor that isn't going to change, so why should to_polygons() change?<br><div><div><div><br>3. Without the source example data, I am at a bit of a loss for what is happening here. I could come up with all sorts of guesses, but I can't tell you for sure without having something I can run myself.<br><br></div><div>Cheers!<br></div><div>Ben Root<br><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 1, 2015 at 4:18 PM, Francis Chabouis <span dir="ltr"><<a href="mailto:fchabouis@gmail.com" target="_blank">fchabouis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Thanks Ben for your answer.<br><br></div>I didn't know about that should_simplify attribute. It was effectively the reason for the disappearing points. Thanks a lot.<br></div><div>I still have a few questions if you don't mind :<br><br></div><div>1. [low importance] Isn't it weird to have this attribute set to True by default ? I would find it  more natural if simplification had to be explicitly requested.<br></div><div><br>2. You say "The first element of that list is the external vertexes, and the rest of
 the elements are all vertex lists of the internal holes." I like this a lot, but are you sure it is true ? As it comes in contradiction with Ian Thomas explanation :<br><br>"The returned geometries are purposefully not documented.  They are an 
'implementation detail' and not considered part of the public interface.
 and as such they could change at any time and hence should not be 
relied upon.  Of course you can choose to access them if you wish, as I 
do myself sometimes, but we make no promises about what the order of the
 polygons is, or that it won't change tomorrow."<br><br><a href="http://matplotlib.1069221.n5.nabble.com/Structure-of-contour-object-returned-from-tricontourf-td44203.html" target="_blank">http://matplotlib.1069221.n5.nabble.com/Structure-of-contour-object-returned-from-tricontourf-td44203.html</a><br><br></div><div>3. I have done a simple test and the output looks like this (2 rings):<br><br><img alt="Images intégrées 1" src="cid:ii_1515f5cfe61c38c7" height="380" width="568"><br><br></div><div>So I'm a bit confused as :<span><br><br>cs = plt.tricontourf(t, v, levels)<br></span>#cs.collections has 1 element (ok as there is only one level)<br><br>for i,collection in enumerate(cs.collections):<br></div><div>    for path in collection.get_paths():<br>    #collection.get_paths() has only 1 element, I would eventually have expected 2 (1 for each ring)</div><div>    polygons = path.to_polygons()<br>    # polygons has 4 elements : the 4 rings are stored at the same place<br></div><div>    # how can I recognise the exteriors from the interiors ?<br><br></div><div>Thanks for your help,<br></div><div>Francis<br></div><div><br> <br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-30 19:37 GMT+01:00 Benjamin Root <span dir="ltr"><<a href="mailto:ben.v.root@gmail.com" target="_blank">ben.v.root@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Francis,<br><br></div>I bet you that the inconsistency in the number of vertexes is due to path simplification. The list of Path objects you get when you call get_paths() on the collection object each have an attribute "should_simplify" and that defaults to True. Set it to False, and you will have all of the vertexes. Also, what you want to call is to_polygons() on the Path object after setting "should_simplify" to False. That will return a list of lists. The first element of that list is the external vertexes, and the rest of the elements are all vertex lists of the internal holes.<br><br></div><div>I hope this description helps. I can't really give you more detailed description due to the fact that I have developed software that does this very thing for my employer, but what you want is certainly possible.<br><br></div><div>Also, as for whether or not we would want a geojson export function available for matplotlib, it isn't really correct to have it in matplotlib because we are a graphing library. However, it would make sense to make the process of extracting the polygon information a bit easier, which would make it easier for another package to be made that would export that information into various data formats, not just geojson.<br><br></div><div>Cheers!<br></div><div>Ben Root<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Nov 30, 2015 at 12:46 PM, Francis Chabouis <span dir="ltr"><<a href="mailto:fchabouis@gmail.com" target="_blank">fchabouis@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hello,<br></div>I'm having some difficulties with the results of the tricontour function. What I'm trying to achieve is fairly simple : I'd like to export the results of the tricontour function as a geoJson. (I think a function doing exactly this job would be nice to have in the library).<br><br></div><div>I wrote this :<br><br>cs = plt.tricontourf(t, v, levels)<br><br>for i,collection in enumerate(cs.collections):<br>    for path in collection.get_paths():<br><br><br></div><div>Now I have this path object.<br></div><div><br>My first problem : when I check the number of vertices (via len(path.vertices)) I get 732 vertices.<br></div><div>If I try to access those vertices with iter_segments as recommended in the doc, I get only 125 vertices.<br></div><div>seg = path.iter_segments()<br></div><div>print len(list(seg))<br>==> 125<br><br></div><div>Am I doing something wrong, or is it possibly a bug ? <br><br></div><div>My second problem : geoJson works with interior and exterior rings. To describe a polygon with a hole in it, we first declare a closed line (that will be the exterior) and all the subsequent lines will be the "holes" (interiors). It seems that what I get from iter_segments and to_polygons is a bunch of lines, but there is no way to know which is an interior, which is an exterior. But I guess this must be stored somewhere as MPL is able to draw a graph from this information !<br><br></div><div>Any hints on how I should proceed ?<br></div><div>Let me know if you need additional information. <br><br></div><div>Thanks<br><br></div><div>ps : I got some of my infos from this thread : <a href="http://matplotlib.1069221.n5.nabble.com/Structure-of-contour-object-returned-from-tricontourf-td44203.html" target="_blank">http://matplotlib.1069221.n5.nabble.com/Structure-of-contour-object-returned-from-tricontourf-td44203.html</a><br><br></div><div>ps2 : If I can write this function I would be happy to integrate it in the lib if you're interested.<br></div></div>
<br></div></div>_______________________________________________<br>
Matplotlib-users mailing list<br>
<a href="mailto:Matplotlib-users@python.org" target="_blank">Matplotlib-users@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-users" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>