[mapserver-users] Re: Cannot get a PostGIS layer to render in Mapserver...

[BrainDrain]

I think you didn't not install postgis extensions correctly (You need for ex.
function force_ 
2d(geography)). Or your postgis version is lower than 1.3.5 (PostGIS adds
support for geographic objects).
-- 
View this message in context: 
http://n2.nabble.com/Cannot-get-a-PostGIS-layer-to-render-in-Mapserver-tp4776199p4776602.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

[mapserver-users] mapserver not generating proper map

[sunny74]

Hi,

I am generating a simple map but mapserver is not generating a proper map.
In fact initially it produced a proper one but after that due to code
changes or some other reason started producing this one.
My code to call mapserver is:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>


  
  
  var mapview, layer, layer1, map;

 function init() {

 //alert("in init");
 map = new OpenLayers.Map('<%=map.ClientID%>');

 //
 layer = new OpenLayers.Layer.WMS("OpenLayers WMS",
"http://172.16.0.144:9000/cgi-bin/mapserv.exe?";, { map:
'Shape/newwr1.map', layers: 'STATE', 'format': 'png' });

 //layer1 = new OpenLayers.Layer.WMS("RLine",
"http://172.16.0.144:9000/cgi-bin/mapserv.exe?";, { map: 'Shape/newwr1.map',
transparent: 'true', layers: 'RailwayStations', 'format': 'png' });

 highlightLayer = new OpenLayers.Layer.Vector("Highlighted
Features", {
 displayInLayerSwitcher: false,
 isBaseLayer: false
 }
);
 map.addLayers([layer]);
 map.setCenter(new OpenLayers.LonLat(73.25, 20.35), 6);
 //for (var i in infoControls) { 
 //infoControls[i].events.register("getfeatureinfo",
this, showInfo);
 //map.addControl(infoControls[i]); 
 //}

 map.addControl(new OpenLayers.Control.LayerSwitcher());
 map.zoomToMaxExtent();
 //infoControls.click.activate();



 }  
  
  
  









and my map file is:

# Map file created from QGIS project file D:/QGIS/newwr.qgs
# Edit this file to customize for your map interface
# (Created with PyQgis MapServer Export plugin)
MAP
  NAME newwr.map
  # Map image size
  SIZE 600 600
  UNITS dd
  EXTENT 67.440106 17.379867 78.390250 25.122977
  FONTSET 'D:\ms4w\Apache\cgi-bin\Shape\font.txt'
  PROJECTION
'proj=longlat'
'ellps=WGS84'
'datum=WGS84'
'no_defs'
''
  END
  
  
  # Background color for the map canvas -- change as desired
  IMAGECOLOR 192 192 192
  IMAGEQUALITY 95
  IMAGETYPE gif
  OUTPUTFORMAT
NAME GIF
DRIVER 'GD/gif'
MIMETYPE 'image/gif'
#IMAGEMODE PC256
EXTENSION 'gif'
  END
  
  # Legend
  LEGEND
  IMAGECOLOR 255 255 255
STATUS ON
KEYSIZE 18 12
LABEL
  TYPE BITMAP
  SIZE MEDIUM
  COLOR 0 0 89
END
  END
  
  # Web interface definition. Only the template parameter
  # is required to display a map. See MapServer documentation
  WEB
# Set IMAGEPATH to the path where MapServer should
# write its output.
IMAGEPATH '/tmp/'

# Set IMAGEURL to the url that points to IMAGEPATH
# as defined in your web server configuration
IMAGEURL '/tmp/'

# WMS server settings
METADATA
  'wms_title'   'newwr.map'
  'wms_onlineresource' 
'http://my.host.com/cgi-bin/mapserv?map=wms.map&;'
  'wms_srs' 'EPSG:4326'
END

#Scale range at which web interface will operate
# Template and header/footer settings
# Only the template parameter is required to display a map. See
MapServer documentation
  END

  LAYER
NAME 'STATE'
TYPE POLYGON
DATA 'D:\ms4w\Apache\cgi-bin\Shape\STATE.shp'

METADATA
  'wms_title' 'STATE'
END
STATUS DEFAULT
TRANSPARENCY 100
PROJECTION
'proj=longlat'
'ellps=WGS84'
'datum=WGS84'
'no_defs'
''
END
CLASS
   NAME 'STATE' 
   STYLE
 SYMBOL 0 
 SIZE 2 
 OUTLINECOLOR 0 0 0
 COLOR 255 255 127
   END
END
  END

  LAYER
NAME 'WaterBody'
TYPE POLYGON
DATA 'D:\ms4w\Apache\cgi-bin\Shape\WaterBody.shp'
METADATA

But when my map comes up it is having a BBOX size of 256 * 256.
the url of the generated map is as follows:

http://172.16.0.144:9000/cgi-bin/mapserv.exe?MAP=Shape%2Fnewwr1.map&LAYERS=STATE&FORMAT=png&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=0,-90,180,90&WIDTH=256&HEIGHT=256

Why does it happen?
Is it because of some wrong openlayers code I have written or some bug?
What should I do to get back to the desired size i.e 600 * 600

Thanks for your attention & efforts.

-- 
View this message in context: 
http://n2.nabble.com/mapserver-not-generating-proper-map-tp4776875p4776875.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

[mapserver-users] Re: mapserver not generating proper map

[BrainDrain]

map = new OpenLayers.Map('<%=map.ClientID%>', {tileSize: new
OpenLayers.Size(600,600)}); 
or
 layer.tileSize=new OpenLayers.Size(600,600);
 layer.imageSize = layer.tileSize;
-- 
View this message in context: 
http://n2.nabble.com/mapserver-not-generating-proper-map-tp4776875p4777049.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

[mapserver-users] List of color combination in MapServer

[Phalguni Pal]

Hi friends,

1. Could you anybody tell me where can I get the list of some standard
MapServer colors with color mames, like:

COLOR  0 0 0 > Black
COLOR 255 0 0 --> Red
COLOR -1 -1 -1 ---> light blue

etc.
2. How to fill a hollow square with two diffetent colors (50-50%)?

Thanking you.
With regards,

-- 
// Phalguni
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Error showing tracks from gpx file

[Dejan Gambin]

Hi,

I am trying to show data from gpx file using Mapserver. I can successfully show 
"track_points" layer but when trying with "tracks" layer, which is "multi line 
string" with one feature only, I get:

msOGRFileNextShape(): IllegalArgumentException: point array must contain 0 or 
>1 elements

here is the relevant part of mapfile:

LAYER
  NAME "gpx_test"
  TYPE LINE
  STATUS DEFAULT
  CONNECTIONTYPE OGR
  CONNECTION "test.gpx"
  DATA "tracks"
  PROJECTION
"init=epsg:4326"
  END
  METADATA
"DESCRIPTION" "GPX Test"
  END
  CLASS
Name 'Track points'
OUTLINECOLOR 0 0 0
SYMBOL 'circle'
SIZE 2
TEMPLATE void
  END  # Class
END

thanks very much

regards, dejan

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Map file xsl transformation and regular expressions

[Alan Boudreault]

Alexandre, could you test the new xsl file  and see if your two issues have 
been fixed. You can get it via: 
http://trac.osgeo.org/mapserver/browser/trunk/mapserver/xmlmapfile/mapfile.xsl?format=raw

I did a quick fix to integrate it in MS 5.6.3, which is supposed to be 
released today.

expression/filter examples:
583 or 583 
will be quoted.
/.../ and 
(...) will not be quoted.

symbol examples:
star.gif will be quoted
32 will not be quoted

Thanks,
Alan

On March 19, 2010 02:59:17 pm Alexandre Soares wrote:
> The symbol attribute (which does not get quoted by default) causes a
>  problem if the value references a stmbol's name. I think it could also
>  benefit from your fix.
> 
> Thank you!
> On Fri, Mar 19, 2010 at 2:49 PM, Alan Boudreault
> 
> wrote:
> > Alexandre, you are right, if the expression is an regular expression, it
> > shouldn't be quoted. I think the only solution would be to add an
> > attribute in
> > the xml schema, that will specify if the expression is an regular
> > expression
> > of not. Something like:
> >
> > 
> >
> > In this case, the xsl transformation would not quote it. I take a note on
> > that
> > and should fix this in the next few days.
> >
> > Thanks for reporting!
> > Alan
> >
> > On March 19, 2010 02:21:45 pm Alexandre Soares wrote:
> > > Hi,
> > >
> > > When I transform my xml map file to a map file, my expressions that
> >
> > contain
> >
> > > a regular expression (the same is true for filters) are rendered with
> > >  double quotes (because the stylesheet has the quote="1" param for
> > > those templates).
> > >
> > > Is there an intended way to achieve this? I know I could modify the
> > > stylesheet to not quote those elements and then quote-wrap my value if
> > > I need them (in case of string comparison).
> > >
> > > Thank you!
> >
> > --
> > Alan Boudreault
> > Mapgears
> > http://www.mapgears.com
> 

-- 
Alan Boudreault
Mapgears
http://www.mapgears.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] List of color combination in MapServer

[Stephen Woodbridge]

Phalguni Pal wrote:

Hi friends,

1. Could you anybody tell me where can I get the list of some standard 
MapServer colors with color mames, like:


COLOR  0 0 0 > Black
COLOR 255 0 0 --> Red
COLOR -1 -1 -1 ---> light blue


These are standard RGB values for colors, except -1 -1 -1 means no color 
so what ever is already displayed will not be over written.


