thomas bonfort wrote:
> it's possible in mapserver since version 6.2 :
> http://mapserver.org/development/rfc/ms-rfc-80.html . Note that
> there's a hardcoded limit of 4 fallbacks font (1 main font + 4
> fallbacks). In mapserver 7.0 this limit will be lifted, and it will
> also be possible to pr
Hello,
in Mapnik it is possible to use an alternate font if a character is not
available on the standard font:
With Openstreetmap Data it is often the case, that a given character is only
available in unifont but not in "DejaVu Sans Book" (the default).
If I correctly understand the doc
Avin Mohanza wrote:
> and why does my debian wheezy alway install mapserver 6.0.1?
Unfortunately there are no official debian or Ubuntu packages of newer
version. However, there is an inofficial repository of mapserver 6.2.1 at
http://git.linuxminded.nl/git/pkg-grass/mapserver
A package build f
Rahkonen Jukka wrote:
> I encourage you to have a try with GDAL 1.10 because I believe that
> for your use case Spatialite will be considerable faster than
> PostGIS.
Thanks! It seems to work fine using gdal 1.10 now and seems to be
slightly faster that using postgis.
> If you can tolerate Win
Rahkonen Jukka wrote:
> GDAL has been supporting Spatialite spatial index since
> http://trac.osgeo.org/gdal/ticket/4212 Some further work was done in
> http://trac.osgeo.org/gdal/ticket/4508 I am remembering from my own
> experience that a query like the one you are using needs GDAL 1.10 but
> w
Hello,
I have the following entry in a layer which I would like to convert from psql
backend
to spatialite:
CONNECTIONTYPE POSTGIS
CONNECTION "dbname=..."
DATA "geom from (select geom,id,height from contours where height%200=0) as foo
using unique id using srid=900913"
I tried the following:
C
Stephen Woodbridge wrote:
> What version are you using?
Have been using some git trunk back from may because of the GAMMA Option I
needed for Ocean Polygons.
> have you tried this with the 6.2-beta?
Just updated to latest trunk to check if the problem still exists and
unfortunately it does.
T
Stephen Woodbridge wrote:
> set the RESOLUTION to an appropriate value for your PDF.
This does not work for PDF. Regardless of the RESOLUTION in the Mapfile the
generated PDF Files are always generated with 72 DPI.
Same with SVG BTW. Looks like all cairo output is affected. Should I report
this
thomas bonfort wrote:
> The pdf is problably generated at 72 dpi, i.e. approx 28 pixels/cm
Hm, this is certainly not what I want.
To generate PDF for printing (not viewing on the screen) something
like 300dpi or 600dpi would be the target resolution.
Any way to specify dpi in addition to pice
thomas bonfort wrote:
> The pdf is problably generated at 72 dpi, i.e. approx 28 pixels/cm
>
> 1000 pixels / (28 pixels/cm) = 35.71 cm, i.e. with rounding occuring
> close to your 352 mm.
Would'nt it be more accurate to generate the PDF according to the RESOLUTION
parameter?
Sven
--
"If you
Hello,
for PDF generation I would usually like to output Data in Papersizes (A3,
A4, ...) but in shp2img or CGI Interface I can only specify pixels.
How does this size correspond to the size shown in acrobat reader?
If I take 1000 Pixels this will result in 352.8mm
Where does this factor of 2.8
Matt McClelland wrote:
> What would be really nice is a script that can 'tweak' DEM based on map
> data. something that changes the DEM to ensure contours follow shorelines,
> and that the bottom of a valley follows creeks. But I just dream of such a
> tool.
Sound complicated, but clipping mig
Hello,
I have a mapfile which contains amongst other a labeled contour layer.
However these are not very acurate because they are derived from
SRTM. For this reason I render the ocean polygon layer above the contour
layer.
This works fine for the contours but does not seem to work for the
contour
Sven Geggus wrote:
> OK YFTR:
>
> Rendering water from Overlapping polygons does work fine in mapserver
> 6.0.x using the "APPROXIMATION_SCALE=FULL" PROCESSING directive.
>
> "FORMATOPTION GAMMA=0.7" does not seem to be needed but won't be
> avai
Sven Geggus wrote:
> Hm. Looking at the sources 6.0.1 seems to be recent enough, but
> unfortunately this does not seem to fix the problem.
OK YFTR:
Rendering water from Overlapping polygons does work fine in mapserver
6.0.x using the "APPROXIMATION_SCALE=FULL" PROC
thomas bonfort wrote:
> you can fiddle with gamma correction in mapserver trunk, c.f.
>
> https://twitter.com/#!/tbonfort/status/93284998249066496
>
> OUTPUTFORMAT
> DRIVER AGG/PNG
> ...
> FORMATOPTION "GAMMA=0.7" #valid from 0 to 1
> END
hm, did you change something else in this area since V
"Lime, Steve D (DNR)" wrote:
> Do outlines fix things at all zoom levels?
Not really. The Workaround which is working best for now is using a very big
polygon Overlap of 100Meters (Talking about Google Mercator here) which I
feel is way to much and an outline with of 1. To completely get rid of
"Lime, Steve D (DNR)" wrote:
> I tried locally and it's definitely a rendering artifact related to
> anti-aliasing.
The artifact is getting worse in lower zoom levels (smaller islands).
I just tried a huge overlap of the polygons which made it better but
did not make it disapear also. So the
thomas bonfort wrote:
> with a recentish version of mapserver, try setting
> PROCESSING "APPROXIMATION_SCALE=FULL"
> on your ocean layer, to avoid feature simplification (it will slow
> down the rendering if the resolution of your data is much greater than
> the resolution of the requested map).
Hello,
the brilliant osm coastline tool from Jochen Topf
(http://blog.jochentopf.com/2012-04-19-more-coastlines-stuff.html)
enables for creating nice ocean or landcover polygons from
Openstreetmap data. Well, this is where my mapserver problem
starts...
For illustration of the problem I just cre
Hello,
I'm trying to render a spatialite layer.
The spatialite file itself seems to be correct, because it can be
viewed in qgis and can be dumped using ogrinfo:
$ogrinfo /home/sven/osm/topo/ocean.sqlite polygons -summary
INFO: Open of `ocean.sqlite'
using driver `SQLite' successful.
Laye
Paul Ramsey wrote:
> It actually worked when I tested against gmaps and virtual earth some
> moons ago. It's possible what osm means by '14' and what the others
> mean by '14' is different. You can different numbers depending on
> whether you start counting from zero and whether your top zoom lev
Starting from a mapserver setup which works fine in WMS Mode I tried to
access the same machine with mode=tile.
Unfortunately it looks like something is wrong with the zoom factor.
Position seems to be fairly correct however:
Just compare the following URLs:
http://a.tile.openstreetmap.org/14/85
Hi there,
looks like I got bitten by some mapscript bug, because I am unable to produce
24-bit png output via mapscript from my raster layers. I always get 8-bit
rasters :(
Despite the bug, I need a workaround for this as 8-bit rasters are
insufficient for my purpose.
Here is what my current tes
Hi there,
looks like I got bitten by some mapscript bug, because I am unable to produce
24-bit png output via mapscript from my raster layers. I always get 8-bit
rasters :(
Despite the bug, I need a workaround for this as 8-bit rasters are
insufficient for my purpose.
Here is what my current tes
25 matches
Mail list logo
