{5} Assigned, Active Tickets by Owner (Full Description) (128 matches)

I have defined a namespace for my WFS server:

     wfs_namespace_prefix "stragisweb"
     wfs_namespace_uri "http://www.syncera.nl/stragisweb";

When using a propertyname like stragisweb:MYCOLUMN it does not get interpreted
by Masperver. MYCOLUMN does work though.

It seems that values entered in Filter expressions in SLD rules which use the logical operator OR are not used properly in some cases. I noticed this when combining numeric and string values. I.e. (QUALI is a text field from a shapefile)

1 - This will work:

<Filter>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>24</Literal>
</PropertyIsEqualTo>
</Filter>

2 - This will also work:

<Filter>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>24a</Literal>
</PropertyIsEqualTo>
</Filter>

3 - But this will fail:

<Filter>
 <OR>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>24</Literal>
</PropertyIsEqualTo>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>24a</Literal>
</PropertyIsEqualTo>
 </OR>
</Filter>

4 - Althought this will work:

<Filter>
 <OR>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>11x</Literal>
</PropertyIsEqualTo>
<PropertyIsEqualTo>
<PropertyName>QUALI</PropertyName>
<Literal>24a</Literal>
</PropertyIsEqualTo>
 </OR>
</Filter>

reported by Bart

just spent half of my day finding out why an SLD with external graphics did not work anymore with 5.0, something like:

<PointSymbolizer?><Geometry><PropertyName?>msGeometry</PropertyName></Geometry><Graphic><ExternalGraphic?><OnlineResource? '.

'xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="'.$this->externalgraphic.'"/><Format>GIF</Format>'. '</ExternalGraphic><Size>1.0</Size></Graphic></PointSymbolizer></Rule>

I used a PointSymbolizer? with Size 1 and this results in something like:

STYLE

ANGLE 360 COLOR 0 0 0 SIZE 1 SYMBOL "....."

END

In Mapserver 4.10 this used to draw the symbol in its native size/dimension, but in 5.0 this does not work anymore, i.e. I do not see anything in the map.

If I change Size to 17 (the size in pixels of the image used), the SLD works fine again.

Was this change intentional? Anyways, I guess this should be documented in the migration guide :-) ?

Something additional, Mapserver does not comply with the SLD spec if you omit the Size in the SLD. The SLD 1.0 spec says:

"The default size of an image format (such as GIF) is the inherent size of the image."

but Mapserver seems to use a default of 6 pixels ...

if (psSize && psSize->psChild && psSize->psChild->pszValue)

psStyle->size = atoi(psSize->psChild->pszValue);

else

psStyle->size = 6; /* defualt value */

Elements are created a s Butoon instances, but there is no name associated with the instances.

This is a general bug to follow implementation of RFC-39 (http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39/)

General steps:

• add addition of classgroup and group
• publish styles in wms
• update sld to support names styles
• update doc

pateImage function in php should also work with AGG

Frank Warmerdam wrote:
> 
> However, now that I think about this, I am concerned that if PROJ is used to
> transform the spmap data from kilometers to meters the text height (expressed
> in km) will not be properly rescaled to go along with it.  If so, I doubt
> your mapfile will work properly even yet.  I will have to talk to Daniel about
> how to handle this.  I am not sure what can be done practically.
>

Need to convert the OGR and WFS layer types to use the generic lp->layerinfo 
instead of custom handles.  Important note: be careful about WFS since it's a 
wrapper around OGR...

Steve Lime wrote:
> 
> Dan: I've taken care of this for everything but the 2 you mention. I'll
> be hidding the shpfile structs behind the layerinfo pointer too.
> 
> Steve
> 
> >>> Daniel Morissette <morissette@dmsolutions.ca> 02/17/03 16:46 PM >>>
> Steve Lime wrote:
> >
> > Dan: I'm poking around the code a bunch trying to wrap stuff up.
> Anyway,
> > one thing I noticed is the variety of layerinfo pointers in the layer
> > object, one for each connection type. For simplicity wouldn't it be
> just
> > as easy to specify a single (eg. void *layerinfo;) pointer? We already
> > do that for iteminfo.
> >
> 
> I agree that this would be a nice change, but there may be an issue with
> merging the WFS and OGR layers since the WFS layer uses an OGR
> connection, so both the wfslayerinfo and the ogrlayerinfo are used at
> the same time.  You could leave the WFS and OGR there untouched and let
> me know when your other changes are done and I'll take care of fixing
> them myself by creating a combined data structure for WFS and OGR.
>

Looking at the source code, Mapserver WMS client, always uses the inimage
type of exceptions in its WMS request:
 
        if (nVersion >= OWS_1_1_0)
            pszExceptionsParam = "application/vnd.ogc.se_inimage";
        else
            pszExceptionsParam = "INIMAGE";

But, application/vnd.ogc.se_inimage is an *optional* exception format in
the WMS spec, so I think your idea would be good of being able to override
this as a user. This is a necessary enhancement, since the default
requested exception format is an optional one, and I would suggest you to
open an enhancement bug for this in the Mapserver bugzilla. Something like
wms_exception_format/ows_exception_format METADATA.

This may also involve some more error handling in Mapserver WMS client
though, since it is not expecting XML type of exceptions for GetMap right
now. So it might not be as straightforward as it looks to implement this.

A few weeks ago I was doing some benchmarks with MapServer 4.10 on a mapfile
with about 10 layers in it and replacing the 10 "init=epsg:xxxx" defns with
native PROJ.4 definitions made the WMS GetCapabilities requests go from 3
hits/seconds to 12 hits/seconds (4 times faster!).

Since EPSG codes are used a lot by all OGC services, optimizing the EPSG lookup
(or caching them at a minimum) is something that would be very valuable for all
OGC service users.

Jean-Francois.Doyon@ccrs.nrcan.gc.ca wrote:
> 
> Yup, that is correct, right now, you can't hide a WMS layer in a given
> mapfile, from showing up in GetCapabilities ... Weren't you paying attention
> in our workshop debbie ? :)
> 
> I haven't checked, but I'd encourage you to file a feature enhancement into
> the MapServer bugzilla about this if there isn't one already ... I could use
> that feature too :)
> 
> Cheers,
> J.F.
> 
> -----Original Message-----
> From: Lowell Filak [mailto:lfilak@medinaco.org]
> Sent: Wednesday, June 11, 2003 4:17 PM
> To: Debbie Pagurek; mapserver-users@lists.gis.umn.edu
> Subject: Re: [Mapserver-users] preventing certain layers from appearing
> in thegetCapabilities doc?
> 
> If I recall a discussion from the User Meeting correctly, you will need to
> use a different Mapfile to do that.
> HTH
> Lowell F.
> 
> The following message was sent by "Debbie Pagurek" <pagurekd@agr.gc.ca> on
> Wed, 11 Jun 2003 13:49:05 -0400.
> 
> > Hi all,
> > I have a mapfile that I am using for an web mapping interface, as well as
> doubling as a WMS server.  There are layers used in the interface that I
> don't want appearing in the getCapabilities document though and I thought I
> could prevent them from appearing there by omitting the METADATA tags for
> those layers, but that is not the case.  Is there a way to select which
> layers in a mapfile should appear in a GetCapabilities document?
> >
> > Thanks,
> > Debbie
> >

I created a new shape file object within php_mapscript and got the error below. I tested with MapServer 5.2.0 beta2, beta 3 and trunk on Ubuntu. It doesn't happen with 5.0.2 release. I pasted below the script used for the test.

[02-Jul-2008 15:27:21] PHP Warning:  [MapServer Error]: msNewSHPFile(): (ttt)
 in /home/nsavard/fgs-ms5.2.0.beta3/www/htdocs/createshp.phtml on line 9
[02-Jul-2008 15:27:21] PHP Warning:  [MapServer Error]: msSHPOpen(): Corrupted .shp file : nRecords = -12.
 in /home/nsavard/fgs-ms5.2.0.beta3/www/htdocs/createshp.phtml on line 9
[02-Jul-2008 15:27:21] PHP Fatal error:  Failed to open shapefile ttt in /home/nsavard/fgs-ms5.2.0.beta3/www/htdocs/createshp.phtml on line 9

and the script is:

<html>
<body>
<?php

dl("php_mapscript.so");

$shpFname = "ttt";
$shpFile = ms_newShapeFileObj( $shpFname, MS_SHP_POINT );

?>
</body>
</html>

http://mapserver.gis.umn.edu/docs/reference/phpmapscript-class/

Join with postgis table noz work when FROM and TO items are charater type.

mappostgresql.c line 336 must change to 
        sprintf(sql, "SELECT %s FROM %s WHERE %s = '%s'", columns, join->table,
join->to, joininfo->from_value);

 thanks

This problem seems to be specific to requests to the MassGIS WMS server at:
http://maps.massgis.state.ma.us:8080/mapaccess/main.jsp

Some layers have scale dependent visibility, but if MapServer requests a layer 
at a scale at which the layer is not available it returns an error rather than 
not returning an image, or returning a blank image. The error message 
includes: "Warning: [MapServer Error]: drawEPP(): EPPL7 support is not 
available."  The complete error message can be seen by running the attached 
test script.

Here is the text from the capabilities document that refers to the layer that 
is causing the problem:

<Layer queryable="1" opaque="0" noSubsets="0">
  <Name>MA Towns Boundaries-towns_poly_axl7</Name>
  <Title>MA Towns Boundaries</Title>
  <SRS>EPSG:26986</SRS>
  <BoundingBox minx="33861.26" miny="777514.31" maxx="330846.09" 
maxy="959747.44" srsName="EPSG:26986" />
  <ScaleHint min="150000.30000060014" max="" />
</Layer>

The ScaleHint tag gives a clue to why the error occurs, but the nature of the 
error message is a mystery to me.

I will attach a mapfile and a script that reproduces the problem. (Thanks to 
Paul Spencer for writing the script)

When offering several spatial reference systems in a mapfile by e.g. using:

"wms_srs" "EPSG:31467 EPSG:31466 EPSG:31468 EPSG:31469 EPSG:25832 EPSG:4326"

bounding box tags for each spatial reference system are missing for at least the
root layer in the corresponding wms getcapabilities. 

Although this is an optional tag regarding to the wms specification, it should
be possible to generate these bounding boxes in the capabilities with mapserver.
WMS Clients sometimes use them.

As requested by Assefa I enter a bug for this issue.

Here what it says in the WMS 1.1.1 doc.

"If a request does includes an imprecise dimensional value, and nearest value
behavior has been declared, then the server shall compute and send the nearest
available value. The value shall be rounded, not merely truncated."

Right now, mapserver is using date_trunc function to allow the user to specify
months, days, hours or minutes.  I think this could be enhanced to get the
nearest time value in Postgres.  For example,  NASA GES has 3 hourly data.  If
the user  specify 2006-09-28T02:00  a blank image is return, the user needs to
be exact 2006-09-28T03:00.  Same thing with 10-day data,  2006-09-03 will 
return a  blank image.  User have to hit the right date 2006-08-10, 2006-08-20,
2006-08-31, 2006-09-10,.... 

Example
Tropical Rain data 3B42_V6_10_DAY:
http://g0hep12u.ecs.nasa.gov/mapserv-bin/wms_ogc?SERVICE=WMS&VERSION=1.1.1&REQUEST=Getmap&layers=bluemarble,TRMM_3B42_V6_10_DAY&BBOX=-180,-50,180,50&TIME=2005-08-20

blank image
http://g0hep12u.ecs.nasa.gov/mapserv-bin/wms_ogc?SERVICE=WMS&VERSION=1.1.1&REQUEST=Getmap&layers=bluemarble,TRMM_3B42_V6_10_DAY&BBOX=-180,-50,180,50&TIME=2005-08-20T04:00

Spaces in CONNECTION strings for SDE (not sure about the other DBs) cause 
problems. Solution is to trim leading a trailing blanks from parameters before 
using them.

We have noticed a problem with MapServer V4.0 when drawing raster symbols on a
map and using 8 bits PNG output.  Sometimes the color of the raster symbol will
change.

In our specific case, we were using a png symbol that contained red color.  
- If the rest of the map also contained some red elsewhere (in the roads layer
for instance) then the symbol was displayed in red correctly
- If there was no red color anywhere else in the map then the symbol was drawn
in black instead of red.

The above was happening when using 8 bits PNG output.  Switching to 24 bits PNG
or JPEG output resolves the issue.  Sounds very much like a color table issue.

Please keep in mind that this happens with raster symbols, not vector symbols.

Unfortunately we don't have a simple reproduceable test case for this.  If we
can build one then we'll attach it.

1. Noone seems to know how the query (itemquery, itemnquery) mechanics actually
work.  Some investigation and documentation are needed.

2. The query method appears to be (a) do a query-by-rectangle (with filter) to
get record#s, then (b) repeatedly request each feature by record number.  In
order for this to be efficient, it assumes a O(1) get-feature-by-record-number
access.  This isnt true for all layer types.  Also, cacheing the results of the
query-by-rectangle (with filter) isnt generally possible because the columns
(items) havent been set yet in the layer object or by a call to LayerGetItems().

3. Why is there a separate query/draw mechanism?  Why doesnt mapserv just do a
normal draw-type request (query-by-rectangle (with filter)), then use the normal
 getNextShape() functions?  Its a maintainance issue to have each layer
implement two basic functions (draw and query) when query could be seamlessly
implemented by the draw mechanism.

C.F. mailing list discussion with subject "Re: [Mapserver-dev] Re:
[Mapserver-users] Mapscript drawQuery() on big PostGIS layers doesn't work
properly ?"

Daniel requested a bug report so this doesnt go away.

We need the ability to specify a proxy when connecting to remote WMS/WFS servers.

This could possibly be added as layer metadata wms_proxy_*, but I wonder if we should instead create global configuration parameters inside the WEB object?

I never really worked in environments with proxies, so I wonder if it is safe to assume that when someone uses a proxy, then they use it for *all* their http connections and not only to get to specific hosts? i.e. is it a good idea to have a single global proxy setting in the web object in the mapfile or should this be local at the layer level?

Order in cgi parameters does matter. 
 
Bad: 
/cgi-bin/mapserv?map=/gis/mymap.map&mode=map&user=USER&map_mylayer_data=%25user%25%2Fmylayer.png 
 
Good: 
/cgi-bin/mapserv?map=/gis/mymap.map&mode=map&map_mylayer_data=%25user%25%2Fmylayer.png&user=USER 
 
The first URL fails because it can't find the data image. It is neede to pass 
"user=USER" as the last argument.

The logic for calculating a layer's scalefactor is present in the msDrawMap 
function in the file mapdraw.c but not in the msDrawLayer function. This is a 
particular problem when using the mapscript API and the 
$layerObj->draw($imageObj) functionality in conjunction with a layer's SIZEUNITS 
or SYMBOLSCALE properties. The result in such a case is that msDrawMap (and the 
scaling logic) is bypassed and symbols are not scaled. 

The problem is further described in the submitted URL.

Our solution was to move the scalefactor calculation logic:

for(i=0;i<map->numlayers; i++) {
	if(map->layers[i].sizeunits != MS_PIXELS)
        map->layers[i].scalefactor = (msInchesPerUnit(map->layers[i].sizeunits,
0)/msInchesPerUnit(map->units,0)) / map->cellsize; 
	else if(map->layers[i].symbolscale > 0 && map->scale > 0)
        map->layers[i].scalefactor = map->layers[i].symbolscale/map->scale;
	else
        map->layers[i].scalefactor = 1;
}

down to the top of the msDrawLayer function:

if(layer->sizeunits != MS_PIXELS)
	 layer->scalefactor = (msInchesPerUnit(layer->sizeunits,0)
/msInchesPerUnit(map->units,0)) / map->cellsize; 
else if(layer->symbolscale > 0 && map->scale > 0)
	 layer->scalefactor = layer->symbolscale/map->scale;
else
	 layer->scalefactor = 1;

The result is that symbols are scaled correctly if layers are drawn 
individually.  This logic, however, is now missing from the other layer drawing 
functions:

