[mapserver-users] GAP problem on MapServer 6.0.1

[Stephen Woodbridge]

Jackey,

I have seen this problem before and I think it is related to the fact 
that you might have coincident points in your line. For example if the 
first and second point in the linestring have the same value. This 
causes problems when we try to compute the heading for that segment. If 
you want me to check on that for you then send me a zip of the shapefile 
with just the bad line in it.

If this is the case, we should probably write a bug ticket for this case.

-Steve

On 11/10/2011 8:03 PM, Jackey Cheung wrote:
> Thanks for your comment, Havard Tveite.
>
> As you suspected, the strange position (and also redundant) of arrows
> is problem in figure 1. Since there is only one line there, we expect
> only one set of (around 2~3) arrows were rendered. We can't figure out
> why there are redundant arrows rendered at strange positions. The
> expected outcome is only 2~3 arrows shall be rendered right around the
> center of the line.
>
>
>
> On Thu, Nov 10, 2011 at 4:49 PM, Havard Tveite<havard.tveite at umb.no>  wrote:
>> Dear Jackey Cheung,
>>
>> I am not sure what exactly you are trying to achieve.
>> Your arrows seem to point in the direction of the lines.
>> The topmost arrow in figure 1 is placed at a strange
>> position - is that the problem?
>>
>> Some comments:
>>
>> The result shown in image 2 is expected.  The arrow
>> symbols are in this case placed at the start points of
>> the lines according to the centre point of the symbol's
>> bounding rectangle (except 0,0 is always taken as the
>> upper left corner of the bounding rectangle).
>> When using a negative GAP, the direction of the symbol
>> is the direction of the line at the (end)point.
>> In version 6.2, ANCHORPOINT is introduced to make it
>> possible to specify a different anchor point for the
>> symbol (http://mapserver.org/trunk/mapfile/symbol.html).
>>
>> The centre point of the bounding box of your arrow_right
>> symbol will be at (17.5,7) in the symbol's coordinate
>> system, so the arrows will be placed somewhat shifted to
>> the right (in the direction of the arrow).
>> In 6.0, if you want the ends of the arrows to be aligned
>> with the start of the lines (when using geomtransform
>> start), you could use the following symbol:
>>
>> SYMBOL
>>   NAME "arrow_right_shift"
>>   TYPE VECTOR
>>   POINTS
>>     30 6
>>     52 6
>>     50 0
>>     60 7 # why 7.5?
>>     50 14
>>     52 8
>>     30 8
>>     30 6
>>   END
>>   FILLED TRUE
>> END
>>
>> In 6.2, you will be able to specify this using
>> ANCHORPOINT 1 0.5
>>
>>
>> Håvard
>>
>> On 11/10/2011 06:35 AM, Jackey Cheung wrote:
>>>
>>> Hi all,
>>>
>>> We are trying to render line direction on 6.0.1. However, there are
>>> something weird with it.
>>>
>>>
>>> SYMBOL
>>>    NAME                 "arrow_right"
>>>    TYPE VECTOR
>>>    POINTS
>>>      5 6
>>>      27 6
>>>      25 0
>>>      35 7.5
>>>      25 14
>>>      27 8
>>>      5 8
>>>      5 6
>>>    END
>>>    FILLED  TRUE
>>> END
>>>
>>>
>>> LAYER
>>>    NAME              "traffic_direction"
>>>    STATUS            DEFAULT
>>>    TYPE              LINE
>>>    MAXSCALEDENOM     5000
>>>
>>>    CONNECTIONTYPE    POSTGIS
>>>    PROCESSING        "CLOSE_CONNECTION=DEFER"
>>>    CONNECTION        "host=xxxxxxx dbname=******* user=xxxxxxxxxx
>>> password=************"
>>>    DATA              "geom FROM view_render_traffic_direction USING
>>> UNIQUE oid USING SRID=4326"
>>>
>>>    CLASS
>>>      NAME            "Traffic Direction"
>>>      STYLE
>>>        ANGLE         AUTO
>>>        SYMBOL        "arrow_right"
>>>        SIZE          6
>>>        COLOR         0 0 250
>>>        GAP           -200
>>>        #GEOMTRANSFORM "start"
>>>      END
>>>    END
>>> END
>>>
>>>
>>> The layer above is rendered as 1.PNG. We've checked that there are
>>> only one line (ring) there, but arrows are rendered problematic.
>>> Then we've tried to change GEOMTRANSFORM to "start" or "end", then
>>> rings seem OK, but all arrows at intersections got crossed, as 2.PNG.
>>> We've also tried to use OFFSET and GAP with positive and negative
>>> combinations, but none can solve the problem.
>>>
>>> Can anyone shed some light for us? Thanks in advance.
>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users