Re: [mapserver-users] msOGRFileOpen(): Falling back to MapServer only evaluation

[Gert Cuykens]

Sounds logical unfortunately even with debug set to 0 and changing
DATA "select node from nodes" and the others to sql syntax i still get
this message

(Mapserver 7.0.6)

msOGRFileOpen(): Falling back to MapServer only evaluation" while
reading upstream, client: 172.17.0.1, server: , request: "GET
/?map=/basemap/basemap.map=nodes+segments=tile=gmap=8473+5568+14.png
HTTP/1.1", upstream: "fastcgi://unix:/var/run/mapserv.socket:", host:
"localhost:8080"
172.17.0.1 - - [17/Oct/2017:21:47:54 +] "GET
/?map=/basemap/basemap.map=nodes+segments=tile=gmap=8473+5568+14.png
HTTP/1.1" 200 10353 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X
10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.52
Safari/537.36"
2017/10/17 21:47:55 [error] 11#0: *2 FastCGI sent in stderr:
"msOGRFileOpen(): Falling back to MapServer only evaluation
msOGRFileOpen(): Falling back to MapServer only evaluation" while
reading upstream, client: 172.17.0.1, server: , request: "GET
/?map=/basemap/basemap.map=nodes+segments=tile=gmap=8473+5571+14.png
HTTP/1.1", upstream: "fastcgi://unix:/var/run/mapserv.socket:", host:
"localhost:8080"
172.17.0.1 - - [17/Oct/2017:21:47:55 +] "GET
/?map=/basemap/basemap.map=nodes+segments=tile=gmap=8473+5571+14.png
HTTP/1.1" 200 20563 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X
10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.52
Safari/537.36"

On Tue, Oct 17, 2017 at 8:50 PM, Lime, Steve D (MNIT)
 wrote:
> Hi: The message is specific to SQLite. I believe it has to do how filtering 
> can be done and depends on the form of your DATA statement. If you don't use 
> SQL syntax for the data statement then you have to fall back to MapServer 
> filter syntax. See http://mapserver.org/input/vector/sqlite.html for examples 
> of each. You could try the SQL syntax in your mapfile and see if that log 
> entry disappears (I'm not setup to test SQLite here). Probably could make the 
> docs clearer about the advantages of one approach vs the other. In any case I 
> think the message is benign and informational only...
>
> Steve
>
> -Original Message-
> From: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] On 
> Behalf Of Gert Cuykens
> Sent: Sunday, October 15, 2017 9:32 PM
> To: mapserver-users@lists.osgeo.org
> Subject: [mapserver-users] msOGRFileOpen(): Falling back to MapServer only 
> evaluation
>
> Image that i get back from the server looks good but don't understand
> what the errors mean in the mapserver logs?
>
> http://localhost:8080/?map=/basemap/basemap.map=nodes=tile=gmap={x}+{y}+{z}.png
>
> MAP
>   NAME "basemap"
>   SHAPEPATH "/basemap"
>   CONFIG  "MS_ERRORFILE" "stderr"
>   UNITS dd
>   # UNITS METERS
>   EXTENT 5.684829 49.398312 6.599194 50.217793
>
>   STATUS ON
>   DEBUG 5
>
>   PROJECTION
> "init=epsg:4326"
> # "init=epsg:3857"
>   END
>
>   WEB
> METADATA
>   "wms_enable_request" "*"
>   "wms_title" "basemap"
>   "wms_onlineresource" "http://localhost:8080/?map=/basemap/basemap.map;
>   "wms_srs" "EPSG:4326"
>   # "wms_srs" "EPSG:3857"
>   "wms_format" "image/png"
>   # "tile_map_edge_buffer" "10"
>   # "tile_metatile_level" "0"
> END
>   END
>
>   OUTPUTFORMAT
> NAME "AGGPNG"
> DRIVER "AGG/PNG"
> EXTENSION "png"
> MIMETYPE "image/png"
> IMAGEMODE RGBA
>   END
>
>   SYMBOL
> NAME "circle"
> TYPE ellipse
> POINTS
>   1 1
> END
>   END
>
>   LAYER
> NAME nodes
> TYPE point
> CONNECTIONTYPE OGR
> CONNECTION "basemap.sqlite"
> DATA nodes
>
> CLASS
>   NAME "nodes"
>   STYLE
> SYMBOL "circle"
> COLOR 0 0 0
> SIZE 3
>   END
> END
>
>   END
>
>   LAYER
> NAME segments
> TYPE line
> CONNECTIONTYPE OGR
> CONNECTION "basemap.sqlite"
> DATA segments
>
> CLASS
>   NAME "segments"
>   STYLE
> COLOR 0 0 0
>   END
> END
>
>   END
>
>   LAYER
> NAME links
> TYPE line
> CONNECTIONTYPE OGR
> CONNECTION "basemap.sqlite"
> DATA links
>
> CLASS
>   NAME "links"
>   STYLE
> COLOR 0 0 0
>   END
> END
>
>   END
>
> END
>
> 2017/10/16 02:25:55 [error] 11#0: *534 FastCGI sent in stderr: "CGI
> Request 5 on process 9
> msTileSetExtent(): gmaps coords (x: 8473, y: 5568, z: 14)
> msTileSetExtent(): gmaps metacoords (x: 8473, y: 5568, z: 14)
> msTileSetExtent(): base image size (256 x 256)
> msTileSetExtent(): buffered image size (256 x 256)
> msTileSetExtent (687326.535559, 6415823.182566) (689762.965835, 
> 6418259.612842)
> msTileSetExtent(): gmaps coords (x: 8473, y: 5568, z: 14)
> msTileSetExtent(): gmaps metacoords (x: 8473, y: 5568, z: 14)
> msTileSetExtent(): base image size (256 x 256)
> msTileSetExt" while reading response header from upstream, client:
> 172.17.0.1, server: , request: "GET
> /?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png
> HTTP/1.1", upstream: 