msDrawWMSLayerLow
msDrawWMSLayerSWF
msDrawWMSLayerPDF

This bug is also present in version 4.0

This layer works, but MapScript hangs when I uncomment MAXINTERVAL:

LAYER
  NAME "Grid"
  PROJECTION
    "init=epsg:28992"
  END
  METADATA
    WMS_TITLE "Graticule"
  END
  TYPE LINE
  STATUS on
  CLASS
    COLOR 128 128 128
    LABEL
      TYPE truetype
      FONT arial
      SIZE 7
      COLOR 0 0 0
      PARTIALS FALSE
    END
  END
  GRID
    LABELFORMAT "%5.0f"
    MAXARCS 10
#    MAXINTERVAL 10
    MAXSUBDIVIDE 2
  END
END

when loading a mapfile using ms_newMapFile, the following error is generated if
the extents are not in the form minx < maxx && miny < maxy

Given web extent is invalid.

I have two problems with this:

1. the error message sucks.  What is a web extent anyway?  Looking in
loadMapInternal, it is obvious ... but to an end user?
2. the behaviour has changed from 4.2, which would load this properly by
swapping the maxy for miny.

Request the error message be changed to something meaningful like:
"Extents specified (<minx> <miny> <maxx> <maxy>) are invalid because miny > maxy
or minx > maxx."

Also request that the behaviour change back to the previous one where the
extents would be automagically corrected.

I have the following layer to define a 4 kilometers cross:

LAYER
   ...
   SIZEUNITS meters
   CLASS
     SYMBOL "cross"
     SIZE 4000
     COLOR 0 0 0
   END
END

When i get the legend of this layer (mapserver?mode=legend) i get an ugly legend
because the size of symbol "+" is too big.

If i try:

LAYER
   ...
   SIZEUNITS kilometers
   CLASS
     SYMBOL "cross"
     SIZE 4
     COLOR 0 0 0
   END
END

I get very small symbols on the legend.

How can i do to get symbols the right size?

Using the WRAP command inside a mapfile to specify which symbol a text string
will wrap on truetype fonts doesn't seem to work. Using bitmap fonts seems to
work fine. Here is a sample mapfile layer:

LAYER
    NAME "Copyright"
  
    METADATA
        "wms_title" "Copyright"
        "wms_srs"   "EPSG:27700"
        "wms_extent"    "0.0 0.0 700000.0 1300000.0"
    END

    STATUS DEFAULT
    TRANSFORM FALSE
    TYPE ANNOTATION

    POSTLABELCACHE TRUE

    FEATURE
        POINTS
        2 5
        END
        TEXT '© Crown copyright/database right 2004.|An Ordnance
Survey/EDINA supplied service.'
    END

    CLASS

        STYLE
            SYMBOL "copy_box_os"
            COLOR 255 255 255
            SIZE 30
        END
        LABEL
            BACKGROUNDCOLOR 0 255 255
            COLOR 0 0 0
            #OUTLINECOLOR 255 255 255
            TYPE TRUETYPE
            FONT arial
            SIZE 7
            ANTIALIAS TRUE
            PARTIALS TRUE
            POSITION CR
            WRAP "|"

        END
    END

    MINSCALE 1000.0
    MAXSCALE 25000.0
    PROJECTION
        "init=epsg:27700"
    END
END # End copyright

In the above example, the text string displayed on the map should be:
© Crown copyright/database right 2004.
An Ordnance Survey/EDINA supplied service.

But this is displayed instead:
© Crown copyright/database right 2004.|An Ordnance Survey/EDINA supplied service.

Hallo!

It seems to me that the expression for classification of a layer is not
evaluated  for queryByRect or queryByPoint. See the following (constructed) case:
I have one shapefile with the values "A" and "B" for the attribute "type" and an
layer that shows only those of type=A (defined with CLASSITEM = type and an
EXPRESSION in the corresponding CLASS).

Querying the second layer leeds to results even containing shapes with type=B.
This holds true for PHP/mapscript but also for a query by a WMS
GetFeatureInfo-Request.

