Re: [mapserver-users] Class maxscaledenom performance

[pe_lord]

It is precisely what I expect. 

The solution is to use scaletoken.

As proposed on  Github RFC86
  , I think it should be
documented into the layer description section:
http://www.mapserver.org/mapfile/layer.html

Pierre



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Class-maxscaledenom-performance-tp5322521p5322827.html
Sent from the Mapserver - User mailing list archive at Nabble.com.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Reprojection error for CONNECTIONTYPE WMS

[Simon.Schneegans]

Hi there!

I tested some more and it seems that this is not only a problem for WMS layers, 
but for Raster layers as well. Here is an example GeoTiff:
https://github.com/mapserver/mapserver/files/1047153/test.zip

I can warp this to HEALPix using GDAL on the command line:
gdalwarp -t_srs '+proj=healpix +a=1 +b=1 +wktext' -te -0.5 0.6 0.5 1  test.tiff 
healpix.tiff

The result looks as supposed (see example in the original issue: 
https://github.com/mapserver/mapserver/issues/5437).
However, if I let mapserver do the reprojection, the result is distorted (e.g. 
Libya is missing on the map). This is my layer (except for some metadata):

LAYER
name "test"
status ON
type RASTER
data "test.tiff"

PROJECTION
AUTO
END
END

This is in my epsg file:

<900916> +proj=healpix +a=1 +b=1 <>

This is the relevant part of the WMS request:

...=test=600=300=EPSG:900916=-0.5,0.6,0.5,1

The example test.tiff I linked above covers exactly the area I am requesting to 
be reprojected to HEALPix. As soon as this input tiff is larger, the 
reprojection works as supposed. I guess that this is the reason why I observed 
the issue with CONNECTIONTYPE WMS first: Here the input data is usually exactly 
as large as required by the reprojection!

Where do I have to go bug hunting? Is it a configuration issue? Is it a 
reprojection issue specific to HEALPix?

Thank you for your support!
Simon



Von: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] Im 
Auftrag von simon.schneeg...@dlr.de
Gesendet: Dienstag, 30. Mai 2017 13:17
An: mapserver-users@lists.osgeo.org
Betreff: [mapserver-users] Reprojection error for CONNECTIONTYPE WMS

Hi there!

I am happily using mapserver to reproject raster data  to the HEALPix 
projection from proj.4. This works 
pretty well for local raster sources, however I get severe reprojection 
problems when using an external WMS as source for my layer.

