Small correction of maptemplate.c to be able to use the shpxy when the geometry is a MULTIPOLYGON

[tbonfort]

Reporter: djay Date: 2007/04/24 - 16:15 I try to generate an imagemap from mapserver using a template which contain this line :

<area shape="polygon" coords="[shpxy precision=0 proj=image] " href="#?[gid]" title="[nom]" alt="[nom]" onmouseover="imagemap.displayData.bindWithArg(imagemap,'[gid]',this.title,'[value]',this)();" onmouseout="imagemap.hideData()" style="border: 1px #eee solid;background-color: #aaa;" />

I made my mapfile and then I use this command to generate my static imagemap : wget -O /path/to/imagemap/imagemap.xml "http://127.0.0.1/cgi-bin/mapserv-4.10.1?map=/path/to/mapfiles/stat_imagemap_com.map&qlayer=clr&mode=nquery&searchmap=true

When I load the imagemap and the image generated I have a warning message in the firefox console about the fact that there are some error in the imagemap and more precisely the last coordinate of some area are not available.

So I've check the imagemap generated by the mapserv cgi program and I see that sometime, there are component with 3 coordinates, which sounds prety strange. Then I've checked all the imagemaps I've generate with the command line coted before, so I use this command : grep "[1-9],[1-9],[1-9]*" -rni /path/to/imagemap to detect wrong imagemaps.

I check my PostGIS MULTIPOLYGON using the summary function to see that everytime a MULTIPOLYGON have more than only one nested POLYGON then the corresponding area have a three coordinate "POINT". Furthermore, in case there are only two POLYGON in the MULTIPOLYGON, I see that this "POINT" is the concatenation of the last POINT of the first POLYGON and the first POINT of the last POLYGON. So I've correct the imagemap generated by hand even if this solution was not acceptable from my point of view, so I've decided to check the source code to see if I could quickly correct this strange behavior.

For the test I've made I have to use a geometry object which is a MULTIPOLYGON. In the ms-rfc-2.txt file there is a note about the fact that MULTIPOLYGON are translated into POLYGON, so I was unable to find any method to solve this problem only in the case that the geometry is a MULTIPOLYGON. So I've choosen to find a solution which could work in each case and don't break anything.

In fact even if my explanation it's (maybe too) long, the correction is quite simple and here it is :

• the only things to change are in the maptemplate.c file :
  • the line 1144 should be (to avoid a possible buffer overflow) :
  • pointFormatLength = strlen("xh") + strlen("xf") + strlen("yh") + strlen("yf") + strlen("cs") + 10 + 2;
  • rather than
  • pointFormatLength = strlen("xh") + strlen("xf") + strlen("yh") + strlen("yf") + strlen("cs") + 10 + 1;
  • the line 1148 should be ;
  • snprintf(pointFormat2, pointFormatLength, "%s%%.%dlf%s%s%%.%dlf%s ", xh, precision, xf, yh, precision, yf);
  • rather than ;
  • snprintf(pointFormat2, pointFormatLength, "%s%%.%dlf%s%s%%.%dlf%s", xh, precision, xf, yh, precision, yf);

Well that's all in fact.

I regenerate the imagemaps and now it works like charm.

Please forgive my realy poor english level .. :] And don't hesitate to tell me if I've made or say anything wrong.

Thanks in advance.

[tbonfort]

Author: warmerdam Date: 2007/04/24 - 20:34 djay,

The change looks ok to me, and I've applied it in 5.0 (dev) and in the 4.10 stable branch.

Steve,

I've added you as a cc: so you can skim the above changes before I close this report. The key thing is adding a space between linestrings/rings. The pointFormat2 format statement has a (nearly invisible!) space added at the end in place of the "cs" value used between coordinates of a given ring. Does this make sense to you? I'm really not too clear on all the places that this template capability is used, and I'd hate to break anything.

[tbonfort]

Author: sdlime Date: 2007/04/25 - 05:30 Replying to [comment:1 warmerdam]:

djay,

The change looks ok to me, and I've applied it in 5.0 (dev) and in the 4.10 stable branch.