Re: [mapserver-users] msOGRFileOpen(): Falling back to MapServer only evaluation

[Lime, Steve D (MNIT)]

Hi: The message is specific to SQLite. I believe it has to do how filtering can 
be done and depends on the form of your DATA statement. If you don't use SQL 
syntax for the data statement then you have to fall back to MapServer filter 
syntax. See http://mapserver.org/input/vector/sqlite.html for examples of each. 
You could try the SQL syntax in your mapfile and see if that log entry 
disappears (I'm not setup to test SQLite here). Probably could make the docs 
clearer about the advantages of one approach vs the other. In any case I think 
the message is benign and informational only...

Steve

-Original Message-
From: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] On 
Behalf Of Gert Cuykens
Sent: Sunday, October 15, 2017 9:32 PM
To: mapserver-users@lists.osgeo.org
Subject: [mapserver-users] msOGRFileOpen(): Falling back to MapServer only 
evaluation

Image that i get back from the server looks good but don't understand
what the errors mean in the mapserver logs?

http://localhost:8080/?map=/basemap/basemap.map=nodes=tile=gmap={x}+{y}+{z}.png

MAP
  NAME "basemap"
  SHAPEPATH "/basemap"
  CONFIG  "MS_ERRORFILE" "stderr"
  UNITS dd
  # UNITS METERS
  EXTENT 5.684829 49.398312 6.599194 50.217793

  STATUS ON
  DEBUG 5

  PROJECTION
"init=epsg:4326"
# "init=epsg:3857"
  END

  WEB
METADATA
  "wms_enable_request" "*"
  "wms_title" "basemap"
  "wms_onlineresource" "http://localhost:8080/?map=/basemap/basemap.map;
  "wms_srs" "EPSG:4326"
  # "wms_srs" "EPSG:3857"
  "wms_format" "image/png"
  # "tile_map_edge_buffer" "10"
  # "tile_metatile_level" "0"
END
  END

  OUTPUTFORMAT
NAME "AGGPNG"
DRIVER "AGG/PNG"
EXTENSION "png"
MIMETYPE "image/png"
IMAGEMODE RGBA
  END

  SYMBOL
NAME "circle"
TYPE ellipse
POINTS
  1 1
END
  END

  LAYER
NAME nodes
TYPE point
CONNECTIONTYPE OGR
CONNECTION "basemap.sqlite"
DATA nodes

CLASS
  NAME "nodes"
  STYLE
SYMBOL "circle"
COLOR 0 0 0
SIZE 3
  END
END

  END

  LAYER
NAME segments
TYPE line
CONNECTIONTYPE OGR
CONNECTION "basemap.sqlite"
DATA segments

CLASS
  NAME "segments"
  STYLE
COLOR 0 0 0
  END
