Skip to content

Sleuthing X windows bug in Ubuntu Gutsy

14 messages · Tim Keitt, Roger Bivand, PUJAN RAJ REGMI +3 more

#
I'm trying to see if I can track down a bug in X windows that causes
it to crash when plotting (I believe) very small filled polygons (or
it may have to do with large numbers of polygons). I first noticed
this running QGIS. Loading a PostGIS layer with ~3K polygons will
cause X to abort. I can load the layer if I have already zoomed into a
smaller region of the coverage. Once I try to zoom out to the full
extent, X dies.

So I tried loading the polygons into "sp" using "readOGR" which works
great. I could then plot the polygons, no problem. But when I called
"spplot" which I believe fills the polygons, same problem. X crashes.

Can anyone confirm this behavior? Try plotting a large number of
polygons with spplot and also try very small polygons (less than a
pixel size). I can send around the shapefile if anyone is interested.
It contains GSHHS coastlines for Micronesia.

THK
#
On Fri, 28 Mar 2008, Tim Keitt wrote:

            
I can't reproduce any problems on

http://www.census.gov/geo/cob/bdy/co/co00shp/co99_d00_shp.zip

library(rgdal)
usc <- readOGR(".", "co99_d00")
# OGR data source with driver: ESRI Shapefile
# Source: ".", layer: "co99_d00"
# with  3489  rows and  9  columns
plot(usc, col=rainbow(52)[usc$state1])
spplot(usc, "STATE", col.regions=rainbow(52))

and:

$ xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    60802000
X.Org version: 6.8.2
...
screen #0:
   dimensions:    1280x1024 pixels (361x271 millimeters)
   resolution:    90x96 dots per inch
   depths (7):    16, 1, 4, 8, 15, 24, 32

Could you please make your file available - maybe there is something 
particular about it? Is there way of asking X which driver it is using 
(here nvidia proprietary for Legacy GPU version (1.0-71xx series), full 
details in /proc/driver/nvidia)?

Roger

  
    
#
On Sat, Mar 29, 2008 at 8:41 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
I'll put the file someplace where it can be downloaded.

This has happened on my desktop using both nvidia and vesa drivers and
on my laptop with the intel driver.

THK

  
    
#
On Sat, Mar 29, 2008 at 10:01 AM, Tim Keitt <tkeitt at gmail.com> wrote:
OK. It is at http://www.keittlab.org/~tkeitt/melanesia.tgz. I just
confirmed loading this file into QGIS 0.9.2-rc2 reproduces the X
crash. I'll test the same under Hardy shortly (requires a chroot).

THK

  
    
#
On Sat, Mar 29, 2008 at 10:25 AM, Tim Keitt <tkeitt at gmail.com> wrote:
I just confirmed the same bug under Hardy Heron again using QGIS
0.9.2-rc2. I'll try with "spplot" next.

THK

  
    
#
On Sat, 29 Mar 2008, Tim Keitt wrote:

            
I'll try melanesia on my system, please try the US counties shapefile on 
yours.

Roger

  
    
#
On Sat, 29 Mar 2008, Roger Bivand wrote:

            
The melanesia shapefile does not cause any problems on my system as 
documented earlier with spplot(). I guess that your X(s) is/are fresher 
than mine, but trying on another Linux system (F7, X.org 1.3.0, intel 
driver) shows no problems either, I'm afraid.

Roger

  
    
#
On Sat, Mar 29, 2008 at 12:21 PM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10400090
X.Org version: 1.4.0.90

Sigh. Debugging X is such a pain...

THK

  
    
#
Hi Tim,

I'm running Gutsy and have no problem working with QGIS (0.9.2-RC1) on a
polygon layer with over 7K polygons doing a choropleth map from a
shapefile set. I think you have hardware/X11 issues, not OGR related
software issues. To confirm this, you might want to load the problem
layer into UDig and see if the same thing happens, since you would then
be out of OGR and into GeoTools.

Dan
On Sat, 2008-03-29 at 12:36 -0500, Tim Keitt wrote:
#
On Sat, Mar 29, 2008 at 3:51 PM, Dan Putler <dan.putler at sauder.ubc.ca> wrote:
That's my point. It is an interaction between X and the properties of
this set of polygons. The fact that it is repeatable across two
different machines and three different videos drivers and two
different software programs suggests strongly that there is a bug in
the X server.

Please try the file at http://www.keittlab.org/~tkeitt/melanesia.tgz
and see if loading it into QGIS causes a crash.

THK

  
    
#
Tim Keitt wrote:

            
Just a suggestion, but have you tried it with an Xnest, or an Xvfb 
server? That way it should only crash that server and not the one you 
are working on.

Barry
#
On Sat, Mar 29, 2008 at 4:36 PM, Barry Rowlingson
<b.rowlingson at lancaster.ac.uk> wrote:
Great suggestion. Yes, I did run a second X server and was able to
crash it without loosing my session. I got as far as trying to run the
X server from within gdb, but it hangs and I have to power cycle.

THK

  
    
1 day later
#
Hi Roger et. al.!

Again, let me start by thanking the Spatial R group for almost 2 years of
fantastic help in my research.  I am currently working on a part of my
puzzle that can be easily done in image processing software such as ENVI but
I am looking for an R solution.  I have a list of lines objects gathered as
a SpatialLines object that "sits" on top of a SpatialGridDataFrame object.
I would like to collect all of the spectral intensity values (or z values)
from the "SpatialGridDataFrame" object that lie along the transect made from
any line of my SpatialLines object.  Here is imaginary code for what I would
like to accomplish

library(sp)
tmp.lines <- Lines(Line(rbind(rank.max2.test[1,1:2], tmp.coords[1,])),
ID=as.character(1))
looplen <- nrow(tmp.coords)
for ( i in 2:looplen){
i <- Lines(Line(rbind(rank.max2.test[1,1:2], tmp.coords[i,])),
ID=as.character(i))
tmp.lines <- c(tmp.lines, i)
}
tmp.slines <- SpatialLines(tmp.lines, proj4string = CRS(as.character(NA)))

where rank.max2.test[1,1:2]
[1] 945112.5 859834.5

And 
tmp.coords[1,]
[1] 945110.6 859848.5

## The above code works great at producing a SpatialLines object with
nrow(tmp.coords) lines

NOW the part that doesn't work
 Transect.values <- overlay(SGDF, tmp.slines[1])

Where SGDF is an object of class SpatialGridDataFrame.

Can this be accomplished as a SpatialLines class (or some polyline general
class) or does the overlay need points?  If I must use points to extract the
SGDF values, is there a way to convert the SpatialLines object into a set of
point coordinates at fixed intervals along the line.  Currently the lines
are only defined as starting and ending coordinates but I would want the
line "points" to occur every 1 meter along the line transect.

Many thanks in advance for any help in this endeavor,
Andrew

Andrew Niccolai
Doctoral Candidate
Yale University
office (203) 432-5144
cell (860) 402-6079