Re: [mapserver-users] Re: Mapserver unnecessary slow with Spatialite
Hi,
I did have the views on my mind but I thought that if they were used ogr would
perhaps loose the spatial index of the Spatialite table. Good if views will
work. It feels like a solid solution even it means playing both with the
mapfile and on the Spatialite side when creating new layers.
-Jukka Rahkonen-
Even Rouault wrote:
>
> Le mardi 30 août 2011 11:07:57, Rahkonen Jukka a écrit :
> > Hi,
> >
> > Even Rouault made a fix yesterday into the ogr sqlite
> driver. It gave 11
> > times more speed when doing small BBOX selections from a
> smallish table
> > with 9 linestrings. These queries are very typical for
> Mapserver and
> > thus when the gdal version behind Mapserver is updated
> people should see
> > much more speedy Spatialite rendering. It was also
> interesting that with
> > the same sample data selecting from Spatialite was 3 times
> faster than
> > from PostGIS. However, there is probably still one problem.
> Even wrote:
> >
> > " However, there is no gain to expect from the above
> change for a request
> > such as : ogrinfo OSM_Finland.sqlite -sql "select geometry, osm_id
> > ,highway,ref, name, tunnel from osm_line where highway is not null"
> > -spat 389116 6677305 389579 6677661
> >
> > Indeed, when you specify -sql, the driver (and to my
> knowlegde, this is
> > true for all other OGR drivers) makes no attempt to merge
> the spatial
> > filter, so the spatial filter is evaluated on OGR side,
> which will be
> > rather slow. So, you have 2 possibilities, either use the
> "-where highway
> > is not null" on a layer so that OGR can merge the attribute
> and spatial
> > filters, or incorporate at hand the spatial filter inside
> the SQL query
> > specified with -sql. "
> >
> > It is very common and handy to define the DATA in Mapserver
> mapfile with
> > SQL like the one used in the example. If this is going to
> lead to slow
> > Mapserver-OGR-Spatialite queries also in the future, could
> it be possible
> > to add some kind of Mapserver processing option that would
> force the use
> > of Spatialite spatial index table? It might behave so that
> if user adds a
> > directive PROCESSING "USE_ SPATIALITE_SPATIAL_INDEX=YES"
> then Mapserver
> > would construct SQL by adding the AND ROWID IN stuff as
> described in the
> > GDAL ticket http://trac.osgeo.org/gdal/ticket/4212. xmax,
> xmin, ymax and
> > ymin would be captured from the WMS BBOX.
>
> I'm not sure how this could be improved in mapserver, but I'm
> thinking of an
> easier solution that will require no code change. Why not using
> sqlite/spatialite views to capture your request ? This way
> the view will be
> seen as a regular layer by OGR, and if you specify it as the
> data in the file,
> the spatial filter will be applied to it.
>
> I've just added support for spatialite views in GDAL trunk
> (r23011). Spatial
> index of the base table is used to speed up spatial queries
> on the view.
>
> On your example, to create the spatial view :
>
> ogrinfo berlin.sqlite -sql "create view
> osm_line_highway_not_null as select
> OGC_FID AS ROWID, GEOMETRY, osm_id ,highway,ref,name, tunnel
> from osm_line
> where highway is not null"
>
> ogrinfo berlin.sqlite -sql "INSERT INTO
> views_geometry_columns (view_name,
> view_geometry, view_rowid, f_table_name, f_geometry_column) VALUES
> ('osm_line_highway_not_null', 'GEOMETRY', 'ROWID',
> 'osm_line', 'GEOMETRY')"
>
> Note: you must call the primary key ROWID if you want QGIS to
> be able to
> display the view on the map. I'm not sure why this is
> necessary (the OGR
> driver works with other names), may be a limitation of the
> qgis spatialite
> driver.
>
> And then you can use osm_line_highway_not_null as a regular
> layer for
> mapserver.
>
> >
> > SELECT geometry, osm_id, highway,ref, name, tunnel
> > FROM osm_line
> > WHERE highway IS NOT NULL AND ROWID IN (
> > SELECT pkid FROM idx_osm_line_GEOMETRY
> > WHERE xmax > 1487400 AND xmin < 1487500
> > AND ymax > 6894200 AND ymin < 6894300);
> >
> >
> > If somebody is interested in having a try with Mapserver
> and Spatialite
> > there is a sample database at
> > http://188.64.1.61/tiedostot/berlin_2011_08_25.zip and corresponding
> > mapfiles at http://latuviitta.org/documents/osm_maps.zip
> Use with MS4W
> > should be as easy as unzipping the berlin.sqlite file into directory
> > \ms4w\data\ and mapfiles into directory \ms4w\osm_maps\.
> After that the
> > Berlin OpenStreetMap WMS should be ready at
> > http://localhost/cgi-bin/mapserv.exe?map=/ms4w/osm_maps/osm_wms.map
> >
> > Because the spatial index issue the service will be rather slow.
> >
> > -Jukka Rahkonen-
> >
> > > -Alkuperäinen viesti-
> > > Lähettäjä: Rahkonen Jukka
> > > Lähetetty: 28. elokuuta 2011 23:56
> > > Vastaanottaja: MapServer
> > > Aihe: Mapserver unnecessary slow with Spatialite
> > >
> > > Hi,
> > >
> > > I have been playing a bit with Mapserver 6.0 and Spatialite
> > > and
Re: [mapserver-users] Issue with run-time substitution?
I have further reduced a test map file and changed the sequence of statements
but one substitution still fails.
I have a number of other map files where substitution works as expected and the
wfilter substitution in this example also works as expected but I cannot see
what is different about the vucv case.
The URL looks like this:
http://www.agua.com.au/cgi-bin/mapserv?map=/tmp/q.map
&mapext=138.4324071+-35.2807010+138.5729945+-35.1222989
&mre=-1070114.26+-4230140.65+289096.72+-2872042.86
&wfilter=id+in+%2847%29&vucv=137_11
The minimal map file is:
# template map file for Agua Soil Database Water Mgt
#
MAP
NAME watermgt
PROJECTION
"proj=eqc"
"ellps=GRS80"
"towgs84=0,0,0"
"no_defs"
"lon_0=138.503e"
END
SIZE 600 600
FONTSET "/var/www/html2/benparts/fonts.list"
SYMBOLSET "/var/www/html2/benparts/symbols"
UNITS METERS
IMAGETYPE jpeg
OUTPUTFORMAT
NAME 'AGG_JPEG'
DRIVER AGG/JPEG
IMAGEMODE RGB
FORMATOPTION "QUALITY=100"
END
IMAGECOLOR 255 255 255
WEB
template /var/www/html2/benparts/templates/test1.html
imagepath "/var/www/html2/tmp/"
imageurl "/tmp/"
LOG "/tmp/mapserv.log"
END
LEGEND
KEYSIZE 18 12
LABEL
TYPE BITMAP
SIZE MEDIUM
COLOR 0 0 94
END
STATUS ON
END
LAYER
TYPE RASTER
NAME "bkgrnd"
STATUS ON
PROJECTION
"init=epsg:4283"
END
DATA "/var/www/html2/benparts/rasters/JB_Onka_IPOS_Ver2.jpg"
PROCESSING "DITHER=YES"
END
LAYER
CONNECTIONTYPE postgis
NAME "weather"
DATA "geom from weather_station"
CONNECTION "user=scldad dbname=benparts"
PROCESSING "CLOSE_CONNECTION=DEFER"
STATUS ON
TYPE POINT
VALIDATION
wfilter 'id in.*'
END
FILTER (%wfilter%)
PROJECTION
"init=epsg:4283"
END
LABELITEM "name"
CLASS
NAME "Weather Station"
STYLE
COLOR214 0 0
SYMBOL 'circle'
SIZE 7
END
LABEL
MINDISTANCE 150
POSITION CR
SIZE TINY
COLOR 9 9 9
STYLE
GEOMTRANSFORM 'labelpoly'
COLOR 255 255 255
END
END
END
END
LAYER
CONNECTIONTYPE postgis
NAME "battery"
VALIDATION
vucv '.*'
END
DATA "geom from wmd using unique id using SRID=4283"
CONNECTION "user=scldad dbname=benparts"
STATUS ON
TYPE POINT
FILTER (uc='%vucv%' and stype='B')
PROJECTION
"init=epsg:4283"
END
MAXSCALE 500
LABELITEM "label"
CLASSITEM "state"
CLASS
EXPRESSION "G"
STYLE
COLOR0 255 0
SYMBOL 'dot'
SIZE 7
OFFSET 17 0
END
LABEL
POSITION CR
TYPE TRUETYPE
FONT arial
SIZE 8
COLOR 0 255 0
OFFSET 20 0
FORCE TRUE
STYLE
GEOMTRANSFORM 'labelpoly'
COLOR 255 255 255
END
END
END
CLASS
EXPRESSION "A"
STYLE
COLOR255 215 0
SYMBOL 'dot'
SIZE 7
OFFSET 17 0
END
LABEL
POSITION CR
TYPE TRUETYPE
FONT arial
SIZE 8
COLOR 255 215 0
OFFSET 20 0
FORCE TRUE
STYLE
GEOMTRANSFORM 'labelpoly'
COLOR 255 255 255
END
END
END
CLASS
EXPRESSION "R"
STYLE
COLOR255 0 0
SYMBOL 'dot'
SIZE 7
OFFSET 17 0
END
LABEL
POSITION CR
TYPE TRUETYPE
FONT arial
SIZE 12
COLOR 255 0 0
OFFSET 20 0
FORCE TRUE
STYLE
GEOMTRANSFORM 'labelpoly'
COLOR 255 255 255
END
END
END
END
#
# Start of reference map
#
REFERENCE
IMAGE /var/www/html2/benparts/refmaps/sa.png
EXTENT -1070114.26 -4230140.65 289096.72 -2872042.86
SIZE 120 120
STATUS ON
MINBOXSIZE 5
MAXBOXSIZE 100
COLOR 0 255 0
OUTLINECOLOR 0 0 0
MARKERSIZE 8
MARKER 'star'
END
#
# Start of scalebar
#
SCALEBAR
IMAGECOLOR 0 0 0
LABEL
COLOR 255 255 255
SIZE TINY
END
STYLE 1
SIZE 200 2
COLOR 255 255 255
UNITS KILOMETERS
INTERVALS 2
TRANSPARENT TRUE
STATUS ON
END
END
When I run this, the Postgresql log shows:
LOG: duration: 0.127 ms execute : select
"name",encode(ST_AsBinary(ST_Force_2D("geom"),'NDR'),'hex') as geom,"id" from
weather_station where geom && GeomFromText('POLYGON((138.42349975
-35.280701,138.42349975 -35.1222
Re: [mapserver-users] wrong tileindex path make mapserver 6 crash
I know last week on the Windows benchmarking server for FOSS4G I made some mistakes with tileindex paths for rasters, with MapServer 6.1-dev and shp2img, and there was no crash (I used the -all-debug switch to get the error messages from MapServer). Maybe this is a platform-specific issue? not sure. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 11-08-30 5:11 PM, Daniel Morissette wrote: Hi Oliver, No, a crash is not normal, so we should try to fix it. I made a few tests and was unable to reproduce the issue, can you reproduce it with the CGI or with shp2img (i.e. without FastCGI)? If you could package a small testcase to reproduce the issue with the CGI or with shp2img (with mapfile, exact request to trigger the issue, etc.) and create a ticket then we'll try to have a look. Daniel On 11-08-30 06:40 AM, Oliver Christen wrote: hello Im just wondering if it was normal for mapserver 6 to crash instead of returning an error message if a tileindex path was incorrect for a raster layer ? Im using 6.0.0-1 I have a raster layer using a tileindex (ortho/ortho.*): LAYER NAME 'ortho' TYPE RASTER STATUS ON TILEINDEX "ortho/ortho" TILEITEM "LOCATION" END at first the TILEINDEX was wrong set to "ortho", so effectively pointing to the folder instead of the files, which is of course wrong, but I would have expected an error message, not a crash. all I have in my error log is: mod_fcgid: error reading data, FastCGI server closed connection Premature end of script headers: mapserv I tried to turn on the debug with: CONFIG "MS_ERRORFILE" "/tmp/ms_error.txt" DEBUG 5 CONFIG "CPL_DEBUG" "ON" but ms_error.txt is empty is there any way to be able to obtain some error message which may help knowing where the error is? would this problem be fixed in 6.0.1? thanks in advance best regards Oliver ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Re: Mapserver unnecessary slow with Spatialite
Le mardi 30 août 2011 11:07:57, Rahkonen Jukka a écrit :
> Hi,
>
> Even Rouault made a fix yesterday into the ogr sqlite driver. It gave 11
> times more speed when doing small BBOX selections from a smallish table
> with 9 linestrings. These queries are very typical for Mapserver and
> thus when the gdal version behind Mapserver is updated people should see
> much more speedy Spatialite rendering. It was also interesting that with
> the same sample data selecting from Spatialite was 3 times faster than
> from PostGIS. However, there is probably still one problem. Even wrote:
>
> " However, there is no gain to expect from the above change for a request
> such as : ogrinfo OSM_Finland.sqlite -sql "select geometry, osm_id
> ,highway,ref, name, tunnel from osm_line where highway is not null"
> -spat 389116 6677305 389579 6677661
>
> Indeed, when you specify -sql, the driver (and to my knowlegde, this is
> true for all other OGR drivers) makes no attempt to merge the spatial
> filter, so the spatial filter is evaluated on OGR side, which will be
> rather slow. So, you have 2 possibilities, either use the "-where highway
> is not null" on a layer so that OGR can merge the attribute and spatial
> filters, or incorporate at hand the spatial filter inside the SQL query
> specified with -sql. "
>
> It is very common and handy to define the DATA in Mapserver mapfile with
> SQL like the one used in the example. If this is going to lead to slow
> Mapserver-OGR-Spatialite queries also in the future, could it be possible
> to add some kind of Mapserver processing option that would force the use
> of Spatialite spatial index table? It might behave so that if user adds a
> directive PROCESSING "USE_ SPATIALITE_SPATIAL_INDEX=YES" then Mapserver
> would construct SQL by adding the AND ROWID IN stuff as described in the
> GDAL ticket http://trac.osgeo.org/gdal/ticket/4212. xmax, xmin, ymax and
> ymin would be captured from the WMS BBOX.
I'm not sure how this could be improved in mapserver, but I'm thinking of an
easier solution that will require no code change. Why not using
sqlite/spatialite views to capture your request ? This way the view will be
seen as a regular layer by OGR, and if you specify it as the data in the file,
the spatial filter will be applied to it.
I've just added support for spatialite views in GDAL trunk (r23011). Spatial
index of the base table is used to speed up spatial queries on the view.
On your example, to create the spatial view :
ogrinfo berlin.sqlite -sql "create view osm_line_highway_not_null as select
OGC_FID AS ROWID, GEOMETRY, osm_id ,highway,ref,name, tunnel from osm_line
where highway is not null"
ogrinfo berlin.sqlite -sql "INSERT INTO views_geometry_columns (view_name,
view_geometry, view_rowid, f_table_name, f_geometry_column) VALUES
('osm_line_highway_not_null', 'GEOMETRY', 'ROWID', 'osm_line', 'GEOMETRY')"
Note: you must call the primary key ROWID if you want QGIS to be able to
display the view on the map. I'm not sure why this is necessary (the OGR
driver works with other names), may be a limitation of the qgis spatialite
driver.
And then you can use osm_line_highway_not_null as a regular layer for
mapserver.
>
> SELECT geometry, osm_id, highway,ref, name, tunnel
> FROM osm_line
> WHERE highway IS NOT NULL AND ROWID IN (
> SELECT pkid FROM idx_osm_line_GEOMETRY
> WHERE xmax > 1487400 AND xmin < 1487500
> AND ymax > 6894200 AND ymin < 6894300);
>
>
> If somebody is interested in having a try with Mapserver and Spatialite
> there is a sample database at
> http://188.64.1.61/tiedostot/berlin_2011_08_25.zip and corresponding
> mapfiles at http://latuviitta.org/documents/osm_maps.zip Use with MS4W
> should be as easy as unzipping the berlin.sqlite file into directory
> \ms4w\data\ and mapfiles into directory \ms4w\osm_maps\. After that the
> Berlin OpenStreetMap WMS should be ready at
> http://localhost/cgi-bin/mapserv.exe?map=/ms4w/osm_maps/osm_wms.map
>
> Because the spatial index issue the service will be rather slow.
>
> -Jukka Rahkonen-
>
> > -Alkuperäinen viesti-
> > Lähettäjä: Rahkonen Jukka
> > Lähetetty: 28. elokuuta 2011 23:56
> > Vastaanottaja: MapServer
> > Aihe: Mapserver unnecessary slow with Spatialite
> >
> > Hi,
> >
> > I have been playing a bit with Mapserver 6.0 and Spatialite
> > and I was a bit surprised about how slow this combination is
> > with any bigger Spatialite database. I asked for an opinion
> > from Mr. Alesandro Furieri who wrote me some hints for making
> > efficient queries which are utilising spatial index.
> >
> > This query comes basically from OGR Spatialite driver page
> > http://www.gdal.org/ogr/drv_sqlite.html
> >
> > SELECT geometry, osm_id, highway, ref, name, tunnel
> > FROM osm_line
> > WHERE highway IS NOT NULL AND
> >
> > MBRIntersects(geometry,
> >
> > BuildMBR(1487400, 6894200, 1487500, 6894300))
> >
> > ORDER BY z_order;
> >
> > OGR documentation says that query is usi
Re: [mapserver-users] wrong tileindex path make mapserver 6 crash
Hi Oliver, No, a crash is not normal, so we should try to fix it. I made a few tests and was unable to reproduce the issue, can you reproduce it with the CGI or with shp2img (i.e. without FastCGI)? If you could package a small testcase to reproduce the issue with the CGI or with shp2img (with mapfile, exact request to trigger the issue, etc.) and create a ticket then we'll try to have a look. Daniel On 11-08-30 06:40 AM, Oliver Christen wrote: hello Im just wondering if it was normal for mapserver 6 to crash instead of returning an error message if a tileindex path was incorrect for a raster layer ? Im using 6.0.0-1 I have a raster layer using a tileindex (ortho/ortho.*): LAYER NAME 'ortho' TYPE RASTER STATUS ON TILEINDEX "ortho/ortho" TILEITEM "LOCATION" END at first the TILEINDEX was wrong set to "ortho", so effectively pointing to the folder instead of the files, which is of course wrong, but I would have expected an error message, not a crash. all I have in my error log is: mod_fcgid: error reading data, FastCGI server closed connection Premature end of script headers: mapserv I tried to turn on the debug with: CONFIG "MS_ERRORFILE" "/tmp/ms_error.txt" DEBUG 5 CONFIG "CPL_DEBUG" "ON" but ms_error.txt is empty is there any way to be able to obtain some error message which may help knowing where the error is? would this problem be fixed in 6.0.1? thanks in advance best regards Oliver ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Issue with run-time substitution?
One question... >From a performance perspective, I would have thought that having the fliter FILTER (stype='B' and uc='%vucv%') inside the DATA statement SQL would be faster, as only the relevant records would be returned to mapserver, & Postgres would be more efficient at doing this. Is there any advantage in using FILTER instead of an SQL WHERE clause for this? Brent Wood --- On Tue, 8/30/11, Julien Cigar wrote: From: Julien Cigar Subject: Re: [mapserver-users] Issue with run-time substitution? To: mapserver-users@lists.osgeo.org Date: Tuesday, August 30, 2011, 11:49 PM On 08/30/2011 13:43, Stephen Davies wrote: > I am running mapserver 6.0.1 with map files migrated from 5.6.3. > > One of my map files has stopped working properly and I suspect that it may be > a > bug in the 6.0.1 run-time substitution code. > > The relevant map file layer sections look like this: > > LAYER > CONNECTIONTYPE postgis > NAME "battery" > DATA "geom from wmd using unique id using SRID=4283" > CONNECTION "user=scldad dbname=benparts" > STATUS ON > TYPE POINT > VALIDATION > vucv '[0-9]*_[0-9]*' > END > FILTER (stype='B' and uc='%vucv%') > PROJECTION > "init=epsg:4283" > END > MAXSCALE 500 > LABELITEM "label" > CLASSITEM "state" > CLASS > EXPRESSION "G" > STYLE > COLOR 0 255 0 > SYMBOL 'dot' > SIZE 7 > OFFSET 17 0 > END > LABEL > POSITION CR > TYPE TRUETYPE > FONT arial > SIZE 8 > COLOR 0 255 0 > OFFSET 20 0 > FORCE TRUE > STYLE > GEOMTRANSFORM 'labelpoly' > COLOR 255 255 255 > END > END > END > . > . > END > > There are twelve layers with essentially the same definition apart from the > STYPE values. > > The invoking URL has&vucv=137_11 but the postgresql log reveals that no > substitution has occurred. The final pgsql command still has '%vucv%'. > > I suspect that having more than one FILTER with the same substitution breaks > things as all other substitutions work fine. > > (I also tried putting the substitution in the DATA entry but with no better > result.) You should use a METADATA section, something like: METADATA "vucv_validation_pattern" '[0-9]*_[0-9]*' END instead of VALIDATION > > Cheers, > Stephen > -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. -Inline Attachment Follows- ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Fwd: [mapserver-users] Re: Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030
hi thank everybody, for you help, i changed my code,, but even i can not see
layer
/*** on page php **/
var options = {
minResolution: "auto",
minExtent: new OpenLayers.Bounds(-1, -1, 1, 1),
maxResolution: "auto",
maxExtent: new
OpenLayers.Bounds("529495","602500","588410","660675"),
controls:[
new
OpenLayers.Control.LayerSwitcher({'ascending':false}),
new OpenLayers.Control.MousePosition(),
new OpenLayers.Control.PanZoom(),
new OpenLayers.Control.ScaleLine()
]
};
var map = new OpenLayers.Map('mapa', options );
var NASAwms2 = new
OpenLayers.Layer.WMS("tl_2010_12001_roads.shp",
"
http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map";,
{layers: 'tl_2010_12001_roads.shp',
format: 'image/png', projection:new
OpenLayers.Projection("EPSG:23030")},{isBaseLayer: true});
map.addLayer(NASAwms2);
var overview = new OpenLayers.Control.OverviewMap({
mapOptions: {
projection: new OpenLayers.Projection("EPSG:23030"),
units: "m",
maxExtent: new
OpenLayers.Bounds("529495","602500","588410","660675"),
maxResolution: 20,
numZoomLevels: 5
}
});
map.addControl(overview);
map.zoomToMaxExtent();
//
MAP
NAME map_generated_by_gvsig
SIZE 600 400
EXTENT 529495 602500 588410 660675
SYMBOLSET "dmwms1.sym"
FONTSET "fonts.txt"
LEGEND
IMAGECOLOR -1 -1 -1
LABEL
FONT "vera"
ANGLE FOLLOW
COLOR 0 0 0
ENCODING "UTF-8"
TYPE truetype
SIZE 8
END
STATUS ON
TRANSPARENT ON
END
WEB
METADATA
"wms_encoding" "UTF-8"
"wms_title" "Mapserver WMS"
"wms_abstract" ""
"wms_srs" "epsg:4326 EPSG:23030"
"wms_onlineresource" "
http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map
"
END
END
PROJECTION
"init=epsg:23030"
END
LAYER
NAME "tl_2010_12001_roads.shp"
STATUS ON
TYPE LINE
UNITS METERS
DATA
"/var/www/gisParcelsFL/tl_2010_12001_roads/tl_2010_12001_roads.shp"
MAXSCALE -1.0
MINSCALE -1.0
TRANSPARENCY 100
SIZEUNITS pixels
LABELITEM "FULLNAME"
#PROJECTION
# "init=epsg:23030"
#END
CLASS
STYLE
COLOR 153 153 153
WIDTH 1
END
NAME "default"
LABEL
FONT "vera"
ANGLE FOLLOW
COLOR 0 0 0
TYPE truetype
SIZE 7.0
END
END
METADATA
"wms_title" "tl_2010_12001_roads.shp"
"wms_abstract" "generated by gvSIG"
"wms_extent" "529495 602500 588410 660675"
"gml_include_items" "all"
END
END # Layer
END # Map File
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Re: Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030
On Aug 30, 2011, at 11:21 AM, Amalia Carolina Canavire wrote: > hi ,I don't good speak english, but i don't understand you, when you say > "Projection must be in meters which seem to be the unit for the EPSG:23030 > units", you can specify in where may correction in this code, please. thank > for you time and helping. Your declared projection "EPSG:23030" uses meters, but your extent `EXTENT -82.658149 29.4353788 -82.05008 29.943614` is definitely not in meters (unless, you are plotting a very tiny and strange area of the world that is only a few centimeters wide and long). Make sure your extent and projection units match. > > 2011/8/30 Rahkonen Jukka > >> Hi, >> >> I do not understand Spanish but it looks like you have something wrong with >> projections. >> >> MAP >> EXTENT -82.658149 29.4353788 -82.05008 29.943614 >> PROJECTION >> "init=epsg:23030" >> END >> >> Projection must be in meters which seem to be the unit for the EPSG:23030 >> units >> >> http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::23030&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title= >> >> The same with "wms_extent" "-82.658149 29.4353788 -82.05008 >> 29.943614" >> use extents in the EPSG:23030 system and units. >> >> -Jukka Rahkonen- >> >> >> >> Lähettäjä: mapserver-users-boun...@lists.osgeo.org [ >> mapserver-users-boun...@lists.osgeo.org] käyttäjän Amalia Carolina >> Canavire [acarolin...@gmail.com] puolesta >> Lähetetty: 30. elokuuta 2011 16:55 >> Vastaanottaja: Lista de Usuarios de gvSIG; mapserver-users@lists.osgeo.org >> Aihe: [mapserver-users] msWMSLoadGetMapParams(): WMS server error. Invalid >> SRS given: SRS must be valid for all requested layers. EPSG 23030 >> >> Hola gente, una duda usando gvsig para poder generar una vista desde un >> .shp debo seleccionar una proyección epsg 23030, porque no me reconece epsg >> 4326 (con esta opción mi vista es vacia , a que se debe? >> Estoy usando gvsig 1.1 por la extensión de publicación, sobre ubuntu. >> Debido a ello , por las dudas, respeto esta proyección epsg 23030, cuando >> utilizo vista desde wms, me muestra sin problema, ahora cuando lo hago para >> web, me sale el error de : >> msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be >> valid for all requested layers . >> >> Si cambio la proyeccion a 4326, no sale el error pero no me muestra nada. >> Mi codigo es el sgte: >> >> >> >> MAP >> NAME map_generated_by_gvsig >> SIZE 600 400 >> EXTENT -82.658149 29.4353788 -82.05008 29.943614 >> SYMBOLSET "dmwms1.sym" >> FONTSET "fonts.txt" >> LEGEND >> IMAGECOLOR -1 -1 -1 >> LABEL >>FONT "vera" >>ANGLE FOLLOW >>COLOR 0 0 0 >>ENCODING "UTF-8" >>TYPE truetype >>SIZE 8 >> END >> STATUS ON >> TRANSPARENT ON >> END >> WEB >> METADATA >>"wms_encoding" "UTF-8" >>"wms_title" "Mapserver WMS" >>"wms_abstract" "" >>"wms_srs" " EPSG:23030" >>"wms_onlineresource" " >> http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map >> " >> END >> END >> PROJECTION >> "init=epsg:23030" >> END >> LAYER >> NAME "tl_2010_12001_roads.shp" >> STATUS ON >> TYPE LINE >> DATA >> "/var/www/gisParcelsFL/tl_2010_12001_roads/tl_2010_12001_roads.shp" >> MAXSCALE -1.0 >> MINSCALE -1.0 >> TRANSPARENCY 100 >> SIZEUNITS pixels >> LABELITEM "FULLNAME" >> PROJECTION >>"init=epsg:23030" >> END >> CLASS >>STYLE >> COLOR 153 153 153 >> WIDTH 1 >>END >>NAME "default" >>LABEL >> FONT "vera" >> ANGLE FOLLOW >> COLOR 0 0 0 >> TYPE truetype >> SIZE 7.0 >>END >> END >> METADATA >>"wms_title" "tl_2010_12001_roads.shp" >>"wms_abstract" "generated by gvSIG" >>"wms_extent" "-82.658149 29.4353788 -82.05008 >> 29.943614" >>"gml_include_items" "all" >> END >> END # Layer >> END # Map File >> >> -- >> >> ** :) sonrei que te queda lindo :):):):): amy cgc >> ** >> >> > > > -- > > *** * :) *sonrei que te queda lindo :):):):): **amy **cgc > ** > * > ___ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Re: Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030
hi ,I don't good speak english, but i don't understand you, when you say "Projection must be in meters which seem to be the unit for the EPSG:23030 units", you can specify in where may correction in this code, please. thank for you time and helping. 2011/8/30 Rahkonen Jukka > Hi, > > I do not understand Spanish but it looks like you have something wrong with > projections. > > MAP > EXTENT -82.658149 29.4353788 -82.05008 29.943614 > PROJECTION > "init=epsg:23030" > END > > Projection must be in meters which seem to be the unit for the EPSG:23030 > units > > http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::23030&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title= > > The same with "wms_extent" "-82.658149 29.4353788 -82.05008 > 29.943614" > use extents in the EPSG:23030 system and units. > > -Jukka Rahkonen- > > > > Lähettäjä: mapserver-users-boun...@lists.osgeo.org [ > mapserver-users-boun...@lists.osgeo.org] käyttäjän Amalia Carolina > Canavire [acarolin...@gmail.com] puolesta > Lähetetty: 30. elokuuta 2011 16:55 > Vastaanottaja: Lista de Usuarios de gvSIG; mapserver-users@lists.osgeo.org > Aihe: [mapserver-users] msWMSLoadGetMapParams(): WMS server error. Invalid > SRS given: SRS must be valid for all requested layers. EPSG 23030 > > Hola gente, una duda usando gvsig para poder generar una vista desde un > .shp debo seleccionar una proyección epsg 23030, porque no me reconece epsg > 4326 (con esta opción mi vista es vacia , a que se debe? > Estoy usando gvsig 1.1 por la extensión de publicación, sobre ubuntu. > Debido a ello , por las dudas, respeto esta proyección epsg 23030, cuando > utilizo vista desde wms, me muestra sin problema, ahora cuando lo hago para > web, me sale el error de : > msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be > valid for all requested layers . > > Si cambio la proyeccion a 4326, no sale el error pero no me muestra nada. > Mi codigo es el sgte: > > > > MAP > NAME map_generated_by_gvsig > SIZE 600 400 > EXTENT -82.658149 29.4353788 -82.05008 29.943614 > SYMBOLSET "dmwms1.sym" > FONTSET "fonts.txt" > LEGEND > IMAGECOLOR -1 -1 -1 > LABEL > FONT "vera" > ANGLE FOLLOW > COLOR 0 0 0 > ENCODING "UTF-8" > TYPE truetype > SIZE 8 > END > STATUS ON > TRANSPARENT ON > END > WEB > METADATA > "wms_encoding" "UTF-8" > "wms_title" "Mapserver WMS" > "wms_abstract" "" > "wms_srs" " EPSG:23030" > "wms_onlineresource" " > http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map > " > END > END > PROJECTION > "init=epsg:23030" > END > LAYER > NAME "tl_2010_12001_roads.shp" > STATUS ON > TYPE LINE > DATA > "/var/www/gisParcelsFL/tl_2010_12001_roads/tl_2010_12001_roads.shp" > MAXSCALE -1.0 > MINSCALE -1.0 > TRANSPARENCY 100 > SIZEUNITS pixels > LABELITEM "FULLNAME" > PROJECTION > "init=epsg:23030" > END > CLASS > STYLE >COLOR 153 153 153 >WIDTH 1 > END > NAME "default" > LABEL >FONT "vera" >ANGLE FOLLOW >COLOR 0 0 0 >TYPE truetype >SIZE 7.0 > END > END > METADATA > "wms_title" "tl_2010_12001_roads.shp" > "wms_abstract" "generated by gvSIG" > "wms_extent" "-82.658149 29.4353788 -82.05008 > 29.943614" > "gml_include_items" "all" > END > END # Layer > END # Map File > > -- > > ** :) sonrei que te queda lindo :):):):): amy cgc > ** > > -- *** * :) *sonrei que te queda lindo :):):):): **amy **cgc ** * ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] SLD ignored with mode=map .. ?
Yes, that's the expected behavior: SLDs are supported only in WMS requests. On 11-08-29 07:39 AM, Julien Cigar wrote: Hello, everything is in the title :) : I wondered if it's normal that my SLD is ignored when mode=map (it works perfectly with WMS)? I use an URL like: http://home.bebif.be/mapserver?map=/path/to/mapfile.map&layer=metzger&mode=map&SLD=http://some.host.be/nobanis/mysld.xml Thank you, Julien ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Daniel Morissette http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] RE: Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030
Hi, I do not understand Spanish but it looks like you have something wrong with projections. MAP EXTENT -82.658149 29.4353788 -82.05008 29.943614 PROJECTION "init=epsg:23030" END Projection must be in meters which seem to be the unit for the EPSG:23030 units http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::23030&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title= The same with "wms_extent" "-82.658149 29.4353788 -82.05008 29.943614" use extents in the EPSG:23030 system and units. -Jukka Rahkonen- Lähettäjä: mapserver-users-boun...@lists.osgeo.org [mapserver-users-boun...@lists.osgeo.org] käyttäjän Amalia Carolina Canavire [acarolin...@gmail.com] puolesta Lähetetty: 30. elokuuta 2011 16:55 Vastaanottaja: Lista de Usuarios de gvSIG; mapserver-users@lists.osgeo.org Aihe: [mapserver-users] msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030 Hola gente, una duda usando gvsig para poder generar una vista desde un .shp debo seleccionar una proyección epsg 23030, porque no me reconece epsg 4326 (con esta opción mi vista es vacia , a que se debe? Estoy usando gvsig 1.1 por la extensión de publicación, sobre ubuntu. Debido a ello , por las dudas, respeto esta proyección epsg 23030, cuando utilizo vista desde wms, me muestra sin problema, ahora cuando lo hago para web, me sale el error de : msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be valid for all requested layers . Si cambio la proyeccion a 4326, no sale el error pero no me muestra nada. Mi codigo es el sgte: MAP NAME map_generated_by_gvsig SIZE 600 400 EXTENT -82.658149 29.4353788 -82.05008 29.943614 SYMBOLSET "dmwms1.sym" FONTSET "fonts.txt" LEGEND IMAGECOLOR -1 -1 -1 LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 ENCODING "UTF-8" TYPE truetype SIZE 8 END STATUS ON TRANSPARENT ON END WEB METADATA "wms_encoding" "UTF-8" "wms_title" "Mapserver WMS" "wms_abstract" "" "wms_srs" " EPSG:23030" "wms_onlineresource" "http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map"; END END PROJECTION "init=epsg:23030" END LAYER NAME "tl_2010_12001_roads.shp" STATUS ON TYPE LINE DATA "/var/www/gisParcelsFL/tl_2010_12001_roads/tl_2010_12001_roads.shp" MAXSCALE -1.0 MINSCALE -1.0 TRANSPARENCY 100 SIZEUNITS pixels LABELITEM "FULLNAME" PROJECTION "init=epsg:23030" END CLASS STYLE COLOR 153 153 153 WIDTH 1 END NAME "default" LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 TYPE truetype SIZE 7.0 END END METADATA "wms_title" "tl_2010_12001_roads.shp" "wms_abstract" "generated by gvSIG" "wms_extent" "-82.658149 29.4353788 -82.05008 29.943614" "gml_include_items" "all" END END # Layer END # Map File -- ** :) sonrei que te queda lindo :):):):): amy cgc ** ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] zoom out factor as int
On Aug 30, 2011, at 9:16 AM, Carlos Ruiz wrote: > Puneet, > > You have to handle negative integers. For example, to zoom in x2 you have to > use +2, to zoom out you have to use -2. Indeed I do... wouldn't have thought this up without your help. Many thanks Carlos. > > Cheers from México > > > IC Carlos Ruiz > > > > - Original Message - > From: Mr. Puneet Kishor > To: MapServer > Cc: > Sent: Monday, August 29, 2011 9:49 PM > Subject: [mapserver-users] zoom out factor as int > > how do I express a zoom out factor in > > zoomPoint( int zoomfactor, pointObj imgpoint, int width, int height, rectObj > extent, rectObj maxextent ) : int > > > Obviously, 0.5 won't work as an int is expected. > > > -- > Puneet Kishor ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] zoom out factor as int
Puneet, You have to handle negative integers. For example, to zoom in x2 you have to use +2, to zoom out you have to use -2. Cheers from México IC Carlos Ruiz - Original Message - From: Mr. Puneet Kishor To: MapServer Cc: Sent: Monday, August 29, 2011 9:49 PM Subject: [mapserver-users] zoom out factor as int how do I express a zoom out factor in zoomPoint( int zoomfactor, pointObj imgpoint, int width, int height, rectObj extent, rectObj maxextent ) : int Obviously, 0.5 won't work as an int is expected. -- Puneet Kishor ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be valid for all requested layers. EPSG 23030
Hola gente, una duda usando gvsig para poder generar una vista desde un .shp debo seleccionar una proyección epsg 23030, porque no me reconece epsg 4326 (con esta opción mi vista es vacia , a que se debe? Estoy usando gvsig 1.1 por la extensión de publicación, sobre ubuntu. Debido a ello , por las dudas, respeto esta proyección epsg 23030, cuando utilizo vista desde wms, me muestra sin problema, ahora cuando lo hago para web, me sale el error de : msWMSLoadGetMapParams(): WMS server error. Invalid SRS given: SRS must be valid for all requested layers . Si cambio la proyeccion a 4326, no sale el error pero no me muestra nada. Mi codigo es el sgte: MAP NAME map_generated_by_gvsig SIZE 600 400 EXTENT -82.658149 29.4353788 -82.05008 29.943614 SYMBOLSET "dmwms1.sym" FONTSET "fonts.txt" LEGEND IMAGECOLOR -1 -1 -1 LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 ENCODING "UTF-8" TYPE truetype SIZE 8 END STATUS ON TRANSPARENT ON END WEB METADATA "wms_encoding" "UTF-8" "wms_title" "Mapserver WMS" "wms_abstract" "" "wms_srs" " EPSG:23030" "wms_onlineresource" " http://localhost/cgi-bin/mapserv?map=%2Fvar%2Fwww%2FgisParcelsFL%2Fmap%2Fdmwms1.map " END END PROJECTION "init=epsg:23030" END LAYER NAME "tl_2010_12001_roads.shp" STATUS ON TYPE LINE DATA "/var/www/gisParcelsFL/tl_2010_12001_roads/tl_2010_12001_roads.shp" MAXSCALE -1.0 MINSCALE -1.0 TRANSPARENCY 100 SIZEUNITS pixels LABELITEM "FULLNAME" PROJECTION "init=epsg:23030" END CLASS STYLE COLOR 153 153 153 WIDTH 1 END NAME "default" LABEL FONT "vera" ANGLE FOLLOW COLOR 0 0 0 TYPE truetype SIZE 7.0 END END METADATA "wms_title" "tl_2010_12001_roads.shp" "wms_abstract" "generated by gvSIG" "wms_extent" "-82.658149 29.4353788 -82.05008 29.943614" "gml_include_items" "all" END END # Layer END # Map File -- *** * :) *sonrei que te queda lindo :):):):): **amy **cgc ** * ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] wrong tileindex path make mapserver 6 crash
Hello, When I need info like that during testing of tileindexes, I always use the shp2img commandline utility (http://www.mapserver.org/utilities/shp2img.html) with the "-all_debug" switch (see examples on that page). Hope that helps. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 11-08-30 7:40 AM, Oliver Christen wrote: hello Im just wondering if it was normal for mapserver 6 to crash instead of returning an error message if a tileindex path was incorrect for a raster layer ? Im using 6.0.0-1 I have a raster layer using a tileindex (ortho/ortho.*): LAYER NAME 'ortho' TYPE RASTER STATUS ON TILEINDEX "ortho/ortho" TILEITEM "LOCATION" END at first the TILEINDEX was wrong set to "ortho", so effectively pointing to the folder instead of the files, which is of course wrong, but I would have expected an error message, not a crash. all I have in my error log is: mod_fcgid: error reading data, FastCGI server closed connection Premature end of script headers: mapserv I tried to turn on the debug with: CONFIG "MS_ERRORFILE" "/tmp/ms_error.txt" DEBUG 5 CONFIG "CPL_DEBUG" "ON" but ms_error.txt is empty is there any way to be able to obtain some error message which may help knowing where the error is? would this problem be fixed in 6.0.1? thanks in advance best regards Oliver ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
RE [Polluriel potentiel] Re: [mapserver-users] Issue with run-time substitution?
VALIDATION should work I use it in several mapfiles with MS6. Perhaps move the VALIDATION block before DATA, just between LAYER and CONNECTIONTYPE Julien Cigar @lists.osgeo.org Envoyé par : mapserver-users-boun...@lists.osgeo.org 2011-08-30 07:49 A mapserver-users@lists.osgeo.org cc Objet [Polluriel potentiel] Re: [mapserver-users] Issue with run-time substitution? On 08/30/2011 13:43, Stephen Davies wrote: > I am running mapserver 6.0.1 with map files migrated from 5.6.3. > > One of my map files has stopped working properly and I suspect that it may be a > bug in the 6.0.1 run-time substitution code. > > The relevant map file layer sections look like this: > > LAYER >CONNECTIONTYPE postgis >NAME "battery" >DATA "geom from wmd using unique id using SRID=4283" >CONNECTION "user=scldad dbname=benparts" >STATUS ON >TYPE POINT >VALIDATION > vucv '[0-9]*_[0-9]*' >END >FILTER (stype='B' and uc='%vucv%') >PROJECTION > "init=epsg:4283" >END >MAXSCALE 500 >LABELITEM "label" >CLASSITEM "state" >CLASS > EXPRESSION "G" > STYLE >COLOR0 255 0 >SYMBOL 'dot' >SIZE 7 >OFFSET 17 0 > END > LABEL >POSITION CR >TYPE TRUETYPE >FONT arial >SIZE 8 >COLOR 0 255 0 >OFFSET 20 0 >FORCE TRUE >STYLE > GEOMTRANSFORM 'labelpoly' > COLOR 255 255 255 >END > END >END > . > . > END > > There are twelve layers with essentially the same definition apart from the > STYPE values. > > The invoking URL has&vucv=137_11 but the postgresql log reveals that no > substitution has occurred. The final pgsql command still has '%vucv%'. > > I suspect that having more than one FILTER with the same substitution breaks > things as all other substitutions work fine. > > (I also tried putting the substitution in the DATA entry but with no better > result.) You should use a METADATA section, something like: METADATA "vucv_validation_pattern" '[0-9]*_[0-9]*' END instead of VALIDATION > > Cheers, > Stephen > -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users <> ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Issue with run-time substitution?
On 08/30/2011 13:43, Stephen Davies wrote: I am running mapserver 6.0.1 with map files migrated from 5.6.3. One of my map files has stopped working properly and I suspect that it may be a bug in the 6.0.1 run-time substitution code. The relevant map file layer sections look like this: LAYER CONNECTIONTYPE postgis NAME "battery" DATA "geom from wmd using unique id using SRID=4283" CONNECTION "user=scldad dbname=benparts" STATUS ON TYPE POINT VALIDATION vucv '[0-9]*_[0-9]*' END FILTER (stype='B' and uc='%vucv%') PROJECTION "init=epsg:4283" END MAXSCALE 500 LABELITEM "label" CLASSITEM "state" CLASS EXPRESSION "G" STYLE COLOR0 255 0 SYMBOL 'dot' SIZE 7 OFFSET 17 0 END LABEL POSITION CR TYPE TRUETYPE FONT arial SIZE 8 COLOR 0 255 0 OFFSET 20 0 FORCE TRUE STYLE GEOMTRANSFORM 'labelpoly' COLOR 255 255 255 END END END . . END There are twelve layers with essentially the same definition apart from the STYPE values. The invoking URL has&vucv=137_11 but the postgresql log reveals that no substitution has occurred. The final pgsql command still has '%vucv%'. I suspect that having more than one FILTER with the same substitution breaks things as all other substitutions work fine. (I also tried putting the substitution in the DATA entry but with no better result.) You should use a METADATA section, something like: METADATA "vucv_validation_pattern" '[0-9]*_[0-9]*' END instead of VALIDATION Cheers, Stephen -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. <>___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Issue with run-time substitution?
I am running mapserver 6.0.1 with map files migrated from 5.6.3. One of my map files has stopped working properly and I suspect that it may be a bug in the 6.0.1 run-time substitution code. The relevant map file layer sections look like this: LAYER CONNECTIONTYPE postgis NAME "battery" DATA "geom from wmd using unique id using SRID=4283" CONNECTION "user=scldad dbname=benparts" STATUS ON TYPE POINT VALIDATION vucv '[0-9]*_[0-9]*' END FILTER (stype='B' and uc='%vucv%') PROJECTION "init=epsg:4283" END MAXSCALE 500 LABELITEM "label" CLASSITEM "state" CLASS EXPRESSION "G" STYLE COLOR0 255 0 SYMBOL 'dot' SIZE 7 OFFSET 17 0 END LABEL POSITION CR TYPE TRUETYPE FONT arial SIZE 8 COLOR 0 255 0 OFFSET 20 0 FORCE TRUE STYLE GEOMTRANSFORM 'labelpoly' COLOR 255 255 255 END END END . . END There are twelve layers with essentially the same definition apart from the STYPE values. The invoking URL has &vucv=137_11 but the postgresql log reveals that no substitution has occurred. The final pgsql command still has '%vucv%'. I suspect that having more than one FILTER with the same substitution breaks things as all other substitutions work fine. (I also tried putting the substitution in the DATA entry but with no better result.) Cheers, Stephen -- = Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia.Fax : 08-8177 0133 Records & Collections Management. Mobile:040 304 0583 ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] wrong tileindex path make mapserver 6 crash
hello Im just wondering if it was normal for mapserver 6 to crash instead of returning an error message if a tileindex path was incorrect for a raster layer ? Im using 6.0.0-1 I have a raster layer using a tileindex (ortho/ortho.*): LAYER NAME 'ortho' TYPE RASTER STATUS ON TILEINDEX "ortho/ortho" TILEITEM "LOCATION" END at first the TILEINDEX was wrong set to "ortho", so effectively pointing to the folder instead of the files, which is of course wrong, but I would have expected an error message, not a crash. all I have in my error log is: mod_fcgid: error reading data, FastCGI server closed connection Premature end of script headers: mapserv I tried to turn on the debug with: CONFIG "MS_ERRORFILE" "/tmp/ms_error.txt" DEBUG 5 CONFIG "CPL_DEBUG" "ON" but ms_error.txt is empty is there any way to be able to obtain some error message which may help knowing where the error is? would this problem be fixed in 6.0.1? thanks in advance best regards Oliver ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Re: Mapserver unnecessary slow with Spatialite
Hi, Even Rouault made a fix yesterday into the ogr sqlite driver. It gave 11 times more speed when doing small BBOX selections from a smallish table with 9 linestrings. These queries are very typical for Mapserver and thus when the gdal version behind Mapserver is updated people should see much more speedy Spatialite rendering. It was also interesting that with the same sample data selecting from Spatialite was 3 times faster than from PostGIS. However, there is probably still one problem. Even wrote: " However, there is no gain to expect from the above change for a request such as : ogrinfo OSM_Finland.sqlite -sql "select geometry, osm_id ,highway,ref, name, tunnel from osm_line where highway is not null" -spat 389116 6677305 389579 6677661 Indeed, when you specify -sql, the driver (and to my knowlegde, this is true for all other OGR drivers) makes no attempt to merge the spatial filter, so the spatial filter is evaluated on OGR side, which will be rather slow. So, you have 2 possibilities, either use the "-where highway is not null" on a layer so that OGR can merge the attribute and spatial filters, or incorporate at hand the spatial filter inside the SQL query specified with -sql. " It is very common and handy to define the DATA in Mapserver mapfile with SQL like the one used in the example. If this is going to lead to slow Mapserver-OGR-Spatialite queries also in the future, could it be possible to add some kind of Mapserver processing option that would force the use of Spatialite spatial index table? It might behave so that if user adds a directive PROCESSING "USE_ SPATIALITE_SPATIAL_INDEX=YES" then Mapserver would construct SQL by adding the AND ROWID IN stuff as described in the GDAL ticket http://trac.osgeo.org/gdal/ticket/4212. xmax, xmin, ymax and ymin would be captured from the WMS BBOX. SELECT geometry, osm_id, highway,ref, name, tunnel FROM osm_line WHERE highway IS NOT NULL AND ROWID IN ( SELECT pkid FROM idx_osm_line_GEOMETRY WHERE xmax > 1487400 AND xmin < 1487500 AND ymax > 6894200 AND ymin < 6894300); If somebody is interested in having a try with Mapserver and Spatialite there is a sample database at http://188.64.1.61/tiedostot/berlin_2011_08_25.zip and corresponding mapfiles at http://latuviitta.org/documents/osm_maps.zip Use with MS4W should be as easy as unzipping the berlin.sqlite file into directory \ms4w\data\ and mapfiles into directory \ms4w\osm_maps\. After that the Berlin OpenStreetMap WMS should be ready at http://localhost/cgi-bin/mapserv.exe?map=/ms4w/osm_maps/osm_wms.map Because the spatial index issue the service will be rather slow. -Jukka Rahkonen- > -Alkuperäinen viesti- > Lähettäjä: Rahkonen Jukka > Lähetetty: 28. elokuuta 2011 23:56 > Vastaanottaja: MapServer > Aihe: Mapserver unnecessary slow with Spatialite > > Hi, > > I have been playing a bit with Mapserver 6.0 and Spatialite > and I was a bit surprised about how slow this combination is > with any bigger Spatialite database. I asked for an opinion > from Mr. Alesandro Furieri who wrote me some hints for making > efficient queries which are utilising spatial index. > > This query comes basically from OGR Spatialite driver page > http://www.gdal.org/ogr/drv_sqlite.html > > SELECT geometry, osm_id, highway, ref, name, tunnel > FROM osm_line > WHERE highway IS NOT NULL AND > MBRIntersects(geometry, > BuildMBR(1487400, 6894200, 1487500, 6894300)) > ORDER BY z_order; > > OGR documentation says that query is using spatial index. > However, Alesandro writes that it does not and suggests > another SQL which is 20 times faster. > > Alesandro wrote: > " Berlin dataset, your original SQL: I've simply adjusted > the MBR coords. > Execution time: 397 millis > Please note: this layer contains very few rows (< 100k): > so not using the Spatial Index imposes a very bland (but > still noticeable) overhead. > > = > > SELECT geometry, osm_id, highway,ref, name, tunnel > FROM osm_line > WHERE highway IS NOT NULL AND ROWID IN ( > SELECT pkid FROM idx_osm_line_GEOMETRY > WHERE xmax > 1487400 AND xmin < 1487500 > AND ymax > 6894200 AND ymin < 6894300) > ORDER BY z_order; > > Same query: this time using the Spatial Index. > Execution time: 17 millis ... really a lot better :-D > and if applied to some larger dataset (> 1 million rows) > the difference will become absolutely dramatic, as you > are already experiencing in the Finland test case. > > SpatiaLite isn't PostGIS: you *must* explicitly write > your SQL Queries in such a way to access the corresponding > Spatial Index table as appropriate. > > Please note well: in SQLite/SpatiaLite the R*Tree > Spatial Index simply is another table between many > others. > The SQL engine has absolutely no idea that a strict > correlation exists between the "geometry" table and > the corresponding R*Tree. > So you are explicitly required to define an explicit > sub-query in order to inq
Re: [mapserver-users] Re: Dashed outline for polygon (migration to 6.0)
Interesting. I am sure that a bug report would be appreciated. Do you think you could create an example that demonstrates the problem? Håvard On 8/29/2011 5:03 PM, Mark Deneen wrote: We had an issue where, depending on your projection, the dashed lines would only show up further north. As they got closer to the equator, they looked more solid. -M On Mon, Aug 29, 2011 at 10:22 AM, Havard Tveite wrote: It works for me for 6.0.0, 6.0.1 and SVN trunk with AGG. I have also tried to include you OUTPUTFORMAT specification, and that works. It also works with GD. I have been testing with shp2img. Håvard Here is a complete layer with an inline feature. LAYER STATUS DEFAULT TYPE POLYGON FEATURE POINTS 5 5 5 25 45 25 45 5 5 5 END # Points END # Feature CLASS STYLE OUTLINECOLOR 0 0 0 WIDTH 6 PATTERN 20 20 END LINECAP BUTT END # STYLE END # CLASS END # LAYER On 8/29/2011 2:59 PM, Petra Pietrasová wrote: Thank you , but even your example doesn´t work. Are you using the version of mapserver 6.0.1 and does dashed line work in it? if it works to you than the problem is not in the layer in the style of layer. Do you have any idea what we do wrong? Some setup of mapserver or output? We are using AGG output as I wrote before... -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Dashed-outline-for-polygon-migration-to-6-0-tp6728657p6737544.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Håvard Tveite Department of Mathematical Sciences and Technology, UMB Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Håvard Tveite Department of Mathematical Sciences and Technology, UMB Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
