[mapserver-users] enhancement ideas

[Tamas Szekeres]

Joan,

New ideas are welcomed since it's more incentive than dealing with
bugs any time ;-)
Most of the times the enhancements/requests are bound to specific
projects/demands so that the developers can easily put these efforts
into their timeline but it's quite difficult to pick up the task that
is out of the context of their existing work. From this aspect the
following options can normally be considered to invoke the new
suggestions:

1. Submit a ticket as an enhancement request and wait if someone gets
involved to implement it

2. Provide working implementations/patches/RFCs that could easily get
approved by the PSC

3. Contract with someone to implement these.

4. Add the wishes to the mapserver GSoC proposals
http://wiki.osgeo.org/wiki/MapServer_2008_SOC_Ideas perhaps some of
the students around here are willing to implement.


With regards to the suggestions I have the following notes:

>
> ** Expressions almost everywhere **
> Possibility to use expressions whenever a value is required.
> Built-in variables and functions would be very useful.
> For example:
>    SIZE [fieldValue]*0.2+5
>    WIDTH imageWidth / 200.0  # imageWidth is a built-in variable containing
> the map width in pixels
>    SIZE min(5, [fieldValue]/100) # minimum function
>    TEXT upperCase([fieldValue])  # get upper case value of a text field
>    TEXT if([fieldValue] = "-", "Yes", "No") # "if then else" expression
>    COLOR rampColor([fieldValue],0,10000)  # get a color in
> a ramp for a numeric field normalized to a range
>

You can currently use MapScript in various languages to provide the
run-time changes in the values in many places. However the run-time
replacements of the shapeObj parameters is a good example where we
cannot indeed utilize MapScript easily since all of the rendering code
is located inside the mapserver core. I guess this is one of the areas
where mapserver currently cannot provide enough support for the
customizations. The expressions you mentioned is only a small sub-area
where the customizations can take place. Actually instead implementing
a general (and may be quite inefficient) expression handler I would
rather support for the users to be able to write code plugins to
'transform' the features before the renderings for their specific
need. From this intent I've created MS-RFC-22
http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22a that couldn't
get enough support by this time, maybe nobody out there has too
sophisticated rendering problems that cannot be handled in other ways
(like placing those transformations to the database level would be
sufficient for example)

> ** Finer grained concurrency locks **
> Especially in OGR. Currently Mapscript (Java or .NET) is not an efficient
> option on a webserver accessing OGR: web requests are practically serialized
> by the locks.
> I think thread safety was improved in latest version of GDAL/OGR, am I
> wrong?
> Adopting RFC15 would be great news!
>

This is just another area where it's difficult to reach the consesus.
Currently most of the users using CGI/WxS related applications are not
really interested in solving these problems. Moreover solely within
the mapserver project is difficult to make the locks more 'fine
grained' so as to prevent from the concurrent accesses of the common
resources inside a dependent library. We can surely make some
enhancements according to RFC15 but the level of the thread isolation
can only really be addressed when all of the dependent libraries have
also been audited.


> **  Facilities for tiles **
> Given the big performance boost of using map tiles, I think it would be very
> useful an utility (or API) for pregenerating tiles of a map for a given area
> and level.
> I am aware of the existence of TileCache but I think it would be interesting
> to have this utility.
>

I think creating tiles / rendering based on the tiles are somewhat out
of the context of the mapserver project and can be impemented by an
outer project. There are a couple of projects that have already
implemented this.

> ** Multiple geometry types on a layer **
> Currently, a layer only admits one geometry type (point, line, polygon).
> Some sources, especially CAD datasets via OGR,
> contain different geometry types. Would be useful and efficient to have all
> geometries shown in the same layer.
> Different styling rules may be needed to display different geometry types in
> the same layer.
>

Generally speaking this would violate the concept around the layers as
grouping the features to be rendered in an unique way. And you can
currently subselect the various kind of the geometries into separate
layers (like using a filter based on the OGR_GEOMETRY field). In
addition you can use a data source controlled customization of the
styles within a same layer by using STYLEITEM AUTO when the data
source contains style information.

Do you have an use case where this isn't enough? Maybe the auto-style
support of RFC-22 could provide a solution.


Best regards,

Tamas