The angle follow with offset trigger an error when the box clip create a multiline

[aperi2007]

Using a Mapserver trunk, with gdal 1.10 and geos 3.3.8:

I notice that on a Line dataset, when the box of the map will clip a linestring creating a virtual multilinestring geometry the map is not create.

After some test the reuslt is that will happen when there is a Label with settings:
Angle Follow and offset.

And this happen with the data repository accessed using a gdal/ogr driver.
This happen with shapefile accessed using ogr driver and also with spatialite with ogr driver.
It don't happend using a shapefile accessed with mapserver native driver or using a inline dataset (also if of kind multilinestring).

I prepare a simple package with a test mapfile and a little spatialite db.

The test mapfile has a inline multilinestring that is always working.
Instead the spatialite accessed using ogr driver, when the line in it is clipped in the screen portion (creating a virtual multilinestring) the map is not create.

[aperi2007]

Sorry, but I don't know how to add a zip file to an issue.

[aperi2007]

I create an url from where the package is downloadable.

http://tinyurl.com/qgj4p86

Regards,

Andrea.

[tbonfort]

@aperi2007 please provide an extent which triggers your problem, using EXTENT 1660351.00 4458445.22 1866743.13 4960849.91 works for me

[aperi2007]

Hi,

this is a call with extent on the same dataset and mapfile that fail for me.

http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=1660312.16974842036142945,4857262.71393941808491945,1668231.6821577069349587,4860105.77443558908998966&CRS=EPSG:3003&WIDTH=945&HEIGHT=339&LAYERS=line-sl&STYLES=&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE

The extent is:
1660312.16974842036142945,4857262.71393941808491945,1668231.6821577069349587,4860105.77443558908998966

Instead this is a work call for me:
http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmstest&&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=1660312.16974842036142945,4857262.71393941808491945,1668231.6821577069349587,4861044.9888612562790513&CRS=EPSG:3003&WIDTH=945&HEIGHT=450&LAYERS=line-sl&STYLES=&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE

The work extent is this:
1660312.16974842036142945,4857262.71393941808491945,1668231.6821577069349587,4861044.9888612562790513

Thx,

Andrea.

[tbonfort]

@sdlime @dmorissette I need your help here.
What's happening is that the call to GEOSOffsetCurve is failing here https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/mapgeos.c#L699 , and returning a NULL geometry. While this is something that could/should be looked in further to prevent it from happening, the implications of this failure are more widespread. The mapserver line offseter detects this failure and we go through our own line offseter : https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/maputil.c#L1756
However, the OGR driver seems to be picking up this error in https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/mapogr.cpp#L1564 when the last feature has been returned, instead of returning MS_DONE. This is why we're obtaining a strange error message

msOGRFileNextShape(): OGR error. IllegalArgumentException: BufferBuilder::bufferLineSingleSided only accept linestrings <br>

which is a GEOS error message wrapped in an OGR error code.

any insight as to why this is happening would be appreciated!

[rouault]

Hum, I suspect that the GEOS error handlers installed by MapServer in https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/mapgeos.c#L58 are overridden by the GEOS error handlers installed by OGR in https://github.com/OSGeo/gdal/blob/trunk/gdal/ogr/ogrgeometry.cpp#L1935 . Which explains why the GEOS error triggered by https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/mapgeos.c#L699 ends up being reported as a OGR error ...

Quick workaround : issue CPLErrorReset() just before https://github.com/mapserver/mapserver/blob/rel-6-4-0-beta1/mapogr.cpp#L1562 , so that previous CPL errors don't contaminate further...

More cleaner approach : use the session oriented API or GEOS to install the error handlers : http://trac.osgeo.org/geos/browser/trunk/capi/geos_c.h.in#L169 and use all the _r suffixed functions instead of the global ones. It seems that the _r functions have been introduced in GEOS 3.1.0 ( http://trac.osgeo.org/geos/ticket/210 confirmed by their presence in http://trac.osgeo.org/geos/browser/tags/3.1.0/capi/geos_c.h.in ). This is probably old enough (4 years) so that MapServer can assume GEOS being 3.1.0 or later (if not already the case)

[tbonfort]

Thanks Even, I hadn't thought of the fact that OGR was also using geos and would therefore have installed its own error handlers, that makes alot of sense. I'll have a look into this next week.

[dmorissette]

Makes complete sense. Thank you @rouault for the explanation , and @tbonfort for fixing.

[rouault]

FYI, I've just migrated GDAL trunk to use the _r GEOS API : http://trac.osgeo.org/gdal/changeset/26326 . Announced in http://lists.osgeo.org/pipermail/gdal-dev/2013-August/036877.html

[tbonfort]

closing this one, will be fixed with #4738

[tbonfort]

@aperi2007 I hope I've fixed the GEOS/OGR collisions in #4738. Can you retest with the current master and close this issue if your original problem was fixed. thanks.

[aperi2007]

Hi Thomas.

I confirm i work without any error.

Many thx for fixing.

[aperi2007]

I see again this error on a my map using the mapserver from trunk. :(

I have this couple of settings:
ANGLE FOLLOW # class from lett_c_corsi - 1:36.436
OFFSET 15 99

with they I have an immediatly crash of mapserver.

the crash happen also if I put
OFFSET 15 -99

If I remove the
OFFSET setting the error disappear.

I try to do an use case test.

[aperi2007]

At now I found only that the error came from the Geos lib:

[Wed Oct 23 17:09:38 2013].557677 msGEOSError(): GEOS library error. �
[Wed Oct 23 17:09:39 2013].131077 msGEOSError(): GEOS library error. �

I'm using the geos 3.4.2 64bit.

[tbonfort]

I'd need to get a backtrace of when that error is happening, you can get that by setting a breakpoint in msGEOSError()

[aperi2007]

Sorry, but I'm no skill on cmake. There is an option in cmake to enable debug ?

[tbonfort]

cmake .. -DCMAKE_BUILD_TYPE=Debug

[aperi2007]

Sorry again,
I compile with the debug and after I start a debug session on shp2img to try to replicate the bug.
In it, I try to add a breakpoint to msGEOSError using "break msGEOSError", but gdb don't find the symbol.

Is this the right procedure for a mapserver executables ?

[aperi2007]

ok, I found how to activate the debug,
Just for other interested users:

After compile with debug option the start is:

gdb shp2img
to set the breakpoint:
break "/path-to-the-compiled-source-file/mapgeos.c:msGEOSError"
and to run set:
run -m /path-to-mapfile/file.map -o /path-to-output-image/test.png -e 1626323.47 4834974.40502219 1633167 4840639.08 -s 700.7017023127543 580 -l "idlayer" -i png -all_debug 3

So I can test the issue.
I see the run don't crash as I guess. But it produce always a white map. With only the default status layers.
This is pretty strange for me.

Infact the same parameter combination on mapserver wms will produce a good visible map is a remove the
OFFSET setting.

Instead using the shp2img also with the OFFSET removed the image produced is always white.

... :/

[tbonfort]

clearing the milestone until we get more info or a testcase

[jratike80]

Seems to be a long story. @aperi2007 , could you update the ticket with the current status with Mapserver 7.0?