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 _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users