All,
Wild thought here . . .
I'm wondering about how to approach the need to add a map inset to a MapServer
call. I know I can make separate calls and stack some maps on top of each
other, but I'm wondering now about using a TRANSFORM of coordinates to put a
Map Inset window into a Mapserver
Travis,
I think MapServer is just going to lookup 2958 in the PROJ.4 epsg init
file. So it may well be sufficient to update the entry to refer to the
grid shift file.
Something like changing this:
# NAD83(CSRS) / UTM zone 17N
<2958> +proj=utm +zone=17 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
If anybody interested, I have published my simple web based mapfile
viewer tool, which I use to develop and visualize MapServer layers.
Mapfile viewer is a Python script which starts standalone WSGI server
which provides OpenLayers-based map v
DATA "the_geom from (select * from get_aerosol_data('gas_db', 25.5,
'2005-3-2 00:00', '2006-3-5 00:00') ) as foo using unique gid using
srid=4326"
Here is a link that might help:
http://mapserver.org/input/vector/postgis.html
-Steve W
On 12/13/2012 3:24 PM, Lime, Steve D (DNR) wrote:
I be
I believe anything you can stuff in a DATA statement using SQL is legitimate.
From: mapserver-users-boun...@lists.osgeo.org
[mapserver-users-boun...@lists.osgeo.org] on behalf of Heiko Schröter
[schro...@iup.physik.uni-bremen.de]
Sent: Tuesday, December
I have issue with my WMS service when using a source raster layer that is
in EPSG:2958 - NAD83(CSRS) / UTM zone 17N srs. The issue is that Mapserrver
(proj) does not apply a gridshift when requesting the layer in a different
projection - UTM z17n NAD83. I have a gridshift file for this
transformat
Label expressions might turn out to be useful here. Just thinking out loud... I
mean we might be able to extend things and define expressions where you can
write tests like the intersecting a label bbox against the parent shape.
Expressions with multiple labels work like classes and are executed
Hi,
We have found that version 2.4.10 of Freetype causes text through
MapServer to render differently (and not as nicely) as v2.3.9 of Freetype.
Whilst we have got round this issue by reverting to the earlier version
of Freetype, we are concerned that this may cause issues in the future
if t