You can also use syntax like:

COLOR "#00"
COLOR "#FF"

etc.

etc. 
2. How to fill a hollow square with two diffetent colors (50-50%)?


http://mapserver.org/documentation.html

Specificaly look at:

# Cartographic Symbol Construction with MapServer
# Symbology Examples

-Steve W



Thanking you.
With regards,

--
// Phalguni




___
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] Memory Leaks with Python Mapscript?

[Jason Beverage]

Hi all,

I'm using Python mapscript to generate map tiles similar to the way
that TileCache does and I think I'm running into some memory leaks.
I'm generating my mapObj and layerObj on the fly based on contents of
our database.

If I let my seed process run for a very long time, the memory use
seems to grow and grow.  I've seen recommendations on the TileCache
page to avoid using Mapscript b/c of memory leaks and even a note on
the mapserver users list saying that the Python bindings "tend to leak
like a sieve".
(http://www.mail-archive.com/mapserver-users@lists.osgeo.org/msg05821.html).

My process is pretty simple, create a new mapObj, add some layerObj's
to it, draw the image, and repeate.

I'm using MapServer/MapScript 5.6.1 and GDAL 1.6.3.  If anyone has any
tips to avoid leaking mem it would be much appreciated!

Thanks,

Jason
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] List of color combination in MapServer

[Daniel Morissette]

Stephen Woodbridge wrote:

Phalguni Pal wrote:

Hi friends,

1. Could you anybody tell me where can I get the list of some standard 
MapServer colors with color mames, like:


COLOR  0 0 0 > Black
COLOR 255 0 0 --> Red
COLOR -1 -1 -1 ---> light blue


These are standard RGB values for colors, except -1 -1 -1 means no color 
so what ever is already displayed will not be over written.


You can also use syntax like:

COLOR "#00"
COLOR "#FF"



See also: http://en.wikipedia.org/wiki/Web_colors

Daniel
--
Daniel Morissette
http://www.mapgears.com/
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] keyimage / getlegendgraphic

[Jörg Thomsen]

huhu,