I scanned the source code of mapserver 4.6 (the version I am working with) as
well as of version 4.8-beta2. In both cases I couldn't find any place where the
evaluation of the expression is done during a query. I also had a look an the
bug-tracker an the mailinglist archives but couldn't find any hint.

Have I overseen something?

         Silke

P.S.: If necessary I can construct a test case which fails with the current
version. 

P.P.S.: 

For the case that I have overseen something, here my full example of layer
definition:
  # Landesmessnetz Menge
  LAYER
    DATA "/usr/local/httpd/gwmessnetz/data/messstellen/messstellen"
    NAME netz_menge
    METADATA
        "DESCRIPTION" "Landesmessnetz Menge"
        "RESULT_FIELDS" "invname, mkz, longname, brgort, tk25, arnum, bo_ident,
projekt, auftrag, kommentar, bohrfirma, brgzweck, bohrz_von, bohrz_bis,
bohrverf, xcoord, ycoord, xcoordo, ycoordo, zcoorde, zcoordb, invmbeg, invzbeg,
invzend, strat, mesartmvp, foto, bewertung, bohrprofil"
        "RESULT_HEADERS" "Messstellenname, Messstellenkennzahl, Bohrungsname,
Bohrungsort, TK25, Archiv-Nummer, Bohrarchiv-Ident, Projekt, Auftraggeber,
Kommentar, Bohrfirma, Bohrungszweck, Bohrzeit von, Bohrzeit bis, Bohrverfahren,
Rechtswert, Hochwert, Original-Rechtswert, Original-Hochwert, Endteufe, Höhe zu
NN (GOK), Messpunkthöhe zu NN (ROK), Filtertiefe von, Filtertiefe bis,
Stratigrafie, Messstellenart, Foto, Bewertung, Bohrprofil"
    END
    SIZEUNITS PIXELS
    STATUS OFF
    TOLERANCE 10
    TOLERANCEUNITS PIXELS
    TEMPLATE void
    TYPE POINT
    UNITS METERS
    MINSCALE 1000
    MAXSCALE 1500001
    SYMBOLSCALE 100000
    CLASSITEM mesartmvp
    CLASS
      NAME "Messstellen"
      EXPRESSION /,M/
      STYLE
        COLOR 0 0 255 # blau
        MAXSIZE 20
        MINSIZE 6
        OUTLINECOLOR 0 0 0 # schwarz
        SIZE 12
        SYMBOL "circle"
      END
    END
  END # Landesmessnetz Menge

When drawing the map label offset should behave similar to label size that is:
it should vary depending on the current scale if symbolscale is set.

Without supporting this the location of the labels relative to the other
features may vary unexpectedly.

Tamas

I have (among others) the definitions pasted below on my mapfile. I run an
application with mapscript on it, On mapserver 4.6, the layer's overlaysymbol
draws as expected, but on 4.8 only symbol is drawn.


MAP
	NAME MAPA 
	STATUS ON
	SIZE 539 378 
	EXTENT -69 -34 -33 6  
	SHAPEPATH "/var/mapdata/shape"
	IMAGECOLOR 255 255 204 # 239 255 214 
	UNITS DD
	IMAGETYPE PNG
	SYMBOLSET "/var/mapdata/simbolos.sym"
	FONTSET "/var/mapdata/fonts.list"

	QUERYMAP
		STATUS ON
		STYLE HILITE
		COLOR 255 0 0
	END

	REFERENCE
		IMAGE images/brasil_ref.png
		EXTENT -69 -34 -33 6 
		SIZE 120 100 
		STATUS ON
		COLOR -1 -1 -1 
		OUTLINECOLOR 0 0 0 
	END

	LEGEND
		KEYSIZE 20 15  
		LABEL
			FONT "arial"
			TYPE TRUETYPE 
			SIZE 10 
			COLOR 0 0 0 
		END
		INTERLACE OFF
		TRANSPARENT ON
		STATUS ON 
	END
 


	SCALEBAR
		COLOR 0 255 153
		IMAGECOLOR  250 250 250
		LABEL
			COLOR 255 64 0
			SIZE TINY
		END