[mapserver-users] mapscript.imageObj(): is severely broken and should not be used after upgrade from 6.0.1 to 6.2.1/6.4.0
Hello, with the upate from ubuntu 13.04 to 13.10 the package python-mapscript moved from 6.0.1 to 6.2.1. Since then I get the the following runtime error: img = mapscript.imageObj(fname) File /usr/lib/python2.7/dist-packages/mapscript.py, line 1324, in __init__ this = _mapscript.new_imageObj(*args) MapServerError: imageObj(): Image handling error. imageObj() is severely broken and should not be used The mapscript API suggests that mapscript.imageObj could be used normally. So I added the ubuntugis-unstable repository and updated python-mapscript to 6.4.0, but the error stays. I didn't find anything usefull searching the internet for this error message, so I wonder whether imageObj is really broken or whether the error is caused by something else? I'm not busy with mapscript, I have to maintain the program where mapscript is part of. Can I use another function instead mapscript.imageObj which gives me back an image object? The function where mapscript.imageObj(fname) is invocated is as follows: def load_custom_symbols(self): lst_symbols = [ os.path.splitext(x) for x in os.listdir(os.path.join(os.getcwd(), _symbols)) ] for symbol, ext in lst_symbols: if ext == .png: fname = os.path.join(os.getcwd(), _symbols, .join([symbol, ext])) symbol = mapscript.symbolObj(symbol) img = mapscript.imageObj(fname) symbol.type = mapscript.MS_SYMBOL_PIXMAP symbol.setImage(img) self.map.symbolset.appendSymbol(symbol) Thanks! Tim ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] XML parsing error with extended Inspire WMS 1.1.1 capabilities
I get this error: Namespace prefix xsi for type on MandatoryKeyword is not defined You're right. The problem using DTD is that namespace declarations are done using FIXED attributes. Therefore the DTD part !ATTLIST inspire_common:MandatoryKeyword xmlns:inspire_common CDATA #FIXED http://inspire.ec.europa.eu/schemas/common/1.0; Should be: !ATTLIST inspire_common:MandatoryKeyword xmlns:inspire_common CDATA #FIXED http://inspire.ec.europa.eu/schemas/common/1.0; xmlns:xsi CDATA #FIXED http://www.w3.org/2001/XMLSchemainstance; Because for element inspire_common:Keyword the xsi:type attribute is declared it should probably also be done for the inspire_common:MandatoryKeyword. So I would consider this being an incomplete document type definition. Fixing this should be simple. HTH ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] [mapserver-dev] RFC-108 : heatmap generation
Hi Jukka, Thanks for the comments, which I mostly agree with. I should clearly remove references to the the term of interpolation as it does not apply to the proposed solution. Concerning the heatmap term that should be replaced by kernel density that could be a possibility, although as you said the heatmap term has become so common that I'd suspect many users wouldn't give a kernel density solution a look even if that is what they are after. I'll rework the RFC to suppress the interpolation references, and use a connectiontype density, would that work for you? I am not sure if this image generator can even make such heatmaps like the salinity map in the beginning of RFC where missing data between the measuring points are (linearly?) interpolated. In that map the density of salinity measurement stations has no effect on the colour. Also in real life even if you measure a hundred times a temperature of +40 degrees from very close measuring points, the maximum temperature does not rise a bit over +40. correct, the proposed solution will be biased by samples close to one another. The system itself is welcome and I am interested in seeing how the problem of creating automatically a good looking visualization for changing map scales is solved. Perhaps output pixel based interpolation radius and PROCESSING “NORMALIZATION=AUTO will handle that. I'm not sure I understand what you're looking for here, can you be a bit more precise? -- thomas -Jukka Rahkonen- Thomas Bonfort wrote: Devs, please have a look at RFC-108 [1]. The associated code and the RFC are still beta, so there's still plenty of room for modification or remarks. best regards, thomas [1] http://mapserver.org/development/rfc/ms-rfc-108.html ___ mapserver-dev mailing list mapserver-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev ___ mapserver-dev mailing list mapserver-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] WMS display of NODATA pixels
Hi group, I am having a heck of a time figuring out how to have MapServer ignore NODATA values in a WMS. Please help! ***THE DATA GDAL shows the NODATA value of this TIFF to be -999: C:\WorkSpace\medem2gdalinfo mosaic100.tif snip NoData Value=-999 I also confirmed this in ArcGIS, the NoData pixels do not draw. The raster is a 32-bit float (a DEM). ***THE MAPFILE I have tried the following, which the docs all indicate should work: PROCESSING NODATA=-999 (nodata pixels show as black) PROCESSING SCALE=-3,950 (again nodata pixels -999 show as black, it does scale the rest of the data) CLASS EXPRESSION ([pixel] -999) (whole image is white) END PROCESSING LUT=0:0,100:128,500:192,951:255 (nodata pixels show black, it does apply the LUT correctly otherwise) ***CHECK IT OUT You can see this for yourself if you like, use this WMS: http://mapserver.maine.gov/wms/mapserv.exe?map=c:/wms/topos.map; Choose the Maine_DEM_2m group === Michael Smith MS GISP State GIS Manager, Maine Office of GIS State of Maine, Office of Information Technology michael.smith _at_ maine.gov 207-215-5530 Board Member, Maine GeoLibrary Education Chair, Maine GIS Users Group State Rep, National States Geographic Information Council [cid:image001.jpg@01CF1E9E.2C978FB0] State House Station 145 51 Commerce Drive Augusta, ME 04333-0145 69o 47' 58.9W 44o 21' 54.8N inline: image001.jpg___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] [mapserver-dev] RFC-108 : heatmap generation
Thomas Bonfort wrote: Hi Jukka, Thanks for the comments, which I mostly agree with. I should clearly remove references to the the term of interpolation as it does not apply to the proposed solution. Concerning the heatmap term that should be replaced by kernel density that could be a possibility, although as you said the heatmap term has become so common that I'd suspect many users wouldn't give a kernel density solution a look even if that is what they are after. I'll rework the RFC to suppress the interpolation references, and use a connectiontype density, would that work for you? Everybody calls them as heatmaps so let it be so but make a difference between density and interpolation. Connectiontype interpolation can be reserved for the future. I am not sure if this image generator can even make such heatmaps like the salinity map in the beginning of RFC where missing data between the measuring points are (linearly?) interpolated. In that map the density of salinity measurement stations has no effect on the colour. Also in real life even if you measure a hundred times a temperature of +40 degrees from very close measuring points, the maximum temperature does not rise a bit over +40. correct, the proposed solution will be biased by samples close to one another. The system itself is welcome and I am interested in seeing how the problem of creating automatically a good looking visualization for changing map scales is solved. Perhaps output pixel based interpolation radius and PROCESSING “NORMALIZATION=AUTO will handle that. I'm not sure I understand what you're looking for here, can you be a bit more precise? I tried to say that same settings for radius and colorrange tend to work well only for a limited scale range. Here are two examples which are using the same traffic accidend data. http://www.hs.fi/kotimaa/Nettisivusto+paljastaa+Helsingin+vaarallisimmat+risteykset/a1305551700052 This one overrates accidents at small scale and burns everything red. When you zoom in the accidents almost disappear and the hotspots are lost. http://cloudnsci.fi/wiki/demos/traffic_accidents_in_Helsinki_heatmap.html This one is static and looks good at medium scales but does not work well at big and small scales. I feel that the search radius and colorrange should be adjusted somehow by the scale but I can't suggest how. But perhaps it can be done rather easily with a few scale dependent classes. -Jukka Rahkonen- -- thomas -Jukka Rahkonen- Thomas Bonfort wrote: Devs, please have a look at RFC-108 [1]. The associated code and the RFC are still beta, so there's still plenty of room for modification or remarks. best regards, thomas [1] http://mapserver.org/development/rfc/ms-rfc-108.html ___ mapserver-dev mailing list mapserver-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev ___ mapserver-dev mailing list mapserver-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev ___ 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] How to make tilecache to mapcache?
Hi, Has anyone moved a existing cache of tiles from tilecache to mapcache? I'm assuming that basically the tiles can be renamed and moved into a new directory tree structure. Does anyone have a script that does this? Or maybe there is a way to configure the mapcache.xml so that it can just work with the existing directory structure? How? Thanks, -Steve ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