END

  END

  LAYER
NAME links
TYPE line
CONNECTIONTYPE OGR
CONNECTION "basemap.sqlite"
DATA links

CLASS
  NAME "links"
  STYLE
COLOR 0 0 0
  END
END

  END

END

2017/10/16 02:25:55 [error] 11#0: *534 FastCGI sent in stderr: "CGI
Request 5 on process 9
msTileSetExtent(): gmaps coords (x: 8473, y: 5568, z: 14)
msTileSetExtent(): gmaps metacoords (x: 8473, y: 5568, z: 14)
msTileSetExtent(): base image size (256 x 256)
msTileSetExtent(): buffered image size (256 x 256)
msTileSetExtent (687326.535559, 6415823.182566) (689762.965835, 6418259.612842)
msTileSetExtent(): gmaps coords (x: 8473, y: 5568, z: 14)
msTileSetExtent(): gmaps metacoords (x: 8473, y: 5568, z: 14)
msTileSetExtent(): base image size (256 x 256)
msTileSetExt" while reading response header from upstream, client:
172.17.0.1, server: , request: "GET
/?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png
HTTP/1.1", upstream: "fastcgi://unix:/var/run/mapserv.socket:", host:
"localhost:8080"
2017/10/16 02:25:55 [error] 11#0: *534 FastCGI sent in stderr: "ent():
buffered image size (256 x 256)
msTileSetExtent (687326.535559, 6415823.182566) (689762.965835, 6418259.612842)
msDrawMap(): rendering using outputformat named AGGPNG (AGG/PNG).
msDrawMap(): WMS/WFS set-up and query, 0.000s
msOGRFileOpen(): Falling back to MapServer only evaluation
msDrawMap(): Layer 0 (nodes), 0.036s
msDrawMap(): Drawing Label Cache, 0.000s
msDrawMap() total time: 0.036s
msSaveImage(stdout) total time: 0.003s
mapserv request processing time (msLoadMap not incl.): 0.039s
msFr" while reading upstream, client: 172.17.0.1, server: , request:
"GET 
/?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png
HTTP/1.1", upstream: "fastcgi://unix:/var/run/mapserv.socket:", host:
"localhost:8080"
2017/10/16 02:25:55 [error] 11#0: *534 FastCGI sent in stderr:
"eeMap(): freeing map at 0x55f140fcb5c0" while reading upstream,
client: 172.17.0.1, server: , request: "GET
/?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png
HTTP/1.1", upstream: "fastcgi://unix:/var/run/mapserv.socket:", host:
"localhost:8080"
172.17.0.1 - - [16/Oct/2017:02:25:55 +] "GET
/?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png
HTTP/1.1" 200 9138 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X
10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.52
Safari/537.36"
172.17.0.1 - - [16/Oct/2017:02:25:55 +] "GET /favicon.ico
HTTP/1.1" 200 75
"http://localhost:8080/?map=/basemap/basemap.map=nodes=tile=gmap=8473+5568+14.png;
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/62.0.3202.52 Safari/537.36"

Re: [mapserver-users] Draw roads WITHOUT anti-aliasing

[Erik H]

We've considered vector tiles but the problem is that (just like image
tiles) they would involve a lot of redrawing and would require a high
bandwidth.

We envision something like 'color cycling' which is sometimes used in
graphics: see http://www.effectgames.com/demos/canvascycle/?sound=0 .

It's a bit like coloring books: you specify a palette (1=red, 2=yellow and
so on), and if you decide you want different colors, you erase the colors
that need to be changed and color them in again with the new color - no
need to have a new book shipped to you, or even to color the entire page if
some colors are unchanged.

