php-mapscript, OGR, and GRASS

[cavallini@…]

When we try to use (via OGR) a grass vector, we get an error:

[Wed Jul 19 09:57:08 2006] [error] [client 192.168.0.110] PHP Warning:
[MapServer Error]: msDrawMap(): Failed to draw layer named
'grass_POSTGRES'.\n in /home/Documenti/pub/prove_w/visuo_map_file.php on
line 6
[Wed Jul 19 09:57:08 2006] [error] [client 192.168.0.110] PHP Warning:
[MapServer Error]: msOGRLayerInitItemInfo(): Invalid Field name:
atc_num\n in /home/Documenti/pub/prove_w/visuo_map_file.php on line 6
[Wed Jul 19 09:57:08 2006] [error] [client 192.168.0.110] PHP Fatal
error:  Call to a member function on a non-object in
/home/Documenti/pub/prove_w/visuo_map_file.php on line 8

Apparently mapscript adds a \n to the name of the database field, and
postgres does not accept it.
shp2img and mapserv can generate the map without problems.
This happens with php4-mapscript 4.8.3-2 and libgdal1-1.3.1-grass from
Debian etch.

[dmorissette]

Paolo, do you just call ms_newMapObj() and then $map->draw() right away or do
you perform any operations on this layer prior to rendering it with MapScript?

I ask this because I see the '\n' in the error message, but it is probably not
related to the problem, I think it is Apache converting line breaks in the PHP
warnings into visible '\\' + 'n', see the other error messages in your log, they
have the same \n in them just before the "in <filename.php>" part.

Unfortunately I'm not familiar with GRASS vector data sources, so I'll CC Frank
who might know better. Also, if you could copy your layer definition and the
relevant parts of your script to this bug that would help in figuring the source
of the problem.

[cavallini@…]

Hi Daniel.
Thanks for the interest. Here are the info you required:
- layer definition:

LAYER
  NAME "grass_POSTGRES"
  TYPE POLYGON
  CONNECTIONTYPE OGR
  
CONNECTION "/home/Documenti/datigrass/Toscana/PERMANENT/vector/t_comuni_2003/head"
  DATA "1"
  STATUS ON
  LABELITEM 'atc_num'
  
  CLASS
    NAME "Ne so veramente troppe"
#     EXPRESSION ([atc_num]=13)
    STYLE
      COLOR 0 240 0
      OUTLINECOLOR 0 100 0
    END
    LABEL
        COLOR 200 0 0
        TYPE TRUETYPE
        FONT arial
        SIZE 10
        ANTIALIAS TRUE
        POSITION CC
	ANGLE AUTO
# 	OFFSET 0 2 
        #MINDISTANCE 300
        BUFFER 2
      END
  END
END


- PHP Script:

<?

$map= ms_newMapObj('grass.map');

$img = $map->draw();

$url = $img->saveWebImage();

?>

<img src="<?echo $url?>" border="1">



- Errors in Apache log:

[Tue Aug 01 10:11:11 2006] [error] [client 192.168.0.110] PHP Warning:  
[MapServer Error]: msDrawMap(): Failed to draw layer named 'grass_POSTGRES'.
\n in /home/Documenti/pub/prove_w/visuo_map_file.php on line 6
[Tue Aug 01 10:11:11 2006] [error] [client 192.168.0.110] PHP Warning:  
[MapServer Error]: msOGRLayerInitItemInfo(): Invalid Field name: atc_num\n 
in /home/Documenti/pub/prove_w/visuo_map_file.php on line 6
[Tue Aug 01 10:11:11 2006] [error] [client 192.168.0.110] PHP Fatal error:  
Call to a member function saveWebImage() on a non-object 
in /home/Documenti/pub/prove_w/visuo_map_file.php on line 8

[dmorissette]

Since you just open the map and then draw() it right away without making any
changes to it, I can't see anything specific to PHP MapScript that can be
interfering with the map object to cause this error, it would have to be
something else that is triggered only in the PHP case.

Frank: any idea?

For instance, looking at the OGR docs for the GRASS driver I see references to a
GISBASE environment variable. Is this variable set and available in the PHP
script environment inside the web server?

Another possibility could be that the web user does not have sufficient
permissions to read all parts of the GRASS dataset. The layer is called
"grass_POSTGRES", is this because part of the data is in a prosgres database?
Could we have a permission problem where the web user is unable to connect to
the database?

Are you able to draw this map using mapserv via the Apache server? You wrote
that "shp2img and mapserv can generate the map without problems", but when you
tested with mapserv, was it at the command-line or via the web server? If the
problem is the missing GISBASE env. var or permissions then mapserv should fail
the same way when it is called via the web server.

[cavallini@…]

We think it should be PHP-mapscript-specific, because the same mapfile with both
shp2img and mapserv (via the web server) returns the correct image.
The GISBASE variable should therefore be ok. The data are in PostgreSQL, but we
checked the permissions, and they are ok.

[dmorissette]

Do you really run shp2img via the web server?

Anyway, that's not the point, if mapserv works fine under the web server then
there has to be something PHP-specific. Possibly a side-effect coming from
another PHP module?

Is your PHP build with postgresql support? If yes are you sure that it is built
against the exact same version of libpq? Perhaps try rebuilding your PHP without
postgresql support (or avoir loading the module at runtime if it's not static)
and then see if that makes any difference. We've seen side-effects caused by
conflicting versions of libs before. This could be what is happening now as well.

[cavallini@…]

I think this is unlikely, as everything is from Debian testing (no php
compilation ,etc). pgsl moduled is loaded at runtime, so I commented out and
reloaded apache, but the problem is still the same.
The bug even survived the upgrade from php4 to php5.
Thanks a lot for following this up.
pc

[dmorissette]

Paolo closed this as invalid in the old bugzilla instance:

---

It works. One has just to be careful to pass the environment variables to grass.