<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Hi Tamas,</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Some points to your kind notes:</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">> ... The expressions you mentioned is only a small sub-area where the<BR>> customizations can take place. Actually instead implementing <BR>> a general (and may be quite inefficient) expression handler I would <BR>> rather support for the users to be able to write code plugins to <BR>> 'transform' the features before the renderings for their specific <BR>> need. From this intent I've created MS-RFC-22. ...</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">I already have readen MS-RFC-22a and think it is a very flexible and powerful enhancement to Mapserver since adds transforming abilities. It can be seen analogous to applying XSLT to XML: is the next step towards flexibility. IMHO, it is really a pity that it is not getting enough support.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">That being said, I still see the need of a global built-in expression mechanism. In the case of writing plugins to transform features, still exists the need of evaluating generic expressions in these plugins: it would be a pain to write a specific transformers for every specific style or attribute transformation.<BR>Moreover, I still see the need to get values from the map environment. Think of displaying labels at 5% the size of map height: it could be easily get whith "SIZE mapHeight*0.05", where mapHeight is a built-in variable.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>> I think creating tiles / rendering based on the tiles are somewhat out <BR>> of the context of the mapserver project and can be impemented by an <BR>> outer project. There are a couple of projects that have already <BR>> implemented this. </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">I didn't know there already were projects with this functionality. Can you please tell me which ones are?</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>Best regards,</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Joan<BR><BR><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Mensaje original ----<BR>De: Tamas Szekeres <szekerest@gmail.com><BR>Para: Joan Verdaguer <verdaguerj@yahoo.es><BR>CC: mapserver-users@lists.osgeo.org<BR>Enviado: jueves, 6 de marzo, 2008 0:27:19<BR>Asunto: Re: [mapserver-users] enhancement ideas<BR><BR>Joan,<BR><BR>New ideas are welcomed since it's more incentive than dealing with<BR>bugs any time ;-)<BR>Most of the times the enhancements/requests are bound to specific<BR>projects/demands so that the developers can easily put these efforts<BR>into their timeline but it's quite difficult to pick up the task that<BR>is out of the context of their existing work. From this aspect the<BR>following options can normally be considered to invoke the new<BR>suggestions:<BR><BR>1. Submit a ticket as an enhancement request and wait if someone gets<BR>involved to implement it<BR><BR>2. Provide working
implementations/patches/RFCs that could easily get<BR>approved by the PSC<BR><BR>3. Contract with someone to implement these.<BR><BR>4. Add the wishes to the mapserver GSoC proposals<BR><A href="http://wiki.osgeo.org/wiki/MapServer_2008_SOC_Ideas" target=_blank>http://wiki.osgeo.org/wiki/MapServer_2008_SOC_Ideas</A> perhaps some of<BR>the students around here are willing to implement.<BR><BR><BR>With regards to the suggestions I have the following notes:<BR><BR>><BR>> ** Expressions almost everywhere **<BR>> Possibility to use expressions whenever a value is required.<BR>> Built-in variables and functions would be very useful.<BR>> For example:<BR>> SIZE [fieldValue]*0.2+5<BR>> WIDTH imageWidth / 200.0 # imageWidth is a built-in variable containing<BR>> the map width in pixels<BR>> SIZE min(5, [fieldValue]/100) # minimum function<BR>> TEXT
upperCase([fieldValue]) # get upper case value of a text field<BR>> TEXT if([fieldValue] = "-", "Yes", "No") # "if then else" expression<BR>> COLOR rampColor([fieldValue],0,10000) # get a color in<BR>> a ramp for a numeric field normalized to a range<BR>><BR><BR>You can currently use MapScript in various languages to provide the<BR>run-time changes in the values in many places. However the run-time<BR>replacements of the shapeObj parameters is a good example where we<BR>cannot indeed utilize MapScript easily since all of the rendering code<BR>is located inside the mapserver core. I guess this is one of the areas<BR>where mapserver currently cannot provide enough support for the<BR>customizations. The expressions you mentioned is only a small sub-area<BR>where the customizations can take place. Actually instead implementing<BR>a general (and may be quite inefficient) expression handler I would<BR>rather
support for the users to be able to write code plugins to<BR>'transform' the features before the renderings for their specific<BR>need. From this intent I've created MS-RFC-22<BR><A href="http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22a" target=_blank>http://mapserver.gis.umn.edu/development/rfc/ms-rfc-22a</A> that couldn't<BR>get enough support by this time, maybe nobody out there has too<BR>sophisticated rendering problems that cannot be handled in other ways<BR>(like placing those transformations to the database level would be<BR>sufficient for example)<BR><BR>> ** Finer grained concurrency locks **<BR>> Especially in OGR. Currently Mapscript (Java or .NET) is not an efficient<BR>> option on a webserver accessing OGR: web requests are practically serialized<BR>> by the locks.<BR>> I think thread safety was improved in latest version of GDAL/OGR, am I<BR>> wrong?<BR>> Adopting RFC15 would be great news!<BR>><BR><BR>This
is just another area where it's difficult to reach the consesus.<BR>Currently most of the users using CGI/WxS related applications are not<BR>really interested in solving these problems. Moreover solely within<BR>the mapserver project is difficult to make the locks more 'fine<BR>grained' so as to prevent from the concurrent accesses of the common<BR>resources inside a dependent library. We can surely make some<BR>enhancements according to RFC15 but the level of the thread isolation<BR>can only really be addressed when all of the dependent libraries have<BR>also been audited.<BR><BR><BR>> ** Facilities for tiles **<BR>> Given the big performance boost of using map tiles, I think it would be very<BR>> useful an utility (or API) for pregenerating tiles of a map for a given area<BR>> and level.<BR>> I am aware of the existence of TileCache but I think it would be interesting<BR>> to have this utility.<BR>><BR><BR>I think creating
tiles / rendering based on the tiles are somewhat out<BR>of the context of the mapserver project and can be impemented by an<BR>outer project. There are a couple of projects that have already<BR>implemented this.<BR><BR>> ** Multiple geometry types on a layer **<BR>> Currently, a layer only admits one geometry type (point, line, polygon).<BR>> Some sources, especially CAD datasets via OGR,<BR>> contain different geometry types. Would be useful and efficient to have all<BR>> geometries shown in the same layer.<BR>> Different styling rules may be needed to display different geometry types in<BR>> the same layer.<BR>><BR><BR>Generally speaking this would violate the concept around the layers as<BR>grouping the features to be rendered in an unique way. And you can<BR>currently subselect the various kind of the geometries into separate<BR>layers (like using a filter based on the OGR_GEOMETRY field). In<BR>addition you can use a data
source controlled customization of the<BR>styles within a same layer by using STYLEITEM AUTO when the data<BR>source contains style information.<BR><BR>Do you have an use case where this isn't enough? Maybe the auto-style<BR>support of RFC-22 could provide a solution.<BR><BR><BR>Best regards,<BR><BR>Tamas<BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1><br><font face="Verdana" size="-2">¿Con Mascota por primera vez? - Sé un mejor Amigo<br><a href="http://es.rd.yahoo.com/evt:51361/*http://es.answers.yahoo.com/dir/index;_ylc=X3oDMTE4ZWhyZjU0BF9TAzIxMTQ3MTQzMjIEc2VjA0Jhbm5lcgRzbGsDQWNxdWlzaXRpb24-?link=over&sid=XXXXXXXX">Entra en Yahoo! Respuestas</a>.<br></font> </body></html>