Menu
▾
▴
plplot-devel
|
From: Mark de W. <m.d...@da...> - 2016-11-18 11:06:38
Attachments:
x19.cc
|
Hi, Recently I ran into an issue with the plplot 5.11.1 on Windows. The plmap code seems to omit lines entirely when a part of the line is not visible. This only occurs when the line is not visible on the left hand side of the plot. When a part is not visible on the right hand side it is properly shown. At my Debian Stable system I use the system's 5.10.0 version. There the issue doesn't occur. (I noticed the plmap code has been rewritten between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 5.11.1 and a recent master [d71e48], both have the issue. Attached a modified example 19 where the bug is shown. The first plot shows the entire coast of Ireland. The second plot should only omit a small part of the coast, but instead the entire coast has been removed. Only the internal border of Ireland remains visible. This seems to happen with all coast lines; I picked Ireland since it shows the bug nicely. Regards, Mark de Wever PS: It seems the old deprecated plmap code no longer shows a map (at least on Windows). I didn't investigate further, I just installed the shapelib library. PPS: There also seems to be another issue with a filled polygon map, but I'm still investigating. If it really is an issue, I'll report it. |
|
From: <p.d...@gm...> - 2016-11-18 17:30:49
|
Hi Mark Thanks for the report. I'll have a look at your example over the weekend and see if I can fix the issue. Phil Sent from my Windows 10 phone From: Mark de Wever Sent: 18 November 2016 11:06 To: plplot-dev Subject: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of themap Hi, Recently I ran into an issue with the plplot 5.11.1 on Windows. The plmap code seems to omit lines entirely when a part of the line is not visible. This only occurs when the line is not visible on the left hand side of the plot. When a part is not visible on the right hand side it is properly shown. At my Debian Stable system I use the system's 5.10.0 version. There the issue doesn't occur. (I noticed the plmap code has been rewritten between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 5.11.1 and a recent master [d71e48], both have the issue. Attached a modified example 19 where the bug is shown. The first plot shows the entire coast of Ireland. The second plot should only omit a small part of the coast, but instead the entire coast has been removed. Only the internal border of Ireland remains visible. This seems to happen with all coast lines; I picked Ireland since it shows the bug nicely. Regards, Mark de Wever PS: It seems the old deprecated plmap code no longer shows a map (at least on Windows). I didn't investigate further, I just installed the shapelib library. PPS: There also seems to be another issue with a filled polygon map, but I'm still investigating. If it really is an issue, I'll report it. |
|
From: Mark de W. <m.d...@da...> - 2017-07-24 14:03:47
|
Hi Phil, I saw the release of 5.13 is being planned. I wondered whether it is possible to fix this issue before the release. Regards, Mark de Wever On 18.11.16 18:30, p.d...@gm... wrote: > Hi Mark > Thanks for the report. I'll have a look at your example over the weekend and see if I can fix the issue. > > Phil > > Sent from my Windows 10 phone > > From: Mark de Wever > Sent: 18 November 2016 11:06 > To: plplot-dev > Subject: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of themap > > Hi, > > Recently I ran into an issue with the plplot 5.11.1 on Windows. The > plmap code seems to omit lines entirely when a part of the line is not > visible. This only occurs when the line is not visible on the left hand > side of the plot. When a part is not visible on the right hand side it > is properly shown. > > At my Debian Stable system I use the system's 5.10.0 version. There the > issue doesn't occur. (I noticed the plmap code has been rewritten > between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with > 5.11.1 and a recent master [d71e48], both have the issue. > > Attached a modified example 19 where the bug is shown. The first plot > shows the entire coast of Ireland. The second plot should only omit a > small part of the coast, but instead the entire coast has been removed. > Only the internal border of Ireland remains visible. This seems to > happen with all coast lines; I picked Ireland since it shows the bug nicely. > > > Regards, > Mark de Wever > > PS: It seems the old deprecated plmap code no longer shows a map (at > least on Windows). I didn't investigate further, I just installed the > shapelib library. > > PPS: There also seems to be another issue with a filled polygon map, but > I'm still investigating. If it really is an issue, I'll report it. > > |
|
From: Phil R. <p.d...@gm...> - 2017-07-24 21:08:52
|
Hi Mark Thanks for the reminder. I will definitely put as much effort as I can into getting this sorted pre release. Phil On 24 July 2017 at 13:27, Mark de Wever <m.d...@da...> wrote: > Hi Phil, > > I saw the release of 5.13 is being planned. I wondered whether it is > possible to fix this issue before the release. > > Regards, > Mark de Wever > > > On 18.11.16 18:30, p.d...@gm... wrote: >> >> Hi Mark >> Thanks for the report. I'll have a look at your example over the weekend >> and see if I can fix the issue. >> >> Phil >> >> Sent from my Windows 10 phone >> >> From: Mark de Wever >> Sent: 18 November 2016 11:06 >> To: plplot-dev >> Subject: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of >> themap >> >> Hi, >> >> Recently I ran into an issue with the plplot 5.11.1 on Windows. The >> plmap code seems to omit lines entirely when a part of the line is not >> visible. This only occurs when the line is not visible on the left hand >> side of the plot. When a part is not visible on the right hand side it >> is properly shown. >> >> At my Debian Stable system I use the system's 5.10.0 version. There the >> issue doesn't occur. (I noticed the plmap code has been rewritten >> between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with >> 5.11.1 and a recent master [d71e48], both have the issue. >> >> Attached a modified example 19 where the bug is shown. The first plot >> shows the entire coast of Ireland. The second plot should only omit a >> small part of the coast, but instead the entire coast has been removed. >> Only the internal border of Ireland remains visible. This seems to >> happen with all coast lines; I picked Ireland since it shows the bug >> nicely. >> >> >> Regards, >> Mark de Wever >> >> PS: It seems the old deprecated plmap code no longer shows a map (at >> least on Windows). I didn't investigate further, I just installed the >> shapelib library. >> >> PPS: There also seems to be another issue with a filled polygon map, but >> I'm still investigating. If it really is an issue, I'll report it. >> >> > |
|
From: Phil R. <p.d...@gm...> - 2017-09-28 20:32:08
|
Hi Mark and anyone else who is listening I have just fixed the map plots. Apologies that this has taken sooooooo long. The changes have just been pushed to the development version and have been checked on my windows machine. Note that you were correct also about there being an issue with using plmapfill. It turned out that the type specified in the shapefile was overriding the render type specified by the user. While I was there I realised there was a problem with rendering polygons that wrap round the whole globe such as Antarctica so that should now be fixed too. For those who may now how plfill works a bit better than me, something that is supported by shapefiles, but currently not by plmap, is holes. A polygon in a shapefile consists of multiple parts and clockwise parts are filled whereas anticlockwise parts are holes. Is this something we can do relatively easily with plfill or is it not really doable? Phil On 18 November 2016 at 10:41, Mark de Wever <m.d...@da...> wrote: > Hi, > > Recently I ran into an issue with the plplot 5.11.1 on Windows. The plmap > code seems to omit lines entirely when a part of the line is not visible. > This only occurs when the line is not visible on the left hand side of the > plot. When a part is not visible on the right hand side it is properly > shown. > > At my Debian Stable system I use the system's 5.10.0 version. There the > issue doesn't occur. (I noticed the plmap code has been rewritten between > 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 5.11.1 and a > recent master [d71e48], both have the issue. > > Attached a modified example 19 where the bug is shown. The first plot shows > the entire coast of Ireland. The second plot should only omit a small part > of the coast, but instead the entire coast has been removed. Only the > internal border of Ireland remains visible. This seems to happen with all > coast lines; I picked Ireland since it shows the bug nicely. > > > Regards, > Mark de Wever > > PS: It seems the old deprecated plmap code no longer shows a map (at least > on Windows). I didn't investigate further, I just installed the shapelib > library. > > PPS: There also seems to be another issue with a filled polygon map, but I'm > still investigating. If it really is an issue, I'll report it. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
|
From: Mark de W. <m.d...@da...> - 2017-09-29 11:19:38
Attachments:
plmapline-fix
|
Hi Phil,
On 28.9.17 22:31, Phil Rosenberg wrote:
> I have just fixed the map plots. Apologies that this has taken
> sooooooo long. The changes have just been pushed to the development
> version and have been checked on my windows machine. Note that you
> were correct also about there being an issue with using plmapfill. It
> turned out that the type specified in the shapefile was overriding the
> render type specified by the user.
Thanks for the fixes.
I just tested with HEAD and the polygon code no longer crashes.
Next I wanted to test with a map with lines and no fill. Unfortunately
plmapline also draws filled polygons. I did this test with the same
shapefiles [1] as the original test.
I assume it is caused by the code: src/plmap.c:324
if ( shapetype == SHPT_NULL )
{
shapetype = fileShapeType;
}
The attached patch lets plmapline draw lines instead of filled polygons.
I tested HEAD+patch and the coastal lines no longer disappear, so that
issue is also fixed.
I will do more testing next week, thanks again for the fixes.
[1]
http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
Regards,
Mark de Wever
|
|
From: Phil R. <p.d...@gm...> - 2017-09-29 10:56:53
|
Hi Mark, well spotted. Patch applied. Thanks for the contribution.
On 29 September 2017 at 11:00, Mark de Wever <m.d...@da...> wrote:
> Hi Phil,
>
> On 28.9.17 22:31, Phil Rosenberg wrote:
>>
>> I have just fixed the map plots. Apologies that this has taken
>> sooooooo long. The changes have just been pushed to the development
>> version and have been checked on my windows machine. Note that you
>> were correct also about there being an issue with using plmapfill. It
>> turned out that the type specified in the shapefile was overriding the
>> render type specified by the user.
>
>
> Thanks for the fixes.
>
> I just tested with HEAD and the polygon code no longer crashes.
>
> Next I wanted to test with a map with lines and no fill. Unfortunately
> plmapline also draws filled polygons. I did this test with the same
> shapefiles [1] as the original test.
>
> I assume it is caused by the code: src/plmap.c:324
> if ( shapetype == SHPT_NULL )
> {
> shapetype = fileShapeType;
> }
>
>
> The attached patch lets plmapline draw lines instead of filled polygons.
>
> I tested HEAD+patch and the coastal lines no longer disappear, so that issue
> is also fixed.
>
> I will do more testing next week, thanks again for the fixes.
>
>
> [1]
> http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
>
> Regards,
> Mark de Wever
|
|
From: Alan W. I. <ir...@be...> - 2017-09-29 19:31:57
|
On 2017-09-28 21:31+0100 Phil Rosenberg wrote: > Hi Mark and anyone else who is listening > I have just fixed the map plots. Apologies that this has taken > sooooooo long. The changes have just been pushed to the development > version and have been checked on my windows machine. Note that you > were correct also about there being an issue with using plmapfill. It > turned out that the type specified in the shapefile was overriding the > render type specified by the user. > > While I was there I realised there was a problem with rendering > polygons that wrap round the whole globe such as Antarctica so that > should now be fixed too. > @Mark: Thanks for spotting these issues that Phil just fixed. For your information, the git master branch version (what Phil just pushed) includes an earlier change by me where all the deprecated plmap cruft was removed. @Phil: After fixing up some minor style and trailing space issues (commit e60fba8 which I just pushed), I tested your changes in the build tree and for the shared libraries case on Linux using the -DBUILD_TEST=ON option. My build of the test_noninteractive target (which build PLplot libraries, bindings, devices, and examples and which executes each of our file devices for each of our C examples as well as comparing -dev psc results for all our supported languages) continues to work well. That is, there are no obvious configure, build, or run-time issue, and no regressions on the remaining (OCaml) PostScript differences with C example results. I also ran examples/c/x19c -dev xcairo , and there are no obvious rendering issues in those results (and presumably also for all other devices/languages). I also built the "validate" target (which tests your DocBook documentation changes for any validation errors) without issues. In sum, your current set of changes looks fine to me, and thanks for this effort! > For those who may now how plfill works a bit better than me, something > that is supported by shapefiles, but currently not by plmap, is holes. > A polygon in a shapefile consists of multiple parts and clockwise > parts are filled whereas anticlockwise parts are holes. Is this > something we can do relatively easily with plfill or is it not really > doable? I don't think that such a major change to plfill would be a good idea. For example, calls to plsurf3d (example 8) and plshades (example 16) end up at the lowest level as many different calls to plfill where presumably some end up as anti-clockwise fills and some end up as clockwise fills in difficult-to-predict ways. Therefore, would it be possible for you to honor this shapefile convention by simply not calling plfill from inside the plmap* routines whenever they run into an anticlockwise part and by changing our DocBook documentation of those routines appropriately? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
|
From: Alan W. I. <ir...@be...> - 2017-09-30 05:27:29
|
On 2017-09-30 02:39+0100 p.d...@gm... wrote: > > > Sent from my Windows 10 phone > > From: Alan W. Irwin > Sent: 29 September 2017 20:31 > To: Phil Rosenberg > Cc: Mark de Wever; plplot-dev > > >> For those who may now how plfill works a bit better than me, something >> that is supported by shapefiles, but currently not by plmap, is holes. >> A polygon in a shapefile consists of multiple parts and clockwise >> parts are filled whereas anticlockwise parts are holes. Is this >> something we can do relatively easily with plfill or is it not really >> doable? > > I don't think that such a major change to plfill would be a good idea. > For example, calls to plsurf3d (example 8) and plshades (example 16) > end up at the lowest level as many different calls to plfill where > presumably some end up as anti-clockwise fills and some end up > as clockwise fills in difficult-to-predict ways. > > I didn't mean to suggest changing plfill behaviour, just wondered if there was some way already to do this. > > Therefore, would it be possible for you to honor this shapefile > convention by simply not calling plfill from inside the plmap* > routines whenever they run into an anticlockwise part and by > changing our DocBook documentation of those routines appropriately? > > I don't think this works as we have to not render the holes in the first instance. E.g imagine an island with a lake. We want to fill just the land, it the lake. This would be a clockwise polygon for the island and an anticlockwise one for the lake. I think the only way to do this would be to convert the polygon with its holes to a single polygon, kind of like a c shape outline but with the ends of the c touching to make it like an o. Hi Phil: It sounds like you are asking if we have the ability to fill a simple (i.e. non self-intersecting, see <https://en.wikipedia.org/wiki/Simple_polygon>) polygon A everywhere other than where it intersects with a simple polygon B. (For your example A would be the polygon describing the island outline, and B would be the polygon describing the lake outline within that island.) If I have described that "not-intersect" case correctly, then the answer to your question is we do not currently have the ability to solve that problem. Which is another example of the truism that dealing with fill issues always seems to be difficult. However, that described problem could be solved with logic rather similar to that needed for solving the general problem of filling the intersection of two simple polygons. And we already do have that capability almost entirely implemented with the fill_intersection_polygon routine in src/plfill.c that I implemented back in 2009. That logic was compiled only if the USE_FILL_INTERSECTION_POLYGON macro is #defined, and the last commit message that mentioned USE_FILL_INTERSECTION_POLYGON is as follows: commit b8be9fcf8de6f5263bdd356a8745ba5878fc3036 Author: Alan W. Irwin <ai...@us...> Date: Mon Dec 28 17:41:45 2009 +0000 Fix cases where split 1/split 2 encompasses all/none of the polygon 2 vertices. This -DUSE_FILL_INTERSECTION_POLYGON=ON change finally gives good results for the first four pages of example 25, if the clip limits are shifted around to avoid the case (not implemented yet) where polygon crossings occur at vertices. So it appears I have the basic recursive algorithm working correctly, but there are some details (e.g., polygon crossings at vertices) still to be implemented. However, I think that is near the last commit where I worked on fill_intersection_polygon, because if I recall correctly if that logic was used for the large number of plfill calls we generate with our standard examples 8 and 16, I ran into bugs in the PL_NEAR_* logic. Therefore, I "temporarily" suspended working on that logic and never got back to it. However, two years ago (see your posts with the subject line "Bug in notcrossed() function of plfill.c" you discovered that our ordinary fill logic (used when USE_FILL_INTERSECTION_POLYGON is not #defined) also sometimes fails because of a PL_NEAR_PARALLEL bug. I have been putting off solving that bug (although it is certainly on my ToDo list for this release cycle). However, once that is solved, and the case of polygon crossings at vertices solved, then it is certainly possible that fill_intersection_polygon would just work as designed for all our examples. Of course, getting this all straightened out is going to take some substantial time. So for now, I think you should ignore this shapelib "hole" convention in the plmap routines while documenting this limitation as well. But after the current PL_NEAR_PARALLEL bug is definitively fixed, you might want to take a look at the fill_intersection_polygon routine again to see whether you think it is worth reviving and modifying for the "not-intersect" case that appears to sometimes be important for shapelib maps. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X