does really nobody have an idea how to solve this? :(


since an update from mapserver 4.x to 5.6 we have a problem with the
keyimage of rasterlayers. The keyimage is unusually large, but with
the old version it worked.

the original imagine is 451*1949 px the keysize in the mapfile is
given with

KEYSIZE 450 1950


The image which is now delivered has a size of 472*1960px, most of
this picture is white canvas, the original graphic is very small and
placed at the lower left corner.

Any suggestions?


I found an older post meanwhile, so I am not the only one having this 
problem:

http://lists.osgeo.org/pipermail/mapserver-users/2009-December/063947.html

Regards, Jörg
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Map file xsl transformation and regular expressions

[Alexandre Soares]

Hi Alan,

I found one small bug: the default value of expressionType complex type is
'CONSTANT'. However, the stylesheet will only quote if the value of the
attribute is equal to 'CONSTANT', which is not if you don't supply a value
for this attribute. All other cases seem to work fine. That
is, 583 will not be quoted with the current
stylesheet.

Thanks!

On Mon, Mar 22, 2010 at 12:04 PM, Alan Boudreault
wrote:

> Alexandre, could you test the new xsl file  and see if your two issues have
> been fixed. You can get it via:
>
> http://trac.osgeo.org/mapserver/browser/trunk/mapserver/xmlmapfile/mapfile.xsl?format=raw
>
> I did a quick fix to integrate it in MS 5.6.3, which is supposed to be
> released today.
>
> expression/filter examples:
> 583 or
> 583
> will be quoted.
> /.../ and
> (...) will not be quoted.
>
> symbol examples:
> star.gif will be quoted
> 32 will not be quoted
>
> Thanks,
> Alan
>
> On March 19, 2010 02:59:17 pm Alexandre Soares wrote:
> > The symbol attribute (which does not get quoted by default) causes a
> >  problem if the value references a stmbol's name. I think it could also
> >  benefit from your fix.
> >
> > Thank you!
> > On Fri, Mar 19, 2010 at 2:49 PM, Alan Boudreault
> >
> > wrote:
> > > Alexandre, you are right, if the expression is an regular expression,
> it
> > > shouldn't be quoted. I think the only solution would be to add an
> > > attribute in
> > > the xml schema, that will specify if the expression is an regular
> > > expression
> > > of not. Something like:
> > >
> > > 
> > >
> > > In this case, the xsl transformation would not quote it. I take a note
> on
> > > that
> > > and should fix this in the next few days.
> > >
> > > Thanks for reporting!
> > > Alan
> > >
> > > On March 19, 2010 02:21:45 pm Alexandre Soares wrote:
> > > > Hi,
> > > >
> > > > When I transform my xml map file to a map file, my expressions that
> > >
> > > contain
> > >
> > > > a regular expression (the same is true for filters) are rendered with
> > > >  double quotes (because the stylesheet has the quote="1" param for
> > > > those templates).
> > > >
> > > > Is there an intended way to achieve this? I know I could modify the
> > > > stylesheet to not quote those elements and then quote-wrap my value
> if
> > > > I need them (in case of string comparison).
> > > >
> > > > Thank you!
> > >
> > > --
> > > Alan Boudreault
> > > Mapgears
> > > http://www.mapgears.com
> >
>
> --
>  Alan Boudreault
> Mapgears
> http://www.mapgears.com
>
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Map file xsl transformation and regular expressions

[Alan Boudreault]

It's fixed. The new xslt will be in MapServer 5.6.3.

Thanks,
Alan

On March 22, 2010 02:56:16 pm Alexandre Soares wrote:
> Hi Alan,
> 
> I found one small bug: the default value of expressionType complex type is
> 'CONSTANT'. However, the stylesheet will only quote if the value of the
> attribute is equal to 'CONSTANT', which is not if you don't supply a value
> for this attribute. All other cases seem to work fine. That
> is, 583 will not be quoted with the current
> stylesheet.
> 
> Thanks!
> 
> On Mon, Mar 22, 2010 at 12:04 PM, Alan Boudreault
> 
> wrote:
> > Alexandre, could you test the new xsl file  and see if your two issues
> > have been fixed. You can get it via:
> >
> > http://trac.osgeo.org/mapserver/browser/trunk/mapserver/xmlmapfile/mapfil
> >e.xsl?format=raw
> >
> > I did a quick fix to integrate it in MS 5.6.3, which is supposed to be
> > released today.
> >
> > expression/filter examples:
> > 583 or
> > 583
> > will be quoted.
> > /.../ and
> > (...) will not be quoted.
> >
> > symbol examples:
> > star.gif will be quoted
> > 32 will not be quoted
> >
> > Thanks,
> > Alan
> >
> > On March 19, 2010 02:59:17 pm Alexandre Soares wrote:
> > > The symbol attribute (which does not get quoted by default) causes a
> > >  problem if the value references a stmbol's name. I think it could also
> > >  benefit from your fix.
> > >
> > > Thank you!
> > > On Fri, Mar 19, 2010 at 2:49 PM, Alan Boudreault
> > >
> > > wrote:
> > > > Alexandre, you are right, if the expression is an regular expression,
> >
> > it
> >
> > > > shouldn't be quoted. I think the only solution would be to add an
> > > > attribute in
> > > > the xml schema, that will specify if the expression is an regular
> > > > expression
> > > > of not. Something like:
> > > >
> > > > 
> > > >
> > > > In this case, the xsl transformation would not quote it. I take a
> > > > note
> >
> > on
> >
> > > > that
> > > > and should fix this in the next few days.
> > > >
> > > > Thanks for reporting!
> > > > Alan
> > > >
> > > > On March 19, 2010 02:21:45 pm Alexandre Soares wrote:
> > > > > Hi,
> > > > >
> > > > > When I transform my xml map file to a map file, my expressions that
> > > >
> > > > contain
> > > >
> > > > > a regular expression (the same is true for filters) are rendered
> > > > > with double quotes (because the stylesheet has the quote="1" param
> > > > > for those templates).
> > > > >
> > > > > Is there an intended way to achieve this? I know I could modify the
> > > > > stylesheet to not quote those elements and then quote-wrap my value
> >
> > if
> >
> > > > > I need them (in case of string comparison).
> > > > >
> > > > > Thank you!
> > > >
> > > > --
> > > > Alan Boudreault
> > > > Mapgears
> > > > http://www.mapgears.com
> >
> > --
> >  Alan Boudreault
> > Mapgears
> > http://www.mapgears.com
> 

-- 
Alan Boudreault
Mapgears
http://www.mapgears.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Re: mapserver not generating proper map

[sunny74]

Hi BrainDrain,

Thanks for your reply.
Your solution doesn't work.

the code relating to the info control is the culprit.
It started giving errors, then I commented it but after that the map was not
getting displayed.
Finally after a lot of effort I got the map but with problems stated
earlier.
After applying your code I find that the background is occupying 600 * 600
but the actual layers are coming small even though magnification level is 6
or more.

I think it is Openlayer 2.8 which is causing the problem.So I need to go
back to OL2.7.
But then is it possible to hav Get Feature Info in 2.7 from shape files? 
If you know how to do it pls send code across.




-- 
View this message in context: 
http://n2.nabble.com/mapserver-not-generating-proper-map-tp4776875p4779918.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

[mapserver-users] Re: mapserver not generating proper map

[BrainDrain]

If layer hasn't tilesSize/imageSize options it copies from map.baseLayer/map
Did you set tileSize for map and every layer?
What do you mean background (it's just a one layer)? 
I'm using OL 2.8 for a long time with raster base layers and transparent
vector layer (both from mapserver)
and I have no problems. 
OL getURL function result independent from level both for wms and mapserver
layers

-- 
View this message in context: 
http://n2.nabble.com/mapserver-not-generating-proper-map-tp4776875p4780393.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

Re: [mapserver-users] keyimage / getlegendgraphic

[Yewondwossen Assefa]

Jörg,

bug related to this is http://trac.osgeo.org/mapserver/ticket/3398. It 
should be fixed in trunk


regards,



Jörg Thomsen wrote:

huhu,

does really nobody have an idea how to solve this? :(


since an update from mapserver 4.x to 5.6 we have a problem with the
keyimage of rasterlayers. The keyimage is unusually large, but with
the old version it worked.

the original imagine is 451*1949 px the keysize in the mapfile is
given with

KEYSIZE 450 1950


The image which is now delivered has a size of 472*1960px, most of
this picture is white canvas, the original graphic is very small and
placed at the lower left corner.

Any suggestions?


I found an older post meanwhile, so I am not the only one having this 
problem:
http://lists.osgeo.org/pipermail/mapserver-users/2009-December/063947.html 



Regards, Jörg
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users




--

Assefa Yewondwossen   
Software Analyst   

Email: ass...@dmsolutions.ca
http://www.dmsolutions.ca/


Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925



___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?

[Tamas Szekeres]

Hi,

I second to these concerns, absolutely. With regards to RFC 52 there have
been a couple of breaking changes in MapServer 5.6 which prevents me from
upgrading to this version in my existing projects. I've already tried to
ring the bell in this topic with a couple of posts (see below), but it seems
the use case described here (as keeping long term mapObj references) is not
widely used and falls ouside of the general area of interest;

http://n2.nabble.com/Ready-for-5-6-2-td4743344.html#a4746772
http://n2.nabble.com/OGR-single-pass-query-issues-was-Ready-for-5-6-2-td4753764.html

By raising up your issues below I've studied RFC
52again to see
the objectives, and it seems we are getting out of the sync
with the current implementation at the drivers.

In my understanding with the original approach the driver should:

1. Retain the result set of the queries at the layer (ie. in the layerinfo
structure) until the layer is open and no subsequent whichShapes is called
to 'invalidate' the query.
2. Provide such index in shapeObj which would allow to retieve in a
subsequent resultsGetShape within the result set.
3. Retain the random access behaviour (getShape) for backward compatibility
in parallel to resultsGetShape.


Since the RFC doesn't contain explicit note about the opposite, the drivers
should also:

4. Preserve the behaviour of keeping separate set of results for separate
layer instances. In this regard a query on one layer should not invalidate
the results for a different layer instance of the same driver.
5. Creating a clone of a layer should provide to use a separate query (by
keeping the results intact on the original layer). This would be essential
for msDrawQueryLayer to work when drawing the background before the
highlighted features.
6. Using a drawQuery should not invalidate the results of a previous query.
7. Drawing the map should not invalidate the results of a previous query.


Further notes: To provide correct implementations at the drivers it seems we
should provide a bit more information for the driver to distinguish between
the purpose of a query. For example whichShapes should take an additional
parameter (querymode) with the following predefined values:

MS_QUERY_SEQUENTIAL:  The returned shapes will be retrieved by nextShape (no
subsequent (result)getshape will happen). This would be used by the normal
drawing operations.
MS_QUERY_RANDOM: The results would be retrieved by nextShape. The driver
would provide oid-s as feature indexes to support to retrieve the features
by the original (2 pass) behaviour (getShape). No features are retained at
the driver for further access.
MS_QUERY_PRESERVE: The results would be retrieved by nextShape and
resultsGetShape. The drivers should store the result set at the layer for
further retrieval (1 pass).

The features retrieved by MS_QUERY_PRESERVE should be kept in a separate
location either in layerinfo or in a separate structure (a queryinfo for
example). The latter would provide the isolate the results from the layer
opened state.
MS_QUERY_SEQUENTIAL or MS_QUERY_RANDOM should not invalidate the results in
queryinfo.


We should also provide the user with an option to select between the default
of MS_QUERY_RANDOM/MS_QUERY_PRESERVE at layer level. Probably a layer
processing option would be sufficient.



Best regards,


Tamas








2010/3/21 BrainDrain 

>
> Please read carefully.
> 'old style' (two pass) query
> advantages:
> - in mapscript (c#) layer's query methods are CUMULATIVE (relative to other
> layer's queries). Query result (success/failure) has no effect on other
> layers when I call map.savequery.
> - In this case (query file contains just oid's) - I CAN create COMPLEX
> queries by applying different parameters and mixing query types
> - Query result is oid (or row index in shapefile) - it's cool for creating
> advanced attr. postqueries
> and disadvantages (insignificant):
> - query binary (closed) format? no output to string (only to file)
> - query file sensitive to layer indexes (map file cleanups/refinements/some
> normalization can cause query file incompatibility)
> - if server data changed refreshing map image by old url to cgi with
> queryfile parameter doesn't perform requery (need custom http
> handler/module)
> AND ONE PASS QUERY (RFC 52)
> advantages:
> - open query file format
> - speedup (no random access)
> disadvantages (huge):
> - layer's query methods are NOT CUMULATIVE (relative to other layer's
> queries). I CAN'T create COMPLEX queries (by using different
> attribute/spatial queries (metadata driven) for different layers)!
> - query result - some (shape)indexes and when I'm querying many layers in
> sequence I NEED TO PRESERVE QUERY FILE FOR EVERY LAYER (on success result)
> (!) and than on feature attributes (for some layer) demand (delayed request
> - its a normal behavior, for. ex I'm requesting only shape names for some
> layer which has results - to build 

[mapserver-users] MapServer 5.6.3 released (obsoletes 5.6.2)

[Daniel Morissette]

The MapServer team announces the release of MapServer version 5.6.3.

This release obsoletes 5.6.2 which was announced only two days ago. 
Unfortunately, two issues introduced in 5.6.2 made that release unusable 
for several use cases involving PostGIS and SDE layers, prompting us to 
issue a new release with those fixes.


The list of fixes since in 5.6.2 and 5.6.3 is included at the end of 
this message.


The source code is available at:

http://mapserver.org/download.html

The binary distributions listed in the download page should be updated 
with the new release in the next few days.



Version 5.6.3 (2010-03-22):
---

- Fixed problem with PostGIS SQL bbox introduced in 5.6.2 (#3324)

- Fix backwards handling of iconv errors (w/ SDE) introduced in 5.6.2 
(#2988)


- Fixed XML transformation issues with expressions and symbols (#3397)


Version 5.6.2 (2010-03-20):
---

- Check error returns from mapstring functions (#2988)

- Correct mutex locking problem with rasters with no inherent georef. 
(#3368)


- Fixed problem with isValidItem vs OGR special attributes (#3356)

- Support wrap character for SVG output (#3367)

- Fixed msMSSQL2008CloseConnection() to free the statement handle
  properly (#3244)

- Fixed PHP MapScript's metadata.nextkey() that was sometimes skipping some
  entries on first call because the NULL arg was not properly handled 
(#3363)


- Fixed the query handling with the MSSQL2008 driver (#3058)

- Fixed swig zoomRectangle() method: the maxy in the rect object have to
  be < miny value (#3286)

- Backport fix for SLD filters column names detection (#3052)

- Backport fix for WFS OGC filters regex tests (#3289)

- Fix crash with GRID layers with no classes (#3352)

- Avoid memory error when building SQL bbox (#3324)

- Determine PgSQL version in a more backwards compatible way (#3291)

- Implemented RFC 52 LayerResultsGetShape support for OGR connection
  type. (#3069)

- Fixed problem with the oracle driver w/FUNCTION=NONE (#3260)

- Got rid of invalid warning about missing EPSG proj in WMs GetCapabilities
  when map has a valid EPSG proj, but layer doesn't (#2028)

- Correct one pass query problems and OGC filter query (#3305)

- Correct QueryByOperator (#3346)

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?

[Frank Warmerdam]

Tamas Szekeres wrote:

In my understanding with the original approach the driver should:

1. Retain the result set of the queries at the layer (ie. in the 
layerinfo structure) until the layer is open and no subsequent 
whichShapes is called to 'invalidate' the query.


Tamas,

Your point here is that the query result should live until
invalidated by another whichShapes, right?  I would agree with
that, but draw on a layer does do a whichShapes, right?  So a
draw is expected to invalidate a query, right?

2. Provide such index in shapeObj which would allow to retieve in a 
subsequent resultsGetShape within the result set.


ok

3. Retain the random access behaviour (getShape) for backward 
compatibility in parallel to resultsGetShape.


ok

Since the RFC doesn't contain explicit note about the opposite, the 
drivers should also:


4. Preserve the behaviour of keeping separate set of results for 
separate layer instances. In this regard a query on one layer should not 
invalidate the results for a different layer instance of the same driver.


This seems to be a lot to expect.  We go to significant effort with
the connection pooling to allow reuse of a connection for different
layers, and in effect in many drivers this connection also carries
a bunch of context with it.  Certainly in the case of OGR an
OGRLayer retains a concept of current query result, but it can
be invalidated by lots of operations other than ResetReading() and
GetNextFeature().  I would imagine this is true to a greater or
lesser to other drivers that pool connections.

5. Creating a clone of a layer should provide to use a separate query 
(by keeping the results intact on the original layer). This would be 
essential for msDrawQueryLayer to work when drawing the background 
before the highlighted features.


This is also quite impractical for some implementations - certainly
for OGR.


6. Using a drawQuery should not invalidate the results of a previous query.


I don't know much about drawQuery but it does seem plausible to ask
that drawQuery should not invalidate the query it is drawing.


7. Drawing the map should not invalidate the results of a previous query.


But drawing maps uses the feature access machinery like whichShapes
doesn't it?  How can we expect map drawing not to invalidate a query?

In retrospect, I'm not all that confident that we really considered
the impact of RFC 52 on use cases such as those you raise.  I
certainly didn't understand these impacts.  What is less clear to
me is where to go from here.  RFC 52 was put in place because the
old approach was giving terrible performance in some cases.
But if we put the expectations you list into place there is no
way it can be made fast on OGR short of maintaining distinct
OGRDataset instances for each query in addition to the one used to
draw the layer.  This could cause various performance and
resource problems.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Re: Cannot get a PostGIS layer to render in Mapserver...

[mapper99]

I am running PostGIS 1.5 for PostgreSQL 8.4.  It appears the force_2d
function is available:

-- Function: force_2d(geometry)

-- DROP FUNCTION force_2d(geometry);

CREATE OR REPLACE FUNCTION force_2d(geometry)
  RETURNS geometry AS
'$libdir/postgis-1.5', 'LWGEOM_force_2d'
  LANGUAGE 'c' IMMUTABLE STRICT
  COST 1;
ALTER FUNCTION force_2d(geometry) OWNER TO postgres;

Is there any other way to test this?


-- 
View this message in context: 
http://n2.nabble.com/Cannot-get-a-PostGIS-layer-to-render-in-Mapserver-tp4776199p4782272.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

RE: [mapserver-users] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?

[Lime, Steve D (DNR)]

I think we're in need of a RFC 52a. Clearly the compound query handling the old 
approach afforded is of value to a group of users and that wasn't accounted for 
in the initial RFC. The work around Assefa had to do with WFS and a certain 
subset of OGC filters at the sprint is evidence that the approach was even used 
in the core code (I wasn't aware of that at the time). We (in 5.6.3) developed 
a work around that retains two sets of indexes one suitable for random access 
and one for a specific result set (e.g. cursor). It uses the already present 
tileindex property of a shapeObj to store the latter. I think we can have the 
best of both here by storing the two indexes and potentially we can revert to a 
single getShape() function in MapScript and revive the old queryfile format as 
a option as well. Just needs to be planned for now that the full impacts are 
better understood.

Steve

From: mapserver-users-boun...@lists.osgeo.org 
[mapserver-users-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam 
[warmer...@pobox.com]
Sent: Monday, March 22, 2010 10:16 PM
To: Tamas Szekeres
Cc: mapserver-users@lists.osgeo.org; BrainDrain
Subject: Re: [mapserver-users] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?

Tamas Szekeres wrote:
> In my understanding with the original approach the driver should:
>
> 1. Retain the result set of the queries at the layer (ie. in the
> layerinfo structure) until the layer is open and no subsequent
> whichShapes is called to 'invalidate' the query.

Tamas,

Your point here is that the query result should live until
invalidated by another whichShapes, right?  I would agree with
that, but draw on a layer does do a whichShapes, right?  So a
draw is expected to invalidate a query, right?

> 2. Provide such index in shapeObj which would allow to retieve in a
> subsequent resultsGetShape within the result set.

ok

> 3. Retain the random access behaviour (getShape) for backward
> compatibility in parallel to resultsGetShape.

ok

> Since the RFC doesn't contain explicit note about the opposite, the
> drivers should also:
>
> 4. Preserve the behaviour of keeping separate set of results for
> separate layer instances. In this regard a query on one layer should not
> invalidate the results for a different layer instance of the same driver.

This seems to be a lot to expect.  We go to significant effort with
the connection pooling to allow reuse of a connection for different
layers, and in effect in many drivers this connection also carries
a bunch of context with it.  Certainly in the case of OGR an
OGRLayer retains a concept of current query result, but it can
be invalidated by lots of operations other than ResetReading() and
GetNextFeature().  I would imagine this is true to a greater or
lesser to other drivers that pool connections.

> 5. Creating a clone of a layer should provide to use a separate query
> (by keeping the results intact on the original layer). This would be
> essential for msDrawQueryLayer to work when drawing the background
> before the highlighted features.

This is also quite impractical for some implementations - certainly
for OGR.

> 6. Using a drawQuery should not invalidate the results of a previous query.

I don't know much about drawQuery but it does seem plausible to ask
that drawQuery should not invalidate the query it is drawing.

> 7. Drawing the map should not invalidate the results of a previous query.

But drawing maps uses the feature access machinery like whichShapes
doesn't it?  How can we expect map drawing not to invalidate a query?

In retrospect, I'm not all that confident that we really considered
the impact of RFC 52 on use cases such as those you raise.  I
certainly didn't understand these impacts.  What is less clear to
me is where to go from here.  RFC 52 was put in place because the
old approach was giving terrible performance in some cases.
But if we put the expectations you list into place there is no
way it can be made fast on OGR short of maintaining distinct
OGRDataset instances for each query in addition to the one used to
draw the layer.  This could cause various performance and
resource problems.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
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] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?

[Paul Ramsey]

Is it better to back out to the old behaviour or would defining a
filter object that allows complex query logic meet the need in a more
direct way? (Ie, is running multiple queries a feature or a workaround
for an even older limitation?)

P.

On Mon, Mar 22, 2010 at 9:21 PM, Lime, Steve D (DNR)
 wrote:
> I think we're in need of a RFC 52a. Clearly the compound query handling the 
> old approach afforded is of value to a group of users and that wasn't 
> accounted for in the initial RFC. The work around Assefa had to do with WFS 
> and a certain subset of OGC filters at the sprint is evidence that the 
> approach was even used in the core code (I wasn't aware of that at the time). 
> We (in 5.6.3) developed a work around that retains two sets of indexes one 
> suitable for random access and one for a specific result set (e.g. cursor). 
> It uses the already present tileindex property of a shapeObj to store the 
> latter. I think we can have the best of both here by storing the two indexes 
> and potentially we can revert to a single getShape() function in MapScript 
> and revive the old queryfile format as a option as well. Just needs to be 
> planned for now that the full impacts are better understood.
>
> Steve
> 
> From: mapserver-users-boun...@lists.osgeo.org 
> [mapserver-users-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam 
> [warmer...@pobox.com]
> Sent: Monday, March 22, 2010 10:16 PM
> To: Tamas Szekeres
> Cc: mapserver-users@lists.osgeo.org; BrainDrain
> Subject: Re: [mapserver-users] ONE PASS QUERY (RFC 52) - FEATURE OR BUG?
>
> Tamas Szekeres wrote:
>> In my understanding with the original approach the driver should:
>>
>> 1. Retain the result set of the queries at the layer (ie. in the
>> layerinfo structure) until the layer is open and no subsequent
>> whichShapes is called to 'invalidate' the query.
>
> Tamas,
>
> Your point here is that the query result should live until
> invalidated by another whichShapes, right?  I would agree with
> that, but draw on a layer does do a whichShapes, right?  So a
> draw is expected to invalidate a query, right?
>
>> 2. Provide such index in shapeObj which would allow to retieve in a
>> subsequent resultsGetShape within the result set.
>
> ok
>
>> 3. Retain the random access behaviour (getShape) for backward
>> compatibility in parallel to resultsGetShape.
>
> ok
>
>> Since the RFC doesn't contain explicit note about the opposite, the
>> drivers should also:
>>
>> 4. Preserve the behaviour of keeping separate set of results for
>> separate layer instances. In this regard a query on one layer should not
>> invalidate the results for a different layer instance of the same driver.
>
> This seems to be a lot to expect.  We go to significant effort with
> the connection pooling to allow reuse of a connection for different
> layers, and in effect in many drivers this connection also carries
> a bunch of context with it.  Certainly in the case of OGR an
> OGRLayer retains a concept of current query result, but it can
> be invalidated by lots of operations other than ResetReading() and
> GetNextFeature().  I would imagine this is true to a greater or
> lesser to other drivers that pool connections.
>
>> 5. Creating a clone of a layer should provide to use a separate query
>> (by keeping the results intact on the original layer). This would be
>> essential for msDrawQueryLayer to work when drawing the background
>> before the highlighted features.
>
> This is also quite impractical for some implementations - certainly
> for OGR.
>
>> 6. Using a drawQuery should not invalidate the results of a previous query.
>
> I don't know much about drawQuery but it does seem plausible to ask
> that drawQuery should not invalidate the query it is drawing.
>
>> 7. Drawing the map should not invalidate the results of a previous query.
>
> But drawing maps uses the feature access machinery like whichShapes
> doesn't it?  How can we expect map drawing not to invalidate a query?
>
> In retrospect, I'm not all that confident that we really considered
> the impact of RFC 52 on use cases such as those you raise.  I
> certainly didn't understand these impacts.  What is less clear to
> me is where to go from here.  RFC 52 was put in place because the
> old approach was giving terrible performance in some cases.
> But if we put the expectations you list into place there is no
> way it can be made fast on OGR short of maintaining distinct
> OGRDataset instances for each query in addition to the one used to
> draw the layer.  This could cause various performance and
> resource problems.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> __