Sorry, but it's not that simple :-(: My current layer configuration:
I will write a PostGIS query and see what differences turn up between
the line and polygon tables and if it is really the geometry as Jukka
Rahkonen and Steve W suggest ...
Layer
Connection "host=10.0.0.2 dbname=osm user=me password=guessit"
Connectiontype Postgis
Data "way from (select osm_id, way, admin_level from
planet_osm_polygon) as foo using unique osm_id using srid=2169"
# Filter "tags ?& ARRAY['boundary', 'admin_level']"
name "boundaries"
status on
type line
units meters
Projection
"init=epsg:3857"
End
Class
expression ("[admin_level]" = "6")
name "communes"
Style
color 10 10 10
width 2
End
End
End
Am 2013-09-06 10:16, schrieb thomas bonfort:
Frank,
can you try without including the hstore tags in your select?
--
thomas
On Thu, Sep 5, 2013 at 3:49 PM, Frank Broniewski <[email protected]> wrote:
Ok, this is weird. It is, as I know now, data source related. I was poking
in the layer configuration to find out why the core dump happens.
Reinstalling didn't solve the issue, btw.
So first I converted the data to shapefile with ogr2ogr (as always very
handy!) and changed the layer accordingly. And no core dump happened!
Then I tried several versions of the data and filter statements without
success.
Since this is a osm2pgsql database I swapped finally the table from
planet_osm_polygon to planet_osm_line (same table schema apart from the
geometry) - and voilà - no core dump.
So I can relate the problem to the planet_osm_polygon table - but I'm not
sure what difference actually is responsible for the crash ...
The most apparent difference is of course the geometry type: planet_osm_line
is linestring, planet_osm_polygon is geometry ...
I will investigate the attributes further tomorrow, but now I need to earn
some money. It's always the deadlines ...
Frank
Am 2013-09-05 09:47, schrieb thomas bonfort:
Frank,
This is such a simple use-case that I doubt it's a bug in the code
per-se. Can you make sure that you are using a clean build (make clean
&& make && make install) as I suspect this could be happening due to a
compilation problem (as a rule of thumb, with mapserver <6.4, always
run make clean after re-running configure)
--
thomas
On Wed, Sep 4, 2013 at 2:39 PM, Frank Broniewski <[email protected]> wrote:
Am 2013-09-04 14:33, schrieb thomas bonfort:
Frank, please supply a backtrace of the crash (`bt` in gdb once it has
halted at the segfault)
--
thomas
On Wed, Sep 4, 2013 at 2:25 PM, Frank Broniewski <[email protected]>
wrote:
Hi,
I just updated my mapserver installation to the latest version (6.2.1).
I'm
running FreeBSD 9.1 and I'm getting a segmentation fault related to
expression usage in my mapfile. I've already compiled mapserver with
debug
symbols and I loaded the core file into gdb:
gdb /usr/local/www/apache22/cgi-bin/mapserv mapserv.core
<snip>
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/lib/libsupc++.so.1...done.
Loaded symbols for /usr/lib/libsupc++.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x00000008008e2520 in yylex (lvalp=0x7fffffffd250,
p=0x7fffffffd3b0)
at
mapparser.y:649
649 mapparser.y: No such file or directory.
in mapparser.y
[New Thread 809007400 (LWP 101134/mapserv)]
So apparently there seems to be a file missing!? Looking at the source
code
(git), line 649 is a blank line, so I'm not sure what's missing
exactly.
I've got yacc, bison and flex installed. For testing purposes I'm using
the
mapserver cgi on the command line:
/usr/local/www/apache22/cgi-bin/mapserv -nh
"QUERY_STRING=map=/data/web/mapserver/cnra/cnra.map&mode=map&layer=boundaries"
The boundaries layer:
Layer
# Classitem "level"
Connection "host=10.0.0.2 dbname=osm user=user password=guessme"
Connectiontype Postgis
Data "geom FROM (SELECT osm_id, way AS geom, name, admin_level AS
level,
tags FROM planet_osm_polygon) AS foo USING UNIQUE osm_id USING
SRID=3857"
Filter "tags ?& ARRAY['boundary', 'admin_level']"
Name "boundaries"
Processing "CLOSE_CONNECTION=DEFER"
Status on
Type line
Units meters
Metadata
"ows_title" "Boundary Map"
"ows_abstract" "Boundary map - data from OpenStreetMap, ODbl
licensed"
End
Projection
"init=epsg:3857"
End
Class
Expression ("[level]" = "6")
# Expression "6"
Name "communes"
Style
Color 10 10 10
Opacity 50
Width 2
End
End
End
The classitem / simple expression (Expression "6") works with the
mapserver
cgi, but python mapscript throws an error: _mapscript.MapServerError:
msEvalExpression(): General error message. Invalid item index.
I've read the mapserver expressions documentation [1] and the note that
says
something about the working environment might be linked to more than
one
expression library. But my operating system skills are not high enough
to
turn this paragraph into something useful for me.
So any help is greatly appreciated.
Frank
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Hi Thomas,
thanks for the fast response! Here's the bt:
(gdb) bt
#0 0x00000008008e2520 in yylex (lvalp=0x7fffffffd250, p=0x7fffffffd3b0)
at
mapparser.y:649
#1 0x00000008008e0146 in yyparse (p=0x7fffffffd3b0) at mapparser.c:1500
#2 0x00000008009239b2 in msEvalExpression (layer=0x809009000,
shape=0x7fffffffd4e0,
expression=0x8090a0280, itemindex=-1) at maputil.c:478
#3 0x0000000800923f03 in msShapeGetClass (layer=0x809009000,
map=0x8090bd800,
shape=0x7fffffffd4e0, classgroup=0x0, numclasses=1) at maputil.c:581
#4 0x0000000800980ab2 in msDrawVectorLayer (map=0x8090bd800,
layer=0x809009000, image=0x8090a91c0)
at mapdraw.c:989
#5 0x00000008009800ed in msDrawLayer (map=0x8090bd800,
layer=0x809009000,
image=0x8090a91c0)
at mapdraw.c:808
#6 0x000000080097ed18 in msDrawMap (map=0x8090bd800, querymap=0) at
mapdraw.c:437
#7 0x0000000800a16e6e in msCGIDispatchImageRequest (mapserv=0x8090b2300)
at
mapservutil.c:1448
#8 0x0000000800a179c2 in msCGIDispatchRequest (mapserv=0x8090b2300) at
mapservutil.c:1690
#9 0x00000000004012c1 in main (argc=3, argv=0x7fffffffd9f0) at
mapserv.c:259
(gdb)
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
