gis.m/Map Display fails to handle vector layers with multiple databse layers

[ploewe]

GRASS 6.3 gives strange effects when one is attempting to query or display data from database layers greater than 1. This can be reproduced.

Example:

A polygon layer has been connected (in postgres) to two tables in layer 1 and layer 2:

GRASS 6.3.0 (meteo):~ > v.db.connect -p map=counties_pie01 Vector map <counties_pie01> is connected by: layer <1> table <counties_pie01> in database <host=localhost,dbname=meteo> through driver <pg> with key <cat> layer <2> table <counties_pie01_a> in database <host=localhost,dbname=meteo> through driver <pg> with key <cat>

The layer can be displayed in a map display, including its centroids. While the "Layer for labels"/"Layer for query" is set to 1 (default), performance is normal.

Hell breaks loose when the "Layer for query" is set to "2": Out of a sudden all centroids and filled areas disappear from from the map display (polygon outlines are still displayed).

The phenomena for "Layer for label"=2 are less severe: A "Attribute col for labels" from the second table is just ignored, while polygon outlines, area fills and centroids are properly rendered.

The gis.m output window does not provide any error messages or warnings while these phenomena occur.

[mlennert]

Replying to ploewe:

GRASS 6.3 gives strange effects when one is attempting to query or display data from database layers greater than 1. This can be reproduced.

Example:

A polygon layer has been connected (in postgres) to two tables in layer 1 and layer 2:

GRASS 6.3.0 (meteo):~ > v.db.connect -p map=counties_pie01 Vector map <counties_pie01> is connected by: layer <1> table <counties_pie01> in database <host=localhost,dbname=meteo> through driver <pg> with key <cat> layer <2> table <counties_pie01_a> in database <host=localhost,dbname=meteo> through driver <pg> with key <cat>

Could you give us the output of v.category option=report ?

Moritz

[cmbarton]

This appears to be a bug in d.vect, not in the TclTk gui. I just tried this out in the GRASS 6.4 development version from the SVN.

From the command line in an xmon...

GRASS 6.4.svn (Spearfish60_test):~ > d.vect map=archsites@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=2 cat=1-10

This displays sites with cats 1-10

GRASS 6.4.svn (Spearfish60_test):~ > d.erase GRASS 6.4.svn (Spearfish60_test):~ > d.vect map=archsites@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=2 lsize=8 xref=left yref=center llayer=2 cat=1-10

This displays nothing

The labeling is worse. I can get labels from layer 1 in the GUI, but from the command line to an xmon, I get...

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. ERROR eof from graphics driver.

Trying to get labels from layer 2 gives me nothing.

I'm trying this with Spearfish, archsites (I've added columns), and the dbf driver. I'm using a Mac OSX 10.5.5. But this seems to be a cross-platform problem.

Michael

[martinl]

Replying to cmbarton:

> GRASS 6.4.svn (Spearfish60_test):~ > d.vect map=archsites@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=2 cat=1-10

This displays sites with cats 1-10

> GRASS 6.4.svn (Spearfish60_test):~ > d.erase
> GRASS 6.4.svn (Spearfish60_test):~ > d.vect map=archsites@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=2 lsize=8 xref=left yref=center llayer=2 cat=1-10

This displays nothing

well, and archsites@PERMANENT contains some elements in layer 2?

v.category archsites@PERMANENT opt=report

?

Martin

[neteler]

Replying to cmbarton:

The labeling is worse. I can get labels from layer 1 in the GUI, but from the command line to an xmon, I get...

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. ERROR eof from graphics driver.

See ​http://lists.osgeo.org/pipermail/grass-user/2009-April/050038.html

and

​http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html#SECDAEMONVSFRAMEWORKS

[kyngchaos]

I think the database problem ultimately boils down to displaying text with FreeType, as Michael found.

The error means what it says. It comes from FreeType when the old-mac-fonts options is enabled, and there is nothing that FreeType can do to "fix" it, because old-mac-fonts means it needs to use Core Foundation. The real solution is that programmers using FreeType on OS X 10.5 need to do as the error suggests, exec() after fork(). This forum topic at Apple describes it concisely:

​http://discussions.apple.com/message.jspa?messageID=7875639

The quick solution is to build FreeType without old-mac-fonts. But there are many with an investment in old Resource-fork based fonts (mainly PostScript) and this is not a good solution ($$ to upgrade to OTF).

The problem doesn't seem to occur in OS X 10.6. I don't know why. Maybe Apple saw that so many had problems with this and reverted, or at least dropped the error (they probably still recommend fork + exec).

[mlennert]

I think the FreeType issue is a different issue than that reported by the OP.

Concerning this original problem, we still do not have any information of whether the maps displayed actually had any category values in layer 2 (as Martin pointed out: archsites in spearfish does not have any info on layer 2). And in the case of the OP, just because one connects a map with v.db.connect on another layer, this does not mean that the map actually has any info on that layer.

The following works for me

v.category archsites option=add layer=2 output=myarchsites
d.vect map=myarchsites@user1 color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=2 lsize=8 xref=left yref=center llayer=1
d.vect map=myarchsites@user1 color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=2 lsize=8 xref=left yref=center llayer=1 cat=1-10

In my eyes this bug can be closed as worksforme, and if there is an issue with FreeType on Mac, please open another bug.

Moritz

[cmbarton]

Hi,

For the record, when I verified the layer problem, I used a special version of archsites that I'd modified for testing and teaching. It does have information in layer 2.

Michael

[mlennert]

Replying to cmbarton:

Hi,

For the record, when I verified the layer problem, I used a special version of archsites that I'd modified for testing and teaching. It does have information in layer 2.

Ok. Can you still reproduce the issue, i.e. by following my steps above ?

When you said

d.vect map=archsites@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape >type=point,line,boundary,area icon=basic/circle size=5 layer=2 lsize=8 xref=left yref=center >llayer=2 cat=1-10

This displays nothing

the first thing I would test is v.category archsites@PERMANENT option=report, just to make sure that there are cat values 1-10 on that layer. Just to be sure we agree: the above line should only show the circles, nothing else, or ?

Moritz

[marisn]

Tested with current 6.4.3 SVN. All features are rendered correctly according to their levels.