Steve,

I've added you as a cc: so you can skim the above changes before I close this report. The key thing is adding a space between linestrings/rings. The pointFormat2 format statement has a (nearly invisible!) space added at the end in place of the "cs" value used between coordinates of a given ring. Does this make sense to you? I'm really not too clear on all the places that this template capability is used, and I'd hate to break anything.

I think the change is ok. The point of having all the seperators is to have total control so that space is extra (I think). Go ahead and apply in CVS HEAD and I'll check some imagemaps I have and then we can back port.

Steve

[tbonfort]

Author: sdlime Date: 2007/04/25 - 05:31 Replying to [comment:2 sdlime]:

I think the change is ok. The point of having all the seperators is to have total control so that space is extra (I think). Go ahead and apply in CVS HEAD and I'll check some imagemaps I have and then we can back port.

Steve

Oh, I see it's already there, cool. Will try tomorrow...

Steve

[tbonfort]

Author: sdlime Date: 2007/04/25 - 05:35 Replying to [comment:3 sdlime]:

Oh, I see it's already there, cool. Will try tomorrow...

Steve

Actually looking at CVS head right now and the space is still there (pointFormat2)?

[tbonfort]

Author: djay Date: 2007/04/25 - 13:52 Maybe this [http://trac.osgeo.org/mapserver/attachment/ticket/2073/maptemplate.patch patch](tested with mapserver-4.10.0) should be a beter solution cause it only add a space separator if there are still geometry components to treat ...

[tbonfort]

Author: warmerdam Date: 2007/04/25 - 15:34 Steve,

The change was to add the space between linestrings/rings so the numbers don't run together. Let me know if djay's extra patch, or another change should be applied, or of course feel free to apply yourself.

[tbonfort]

Author: sdlime Date: 2007/04/25 - 15:58 Replying to [comment:6 warmerdam]:

Steve,

The change was to add the space between linestrings/rings so the numbers don't run together. Let me know if djay's extra patch, or another change should be applied, or of course feel free to apply yourself.

Argh... It was late and I had my head up my... Anyway, now I don't think any patch is necessary. There are tag arguments to control part headers (ph), footers (pf) and seperators (ps) and by default they are empty strings. djay, if you take out any of your code and add ps=" " to your shpxy tag does it output correctly? Could change the default part seperator to a space as well.

I'll take this bug...

Steve

[tbonfort]

Author: djay Date: 2007/04/26 - 11:34 Replying to [comment:7 sdlime]:

There are tag arguments to control part headers (ph), footers (pf) and seperators (ps) and by default they are empty strings. djay, if you take out any of your code and add ps=" " to your shpxy tag does it output correctly? Could change the default part seperator to a space as well.

I'll take this bug...

Steve

Hi Steve, please forgive me, indeed you're right, on line 1226 of maptemplace.c file there is the appending call using ps. So using ps=" " in the template solve the problem.

Nevertheless I would like to know if it's not the behavior that Mapserver should have by default (having ps=" " rather than ps="") ?

Indeed, what is the beter solution between :

• user must take care about how many components his "multigeom" have and fix pf in his template (only if his "multigeom" have more than one component),
• Mapserver handle templating in a way that solve this kind of problem automaticaly (each "geom" in a "multigeom" are space separated) ?

Personnaly I prefer the last one. Furthermore, as it is handle in the code, the ps is appended if and only if there are another component in the “multigeom", so we could be sure about the fact that having ps=" " by default doesn't break anything.

So has you tell, I think that it could be a good thing to change the default separator in the code.

Please, tell me what you thinking about this point of view and what will be done in the futur mapserver versions.

[tbonfort]

Author: sdlime Date: 2007/04/27 - 06:21 Replying to [comment:8 djay]: Hey, not a problem. I probably didn't set a default as a space because wasn't sure if browsers could handle multipart features and was too lazy to check. Originally the [shpxy...] tag was written to output SVG. Anyway, I can live with a space default between parts and will make that change to 4.10 and CVS head.

Steve