Of course, a coloring book is not very useful if it specifies numbers that
are not in the palette, or (worse) if some numbers exist in the palette but
are just wrong (you don't want to color part of Belle's dress with the
color that was meant for Ariel's hair).

On a more technical note, we get pretty far by filtering out the pixels
with alpha != 255 (see screenshots) but some incorrect pixels remain.
Ideally, we would like to preserve some kind of anti-aliasing but we need
about 22 bits just to encode the road segments, not sure how that would
work.

As for Andreas' remark about 'simply the use of another scanline
rasterizer.' - I'm sorry but I'm not much of a C++ developer. If I have to
do rasterizing, I'd skip MapServer altogether and generate the PNG in Java.

Thanks.


On Tue, Oct 17, 2017 at 4:53 AM, Eichner, Andreas - SID <
andreas.eich...@sid.sachsen.de> wrote:

> I'd guess it's simply the use of another scanline rasterizer. The demo
>   http://www.antigrain.com/demo/rasterizers.cpp.html
> is an example of drawing as polygon aliased and anti-aliased side by side.
>
>
> > -Ursprüngliche Nachricht-
> > Von: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] Im
> > Auftrag von Richard Greenwood
> > Gesendet: Dienstag, 17. Oktober 2017 03:44
> > An: Erik H
> > Cc: mapserver-users@lists.osgeo.org
> > Betreff: Re: [mapserver-users] Draw roads WITHOUT anti-aliasing
> >
> > On Mon, Oct 16, 2017 at 1:23 PM, Erik H  wrote:
> >
> >
> >   I don't think we have much use for lines that are one pixel wide.
> >
> >   I'm surprised at how difficult this is; isn't there some driver
> > other than AGG/PNG I could use?
> >
> >
> > In mapserver versions before 7.0 there is the GD driver. I use it for 8
> > bit GIFs. Not sure what it does with 24 images.
> >
> > Rich
> >
> >
> >
> >
> >
> >
> >   On Mon, Oct 16, 2017 at 2:50 PM, Lime, Steve D (MNIT)
> >  wrote:
> >
> >
> >   So you really do need 24-bit output. I was looking back
> > through the mailing list archives and it was mentioned back in 2012 that
> > aliased output could be implemented for simple (1 pixel-wide) lines and
> > polygons – so there is hope but I don’t believe (looking through the
> > source) that Thomas ever fully implemented it. In mapagg.cpp there are
> > ifdef’s for a symbol named AGG_ALIASED_ENABLED which makes me wonder if
> > work was started. I tried setting that in mapagg.cpp but ran into
> > compile errors and didn’t try and track those down.
> >
> >
> >
> >   Of course you’d have to live with 1 pixel wide lines…
> >
> >
> >
> >   Steve
> >
> >
> >
> >   From: Erik H [mailto:erik.h11...@gmail.com]
> >   Sent: Monday, October 16, 2017 1:15 PM
> >   To: Lime, Steve D (MNIT) 
> >   Cc: mapserver-users@lists.osgeo.org  > us...@lists.osgeo.org>
> >   Subject: Re: [mapserver-users] Draw roads WITHOUT anti-
> > aliasing
> >
> >
> >
> >   Thanks for your reply, but I should have mentioned that I
> > have a LOT of different colors to be displayed, almost a million...
> >
> >
> >
> >   I should also have mentioned that I've already tried to
> > filter out the anti-aliased pixels by setting all alpha bytes to 255 and
> > then assuming that all pixels that don't have alpha=255 in the PNG can
> > be removed, but that assumption seems to be wrong.
> >
> >
> >
> >   On Mon, Oct 16, 2017 at 2:00 PM, Lime, Steve D (MNIT)
> >  wrote:
> >
> >   Hmmm… I wonder if you just could use a pre-computed
> > palette to control quantizing to 8 bits. You can supply a palette file
> > (RGB or RGBA) and the MapServer will map 24/32-bit values to those in
> > the palette. Format options are:
> >
> >
> >
> >FORMATOPTION "PALETTE_FORCE=TRUE"
> >
> >   FORMATOPTION "PALETTE=palette.txt"
> >
> >
> >
> >   This will definitely limit the colors in your
> output
> > image to those you specify. The question is whether or not the anti-
> > aliased colors will map to the right color and that will depend on your
> > palette. I did write a simple test with a 5 color palette (black, white,
> > red, green and 

Re: [mapserver-users] Draw roads WITHOUT anti-aliasing

[Eichner, Andreas - SID]

I'd guess it's simply the use of another scanline rasterizer. The demo
  http://www.antigrain.com/demo/rasterizers.cpp.html
is an example of drawing as polygon aliased and anti-aliased side by side.


> -Ursprüngliche Nachricht-
> Von: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] Im
> Auftrag von Richard Greenwood
> Gesendet: Dienstag, 17. Oktober 2017 03:44
> An: Erik H
> Cc: mapserver-users@lists.osgeo.org
> Betreff: Re: [mapserver-users] Draw roads WITHOUT anti-aliasing
> 
> On Mon, Oct 16, 2017 at 1:23 PM, Erik H  wrote:
> 
> 
>   I don't think we have much use for lines that are one pixel wide.
> 
>   I'm surprised at how difficult this is; isn't there some driver
> other than AGG/PNG I could use?
> 
> 
> In mapserver versions before 7.0 there is the GD driver. I use it for 8
> bit GIFs. Not sure what it does with 24 images.
> 
> Rich
> 
> 
> 
> 
> 
> 
>   On Mon, Oct 16, 2017 at 2:50 PM, Lime, Steve D (MNIT)
>  wrote:
> 
> 
>   So you really do need 24-bit output. I was looking back
> through the mailing list archives and it was mentioned back in 2012 that
> aliased output could be implemented for simple (1 pixel-wide) lines and
> polygons – so there is hope but I don’t believe (looking through the
> source) that Thomas ever fully implemented it. In mapagg.cpp there are
> ifdef’s for a symbol named AGG_ALIASED_ENABLED which makes me wonder if
> work was started. I tried setting that in mapagg.cpp but ran into
> compile errors and didn’t try and track those down.
> 
> 
> 
>   Of course you’d have to live with 1 pixel wide lines…
> 
> 
> 
>   Steve
> 
> 
> 
>   From: Erik H [mailto:erik.h11...@gmail.com]
>   Sent: Monday, October 16, 2017 1:15 PM
>   To: Lime, Steve D (MNIT) 
>   Cc: mapserver-users@lists.osgeo.org  us...@lists.osgeo.org>
>   Subject: Re: [mapserver-users] Draw roads WITHOUT anti-
> aliasing
> 
> 
> 
>   Thanks for your reply, but I should have mentioned that I
> have a LOT of different colors to be displayed, almost a million...
> 
> 
> 
>   I should also have mentioned that I've already tried to
> filter out the anti-aliased pixels by setting all alpha bytes to 255 and
> then assuming that all pixels that don't have alpha=255 in the PNG can
> be removed, but that assumption seems to be wrong.
> 
> 
> 
>   On Mon, Oct 16, 2017 at 2:00 PM, Lime, Steve D (MNIT)
>  wrote:
> 
>   Hmmm… I wonder if you just could use a pre-computed
> palette to control quantizing to 8 bits. You can supply a palette file
> (RGB or RGBA) and the MapServer will map 24/32-bit values to those in
> the palette. Format options are:
> 
> 
> 
>FORMATOPTION "PALETTE_FORCE=TRUE"
> 
>   FORMATOPTION "PALETTE=palette.txt"
> 
> 
> 
>   This will definitely limit the colors in your output
> image to those you specify. The question is whether or not the anti-
> aliased colors will map to the right color and that will depend on your
> palette. I did write a simple test with a 5 color palette (black, white,
> red, green and blue) and it seems to work ok but that’s a very simple
> palette… Based on your application it might work though.
> 
> 
> 
>   -  http://maps1.dnr.state.mn.us/cgi-
> bin/mapserv70?map=/usr/local/mapserver/apps/test/palette/test.map=m
> ap  bin/mapserv70?map=/usr/local/mapserver/apps/test/palette/test.map=m
> ap>  (24-bit)
> 
>   -  http://maps1.dnr.state.mn.us/cgi-
> bin/mapserv70?map=/usr/local/mapserver/apps/test/palette/test.map=m
> ap=png8  bin/mapserv70?map=/usr/local/mapserver/apps/test/palette/test.map=m
> ap=png8>  (8-bit w/5 colors)
> 
> 
> 
>   Steve
> 
> 
> 
>   From: mapserver-users [mailto:mapserver-users-
> boun...@lists.osgeo.org 
> ] On Behalf Of Erik H
>   Sent: Monday, October 16, 2017 10:58 AM
>   To: mapserver-users@lists.osgeo.org  us...@lists.osgeo.org>
>   Subject: [mapserver-users] Draw roads WITHOUT anti-
> aliasing
> 
> 
> 
>   I'm running a tiling server that uses MapServer 7.0.4
> to generate PNGs.
> 
> 
> 
>   My colleagues came up with an ingenious idea to animate
> traffic conditions that would require them to identify road segments
> based on their color. They asked me to generate tiles with a
> predetermined RGBA value per road segment.
> 
> 
> 
>   I configured a layer of type LINE, with a STYLE section
> containing 'COLOR [palette]' (palette being