I reported this issue on Github 
(https://github.com/mapserver/mapserver/issues/5437) but was told to ask here 
for assistance. Instead of copy-pasting the text from the Github issue to this 
mail, I kindly ask you to refer to this Github issue for further information; 
there I also included several images illustrating the problem.

I am looking forward to get any feedback or input that helps me solving this 
issue!

Thank you very much!
Simon

--
Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Simulation and Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Simon Schneegans, M. Sc.
Telephone +49 531 295-2333 | Telefax +49 531 295-12100  | 
simon.schneeg...@dlr.de
DLR.de

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

Re: [mapserver-users] Class maxscaledenom performance

[Eichner, Andreas - SID]

What about http://mapserver.org/development/rfc/ms-rfc-86.html ?


> -Ursprüngliche Nachricht-
> Von: mapserver-users [mailto:mapserver-users-boun...@lists.osgeo.org] Im
> Auftrag von pe_lord
> Gesendet: Donnerstag, 1. Juni 2017 19:26
> An: mapserver-users@lists.osgeo.org
> Betreff: Re: [mapserver-users] Class maxscaledenom performance
> 
> I've verified if the issue was not linked to WMS. shp2img succeed to
> produce
> the png. But it's quite long.
> 
> I have tried at
> *1:102 000 *
> PGIS Query = 4 sec
> Nb of recors = 2859 records
> Mapserver render by WMS = 2.5 sec
> Mapserver render by shp2img =  shp2img total time: 3.677s
> 
> select
> "classitem_field",encode(ST_AsBinary(ST_Force2D("the_geom"),'NDR'),'hex'
> ) as
> geom,"ogc_fid" from ori_pee
> where the_geom && ST_GeomFromText('POLYGON((-8871026
> 6114309.70958512,-8871026 6140241.29041488,-8834701
> 6140241.29041488,-8834701 6114309.70958512,-8871026
> 6114309.70958512))',3857)
> 
> 
> *1:1 002 000*
> PGIS Query = 26 minutes
> Nb of records = 242832 records
> Mapserver render by WMS = "internal server error" = timout
> Mapserver render by shp2img =  shp2img total time: 156.299s
> 
> select
> "classitem_field",encode(ST_AsBinary(ST_Force2D("the_geom"),'NDR'),'hex'
> ) as
> geom,"ogc_fid" from ori_pee
> where the_geom && ST_GeomFromText('POLYGON((-9031284
> 504.71459227,-9031284 6254645.28540772,-8674443
> 6254645.28540772,-8674443 504.71459227,-9031284
> 504.71459227))',3857)
> 
> Here my validations
> 1-My layer have EXTENT
> 2-Mapserver do not reproject data
> 3-My layer has no label
> 4-Myconnection on postgis "DEFER"
> 5-My table have no OIDS
> 6-My table have GIST index on the_geom field
> 7-My table have a btree index on classitem field.
> 8-No warning in my GetCapabilities
> 
> 
> I have tried loading a new table with OIDS set to TRUE (on table, not on
> database)  and it's seem to be the same behavior? Do I really need to
> modify
> postgresql.conf?
> 
> 
> 
> When I read the query called from mapserver, I think there is a way to
> improve performance on maxscaledenom. Do you think there is a way for
> mapserver to know which class to render at current scale (based on bbox
> )
> and filter on them ...
> 
> the query might look like this:
> select
> "classitem_field",encode(ST_AsBinary(ST_Force2D("the_geom"),'NDR'),'hex'
> ) as
> geom,"ogc_fid" from ori_pee
> where the_geom && ST_GeomFromText('POLYGON((-9031284
> 504.71459227,-9031284 6254645.28540772,-8674443
> 6254645.28540772,-8674443 504.71459227,-9031284
> 504.71459227))',3857) and classitem_field = 'BBOX'
> 
> I think I will work on union layers :) .
> 
> 
> 
> 
> 
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/Class-
> maxscaledenom-performance-tp5322521p5322693.html
> Sent from the Mapserver - User mailing list archive at Nabble.com.
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] OpenGL on Linux (Debian/Ubunu)

[Even Rouault]

On vendredi 2 juin 2017 05:57:25 CEST Schepers, Benjamin wrote:
> Hi Daniel,
> 
> thanks for your advice - I've done exactly the same way you as you described
> it for some years now (doing the painful "average"-resampling due to
> preprocessing the overviews with GDAL and nesrest in WMS-postprocessing).
> The servers and services are "highly optimized" and generally fast - thanks
> to GDAL's and mapserver's functionality and performance and community
> hints. But I wasn't really satisfied with final image-quality, because of
> the trade-of between performance and image-quality on WMS-postprocessing -
> I decided for performance.
 
> From my point of view it still makes a difference in image quality, whether
> I use nearest or average on WMS-postprocessing, especially the
> aliasing-effects on edges of buildings, bridges, etc. would be nearly
> totally eliminated with "average"postprocessing , I did some tests!
 
> My guess was, that resampling could be done much better by the GPU (having a
> look in the world of gaming, where some "super-mega-ultra-antialiasing" is
> done with more than 100 frames per seconds in highest resolutions.

Before going to the GPU, I would look if the MapServer resampling code couldn't 
already be 
optimized on the CPU. There's likely room for improvements.

 > Now there is an option to get some new servers with integrated GPUs (Nvidia
> GTX1080) and asked myself (and now the community ;-) ) whether it would
> make sense  to exercise that option...

What is not obvious performance wise is that you would need to transfer buffers 
back and 
forth between the CPU and GPU.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users