It seems Mapserver does not treat your column as a character column, try using
the following METADATA on your source layer (so not in the temporary MAP file):
gml_geoidn_type Character
Best regards,
Bart
On Mar 3, 2010, at 8:52 AM, DeDuikertjes wrote:
Bart,
Thanks for the suggestion. I've
Hi,
I guees this is this part which run an error:
error. Failed to parse expression: NL.IMRO.0184.BA127909736-00 =
NL.IMRO.0184.EP127818521-00
Try to change :
EXPRESSION ([geoidn] = NL.IMRO.0184.EP127818521-00)
in :
EXPRESSION ([geoidn] = NL.IMRO.0184.EP127818521-00)
Regards,
Y.
Le mercredi
Hi,
I would love to, but mapserver makes these expressions from the SLD, not me.
MArco
Yves Jacolin schreef:
Hi,
I guees this is this part which run an error:
error. Failed to parse expression: NL.IMRO.0184.BA127909736-00 =
NL.IMRO.0184.EP127818521-00
Try to change :
EXPRESSION ([geoidn]
Bart,
I've tried to do so, no difference in either error file or temporary
mapfile expressions
MArco
Bart van den Eijnden schreef:
It seems Mapserver does not treat your column as a character column, try using
the following METADATA on your source layer (so not in the temporary MAP file):
Then I fear you have run into (like myself):
http://trac.osgeo.org/mapserver/ticket/3289
Assefa can confirm this. Btw the fix was only done in trunk, should it not be
done in the 5.6 branch as well?
Best regards,
Bart
On Mar 3, 2010, at 9:41 AM, DeDuikertjes wrote:
Bart,
I've tried to do
Bart,
The ticket refers to WFS OCG filter rgex tests for numeric values.
So, it seems to extend to WMS as well (need to expand the ticket ?).
Does this mean that I have te wait for this to be fixed, and then
packaged in FGS?
(mapserver compilation is something I cannot do).
Now to check that
Marco,
filter code is used by both WFS and SLD WMS.
The second = is not necessary, =, == and eq are the same for strings.
Best regards,
Bart
On Mar 3, 2010, at 10:01 AM, DeDuikertjes wrote:
Bart,
The ticket refers to WFS OCG filter rgex tests for numeric values.
So, it seems to extend to
List,
Is it known what is the latest mapserver version that does not have this
bug?
MArco
Bart van den Eijnden schreef:
Marco,
filter code is used by both WFS and SLD WMS.
The second = is not necessary, =, == and eq are the same for strings.
Best regards,
Bart
On Mar 3, 2010, at 10:01
Bart van den Eijnden wrote:
Then I fear you have run into (like myself):
http://trac.osgeo.org/mapserver/ticket/3289
Assefa can confirm this. Btw the fix was only done in trunk, should it not be
done in the 5.6 branch as well?
The fix was back ported to the 5.6 branch and should be
Ok, thank you for the confirmation.
For now I've installed 5.4.2. This one doesn't have the bug.
And thank you all for the accurate help to pinpoint the problem and to
learn me a few new tricks.
MArco
Yewondwossen Assefa schreef:
Bart van den Eijnden wrote:
Then I fear you have run into
Hi List,
Finally I managed to upgrade mapserver 5.1-dev (FWTools) to 5.6.0 (FGS).
I use it as a WMS. Everything looks fine, but I've one anoying problem:
When I do a getmap-request with an SLD I get an empty image back, while
5.1-dev gives me a proper result.
Other getmap requests work fine.
I
Hi There,
One way to debug would be to set your map file in debug, something like
this:
CONFIG MS_ERRORFILE f:/msapps/gmap-ms40/htdocs/gmap.log
DEBUG 5
and check the logs. It should show you the map file after the sld has
been applied. That might give a hint on what went wrong.
best
Hi,
And if I do the same request without the SLD:
Bart,
Thanks for the suggestion. I've opened up the temporary MAP file. A
layer definition from this file is (there are a LOT more like that):
LAYER
CONNECTION host=xxx user=x dbname=xxx
CONNECTIONTYPE POSTGIS
DATA 'tc_punt_geometry from
14 matches
Mail list logo
