New (?) use of polypath() in package sp causing a problem?

[MacQueen, Don]

I have encountered a problem I've never seen before.

The problem is:

> x11(type='Xlib')
> plot(sfbound)
Warning message:
In polypath(x = mcrds[, 1], y = mcrds[, 2], border = border, col = col, :
Path drawing not available for this device

And nothing is plotted.

The object sfbound is a SpatialPolygonsDataFrame object with one simple
polygon in it.
Previously I have had no problem plotting such objects with
x11(type='Xlib').x11(type='cairo') succeeds.


It looks very likely that this relates to this entry in NEWS for R 2.12.0:

-- quote --
Added support for polygons with holes to the graphics
engine. This is implemented for the pdf(),
postscript(), x11(type="cairo"), windows(),
and quartz() devices (and associated raster formats),
but not for x11(type="Xlib") or xfig() or
pictex(). The user-level interface is the
polypath() function in graphics and
grid.path() in grid.
-- end quote --

That is, presuming a relatively recent change in sp in which polyplot() is
now used and previously was not, the change described in NEWS would
explain why I'm seeing this.



The problem is, I have found that for plots in which a very large number
of objects are being plotted, the Xlib version of X11() is much faster
than the cairo version. And I frequently plot spatial objects with
thousands of line segments in them, where the performance difference is
substantial, to the point of making use of the cairo version intolerable.

I guess the question is -- am I correct in this analysis?
If so, do I have any alternative when I need to plot spatial objects with
huge numbers of points/lines/polygons in them?

Thanks
-Don


> str(sfbound)
Formal class 'SpatialPolygonsDataFrame' [package "sp"] with 5 slots
  ..@ data       :'data.frame': 1 obs. of  1 variable:
  .. ..$ name: Factor w/ 1 level "Boundary.kml": 1
  ..@ polygons   :List of 1
  .. ..$ :Formal class 'Polygons' [package "sp"] with 5 slots
  .. .. .. ..@ Polygons :List of 1
  .. .. .. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
  .. .. .. .. .. .. ..@ labpt  : num [1:2] -121.7 37.7
  .. .. .. .. .. .. ..@ area   : num 3.71e-06
  .. .. .. .. .. .. ..@ hole   : logi FALSE
  .. .. .. .. .. .. ..@ ringDir: int 1
  .. .. .. .. .. .. ..@ coords : num [1:8, 1:2] -122 -122 -122 -122 -122
...
  .. .. .. ..@ plotOrder: int 1
  .. .. .. ..@ labpt    : num [1:2] -121.7 37.7
  .. .. .. ..@ ID       : chr "1"
  .. .. .. ..@ area     : num 3.71e-06
  ..@ plotOrder  : int 1
  ..@ bbox       : num [1:2, 1:2] -121.7 37.7 -121.7 37.7
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : chr [1:2] "x" "y"
  .. .. ..$ : chr [1:2] "min" "max"
  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slots
  .. .. ..@ projargs: chr "+proj=longlat +ellps=GRS80 +datum=NAD83
+no_defs +towgs84=0,0,0"


> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] sp_0.9-99   rmacq_1.1-8

loaded via a namespace (and not attached):
[1] grid_2.15.1    lattice_0.20-6 tools_2.15.1

       

--
Don MacQueen

Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Roger Bivand]

On Fri, 10 Aug 2012, MacQueen, Don wrote:

> I have encountered a problem I've never seen before.
>
> The problem is:
>
>> x11(type='Xlib')
>> plot(sfbound)
> Warning message:
> In polypath(x = mcrds[, 1], y = mcrds[, 2], border = border, col = col, :
> Path drawing not available for this device
>
> And nothing is plotted.
>
> The object sfbound is a SpatialPolygonsDataFrame object with one simple
> polygon in it.
> Previously I have had no problem plotting such objects with
> x11(type='Xlib').x11(type='cairo') succeeds.
>
>
> It looks very likely that this relates to this entry in NEWS for R 2.12.0:
>
> -- quote --
> Added support for polygons with holes to the graphics
> engine. This is implemented for the pdf(),
> postscript(), x11(type="cairo"), windows(),
> and quartz() devices (and associated raster formats),
> but not for x11(type="Xlib") or xfig() or
> pictex(). The user-level interface is the
> polypath() function in graphics and
> grid.path() in grid.
> -- end quote --
>
> That is, presuming a relatively recent change in sp in which polyplot() is
> now used and previously was not, the change described in NEWS would
> explain why I'm seeing this.
>
>
>
> The problem is, I have found that for plots in which a very large number
> of objects are being plotted, the Xlib version of X11() is much faster
> than the cairo version. And I frequently plot spatial objects with
> thousands of line segments in them, where the performance difference is
> substantial, to the point of making use of the cairo version intolerable.
>
> I guess the question is -- am I correct in this analysis?
> If so, do I have any alternative when I need to plot spatial objects with
> huge numbers of points/lines/polygons in them?

Don,

The analysis is correct (r1248). If the hole status of Polygon objects is
known to be correct, and the par(bg=) and pbg= values are set to match,
the plots will be the same. polypath analyses the polygon rings itself and
provides transparency in polygon painting - it doesn't paint in holes. The
legacy polygon function first painted the whole exterior ring, then
overpainted holes with the pbg= colour, which is "transparent" by default.
For many purposes, polypath is preferable, but as you know, cairo is much
slower than X11. So using X11 ought still to be OK, in the plot method set
usePolypath=FALSE. We can add back an option and set the argument by
default to that option if that would help.

The details for the plot method in the code:

https://r-forge.r-project.org/scm/viewvc.php/pkg/sp/R/SpatialPolygons-displayMethods.R?root=rspatial&view=log

and for spplot methods look in the same repository.

Hope this helps,

Roger

>
> Thanks
> -Don
>
>
>> str(sfbound)
> Formal class 'SpatialPolygonsDataFrame' [package "sp"] with 5 slots
>  ..@ data       :'data.frame': 1 obs. of  1 variable:
>  .. ..$ name: Factor w/ 1 level "Boundary.kml": 1
>  ..@ polygons   :List of 1
>  .. ..$ :Formal class 'Polygons' [package "sp"] with 5 slots
>  .. .. .. ..@ Polygons :List of 1
>  .. .. .. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
>  .. .. .. .. .. .. ..@ labpt  : num [1:2] -121.7 37.7
>  .. .. .. .. .. .. ..@ area   : num 3.71e-06
>  .. .. .. .. .. .. ..@ hole   : logi FALSE
>  .. .. .. .. .. .. ..@ ringDir: int 1
>  .. .. .. .. .. .. ..@ coords : num [1:8, 1:2] -122 -122 -122 -122 -122
> ...
>  .. .. .. ..@ plotOrder: int 1
>  .. .. .. ..@ labpt    : num [1:2] -121.7 37.7
>  .. .. .. ..@ ID       : chr "1"
>  .. .. .. ..@ area     : num 3.71e-06
>  ..@ plotOrder  : int 1
>  ..@ bbox       : num [1:2, 1:2] -121.7 37.7 -121.7 37.7
>  .. ..- attr(*, "dimnames")=List of 2
>  .. .. ..$ : chr [1:2] "x" "y"
>  .. .. ..$ : chr [1:2] "min" "max"
>  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slots
>  .. .. ..@ projargs: chr "+proj=longlat +ellps=GRS80 +datum=NAD83
> +no_defs +towgs84=0,0,0"
>
>
>> sessionInfo()
> R version 2.15.1 (2012-06-22)
> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>
> locale:
> [1] C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> other attached packages:
> [1] sp_0.9-99   rmacq_1.1-8
>
> loaded via a namespace (and not attached):
> [1] grid_2.15.1    lattice_0.20-6 tools_2.15.1
>
>
>
>

--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[MacQueen, Don]

(see below)


On 8/10/12 1:04 AM, "Roger Bivand" <[hidden email]> wrote:

>On Fri, 10 Aug 2012, MacQueen, Don wrote:
>
>> I have encountered a problem I've never seen before.
>>
>> The problem is:
>>
>>> x11(type='Xlib')
>>> plot(sfbound)
>> Warning message:
>> In polypath(x = mcrds[, 1], y = mcrds[, 2], border = border, col = col,
>>:
>> Path drawing not available for this device
>>
>> And nothing is plotted.
>>
>> The object sfbound is a SpatialPolygonsDataFrame object with one simple
>> polygon in it.
>> Previously I have had no problem plotting such objects with
>> x11(type='Xlib').x11(type='cairo') succeeds.
>>
>>
>> It looks very likely that this relates to this entry in NEWS for R
>>2.12.0:
>>
>> -- quote --
>> Added support for polygons with holes to the graphics
>> engine. This is implemented for the pdf(),
>> postscript(), x11(type="cairo"), windows(),
>> and quartz() devices (and associated raster formats),
>> but not for x11(type="Xlib") or xfig() or
>> pictex(). The user-level interface is the
>> polypath() function in graphics and
>> grid.path() in grid.
>> -- end quote --
>>
>> That is, presuming a relatively recent change in sp in which polyplot()
>>is
>> now used and previously was not, the change described in NEWS would
>> explain why I'm seeing this.
>>
>>
>>
>> The problem is, I have found that for plots in which a very large number
>> of objects are being plotted, the Xlib version of X11() is much faster
>> than the cairo version. And I frequently plot spatial objects with
>> thousands of line segments in them, where the performance difference is
>> substantial, to the point of making use of the cairo version
>>intolerable.
>>
>> I guess the question is -- am I correct in this analysis?
>> If so, do I have any alternative when I need to plot spatial objects
>>with
>> huge numbers of points/lines/polygons in them?
>
>Don,
>
>The analysis is correct (r1248). If the hole status of Polygon objects is
>known to be correct, and the par(bg=) and pbg= values are set to match,
>the plots will be the same. polypath analyses the polygon rings itself
>and
>provides transparency in polygon painting - it doesn't paint in holes.
>The
>legacy polygon function first painted the whole exterior ring, then
>overpainted holes with the pbg= colour, which is "transparent" by
>default.
>For many purposes, polypath is preferable, but as you know, cairo is much
>slower than X11. So using X11 ought still to be OK, in the plot method
>set
>usePolypath=FALSE. We can add back an option and set the argument by
>default to that option if that would help.
>
>The details for the plot method in the code:
>
>https://r-forge.r-project.org/scm/viewvc.php/pkg/sp/R/SpatialPolygons-disp
>layMethods.R?root=rspatial&view=log
>
>and for spplot methods look in the same repository.
>
>Hope this helps,
>
>Roger

It does help, especially the pointer to usePolypath=FALSE, which lets me
plot with X11/Xlib. Thank you.

In terms of adding back an option, would that be a global option of some
sort, so that users like me don't have to supply usePolypath=FALSE every
time?  That would indeed be helpful, if it's not too much trouble.

-Don

>
>>
>> Thanks
>> -Don
>>
>>
>>> str(sfbound)
>> Formal class 'SpatialPolygonsDataFrame' [package "sp"] with 5 slots
>>  ..@ data       :'data.frame': 1 obs. of  1 variable:
>>  .. ..$ name: Factor w/ 1 level "Boundary.kml": 1
>>  ..@ polygons   :List of 1
>>  .. ..$ :Formal class 'Polygons' [package "sp"] with 5 slots
>>  .. .. .. ..@ Polygons :List of 1
>>  .. .. .. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
>>  .. .. .. .. .. .. ..@ labpt  : num [1:2] -121.7 37.7
>>  .. .. .. .. .. .. ..@ area   : num 3.71e-06
>>  .. .. .. .. .. .. ..@ hole   : logi FALSE
>>  .. .. .. .. .. .. ..@ ringDir: int 1
>>  .. .. .. .. .. .. ..@ coords : num [1:8, 1:2] -122 -122 -122 -122 -122
>> ...
>>  .. .. .. ..@ plotOrder: int 1
>>  .. .. .. ..@ labpt    : num [1:2] -121.7 37.7
>>  .. .. .. ..@ ID       : chr "1"
>>  .. .. .. ..@ area     : num 3.71e-06
>>  ..@ plotOrder  : int 1
>>  ..@ bbox       : num [1:2, 1:2] -121.7 37.7 -121.7 37.7
>>  .. ..- attr(*, "dimnames")=List of 2
>>  .. .. ..$ : chr [1:2] "x" "y"
>>  .. .. ..$ : chr [1:2] "min" "max"
>>  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slots
>>  .. .. ..@ projargs: chr "+proj=longlat +ellps=GRS80 +datum=NAD83
>> +no_defs +towgs84=0,0,0"
>>
>>
>>> sessionInfo()
>> R version 2.15.1 (2012-06-22)
>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>>
>> locale:
>> [1] C
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> other attached packages:
>> [1] sp_0.9-99   rmacq_1.1-8
>>
>> loaded via a namespace (and not attached):
>> [1] grid_2.15.1    lattice_0.20-6 tools_2.15.1
>>
>>
>>
>>
>
>--
>Roger Bivand
>Department of Economics, NHH Norwegian School of Economics,
>Helleveien 30, N-5045 Bergen, Norway.
>voice: [phone]; fax [phone]
>e-mail: [hidden email]
>

--
Don MacQueen

Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[Roger Bivand]

On Fri, 10 Aug 2012, MacQueen, Don wrote:

> (see below)
>
>
> On 8/10/12 1:04 AM, "Roger Bivand" <[hidden email]> wrote:
>
>> On Fri, 10 Aug 2012, MacQueen, Don wrote:
>>
>>> I have encountered a problem I've never seen before.
>>>
>>> The problem is:
>>>
>>>> x11(type='Xlib')
>>>> plot(sfbound)
>>> Warning message:
>>> In polypath(x = mcrds[, 1], y = mcrds[, 2], border = border, col = col,
>>> :
>>> Path drawing not available for this device
>>>
>>> And nothing is plotted.
>>>
>>> The object sfbound is a SpatialPolygonsDataFrame object with one simple
>>> polygon in it.
>>> Previously I have had no problem plotting such objects with
>>> x11(type='Xlib').x11(type='cairo') succeeds.
>>>
>>>
>>> It looks very likely that this relates to this entry in NEWS for R
>>> 2.12.0:
>>>
>>> -- quote --
>>> Added support for polygons with holes to the graphics
>>> engine. This is implemented for the pdf(),
>>> postscript(), x11(type="cairo"), windows(),
>>> and quartz() devices (and associated raster formats),
>>> but not for x11(type="Xlib") or xfig() or
>>> pictex(). The user-level interface is the
>>> polypath() function in graphics and
>>> grid.path() in grid.
>>> -- end quote --
>>>
>>> That is, presuming a relatively recent change in sp in which polyplot()
>>> is
>>> now used and previously was not, the change described in NEWS would
>>> explain why I'm seeing this.
>>>
>>>
>>>
>>> The problem is, I have found that for plots in which a very large number
>>> of objects are being plotted, the Xlib version of X11() is much faster
>>> than the cairo version. And I frequently plot spatial objects with
>>> thousands of line segments in them, where the performance difference is
>>> substantial, to the point of making use of the cairo version
>>> intolerable.
>>>
>>> I guess the question is -- am I correct in this analysis?
>>> If so, do I have any alternative when I need to plot spatial objects
>>> with
>>> huge numbers of points/lines/polygons in them?
>>
>> Don,
>>
>> The analysis is correct (r1248). If the hole status of Polygon objects is
>> known to be correct, and the par(bg=) and pbg= values are set to match,
>> the plots will be the same. polypath analyses the polygon rings itself
>> and
>> provides transparency in polygon painting - it doesn't paint in holes.
>> The
>> legacy polygon function first painted the whole exterior ring, then
>> overpainted holes with the pbg= colour, which is "transparent" by
>> default.
>> For many purposes, polypath is preferable, but as you know, cairo is much
>> slower than X11. So using X11 ought still to be OK, in the plot method
>> set
>> usePolypath=FALSE. We can add back an option and set the argument by
>> default to that option if that would help.
>>
>> The details for the plot method in the code:
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/sp/R/SpatialPolygons-disp
>> layMethods.R?root=rspatial&view=log
>>
>> and for spplot methods look in the same repository.
>>
>> Hope this helps,
>>
>> Roger
>
> It does help, especially the pointer to usePolypath=FALSE, which lets me
> plot with X11/Xlib. Thank you.
>
> In terms of adding back an option, would that be a global option of some
> sort, so that users like me don't have to supply usePolypath=FALSE every
> time?  That would indeed be helpful, if it's not too much trouble.

Committed to the sp package in the rspatial project on R-Forge as revision
1269. If you could check and see whether this works for you, I'd be
grateful - you would add set_Polypath(FALSE) early in your script, and it
should work everwhere plot() is called on a SpatialPolygons object.

Roger

>
> -Don
>
>>
>>>
>>> Thanks
>>> -Don
>>>
>>>
>>>> str(sfbound)
>>> Formal class 'SpatialPolygonsDataFrame' [package "sp"] with 5 slots
>>>  ..@ data       :'data.frame': 1 obs. of  1 variable:
>>>  .. ..$ name: Factor w/ 1 level "Boundary.kml": 1
>>>  ..@ polygons   :List of 1
>>>  .. ..$ :Formal class 'Polygons' [package "sp"] with 5 slots
>>>  .. .. .. ..@ Polygons :List of 1
>>>  .. .. .. .. ..$ :Formal class 'Polygon' [package "sp"] with 5 slots
>>>  .. .. .. .. .. .. ..@ labpt  : num [1:2] -121.7 37.7
>>>  .. .. .. .. .. .. ..@ area   : num 3.71e-06
>>>  .. .. .. .. .. .. ..@ hole   : logi FALSE
>>>  .. .. .. .. .. .. ..@ ringDir: int 1
>>>  .. .. .. .. .. .. ..@ coords : num [1:8, 1:2] -122 -122 -122 -122 -122
>>> ...
>>>  .. .. .. ..@ plotOrder: int 1
>>>  .. .. .. ..@ labpt    : num [1:2] -121.7 37.7
>>>  .. .. .. ..@ ID       : chr "1"
>>>  .. .. .. ..@ area     : num 3.71e-06
>>>  ..@ plotOrder  : int 1
>>>  ..@ bbox       : num [1:2, 1:2] -121.7 37.7 -121.7 37.7
>>>  .. ..- attr(*, "dimnames")=List of 2
>>>  .. .. ..$ : chr [1:2] "x" "y"
>>>  .. .. ..$ : chr [1:2] "min" "max"
>>>  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slots
>>>  .. .. ..@ projargs: chr "+proj=longlat +ellps=GRS80 +datum=NAD83
>>> +no_defs +towgs84=0,0,0"
>>>
>>>
>>>> sessionInfo()
>>> R version 2.15.1 (2012-06-22)
>>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>>>
>>> locale:
>>> [1] C
>>>
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>
>>> other attached packages:
>>> [1] sp_0.9-99   rmacq_1.1-8
>>>
>>> loaded via a namespace (and not attached):
>>> [1] grid_2.15.1    lattice_0.20-6 tools_2.15.1
>>>
>>>
>>>
>>>
>>
>> --
>> Roger Bivand
>> Department of Economics, NHH Norwegian School of Economics,
>> Helleveien 30, N-5045 Bergen, Norway.
>> voice: [phone]; fax [phone]
>> e-mail: [hidden email]
>>
>
>

--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo