[mapserver-users] Re: ANGLE FOLLOW and Label Offset (v. 5.6.6)
Bob Basques
Bob.Basques at ci.stpaul.mn.us
Tue Jun 7 08:10:55 PDT 2011
Brent,
I was thinking initially about some sort of half way between persistent and original, the difference being, primarily, that these buffered objects would end up being real and new geometries, instead of buffered thingies. This would allow for using the existing labeling capabilities. Running these buffered objects out in real time seemed to be the problem. Your specific needs seem to point to dynamic rendering as well (scaled geometries)
Sounds like Steve's idea is reminiscent of a conversation we had a few years ago related to putting more GEO control into a user request pipeline, which is essentially a method of working the new geometries forward halfway. You're right though. May have to re-write some of those project descriptors at some point. :c)
bobb
>>> Brent Fraser <bfraser at geoanalytic.com> wrote:
Bob,
I take it you mean making the transformed geometry persistent to minimize the performance hit? You can do that now by creating additional layers with your favorite GUI or command line tools. My buffered geometry is for visualization only (so far?) so the buffer distance is in pixels (or text points). I want the thick line rendered inside the polygon to be 5 pixels wide regardless of the zoom level, or I want the stream label to be placed [approximately] 4 pixels above the stream regardless of the view scale.
On the other hand, Steve Lime had mused about having LAYER-level transformed geometry so it could be used in queries. It kind of boggles the mind (well, mine anyway). Would it be possible to select features by attribute (where name='my stream') from one, buffer it (my_buffer=buffer(shape, 500m)), and use the resulting geometry to select from another layer (where building_type="residential' and within(my_buffer))?
Oh wait, "Mapserver is not a full-featured GIS"...
Best Regards,
Brent Fraser
On 6/7/2011 8:21 AM, Bob Basques wrote:
All,
I've been following this thread with interest.
Was wondering, does it make any sense to consider building out an entirely new geometry set that is based on the original geometry. On the surface this seems like overkill, but I wonder if treating this situation as an indexing sort of problem might not help. The buffered result geometries could easily become more complex than the original geometries for example, and having them as a separated group may be beneficial to performance tuning, etc.
Might this be a new commandline tool for building these extras into a dataset (similar to making IDX files?). I could think of a few uses of this type of thing for highlighting, etc. Although, now that I've thought about it even more, the idea of being able to change these things on the fly makes the whole conversation go round back to the beginning again. :c). Making the buffering dynamic has it's advantages as well for example.
bobb
>>> Brent Fraser <bfraser at geoanalytic.com> ( mailto:bfraser at geoanalytic.com ) wrote:
Thomas,
Yes, I've been trying to come up with good map file syntax to
indicate labeling of the transformed geometry. Currently mapserver allows:
- transformed original geometry (buffer, difference)
- augmented original geometry (bbox, start/end, vertices)
- rendered label geometry (labelpoint, labelpoly)
but it doesn't label transformed geometry, only original geometry. The
main problem (from a user interface perspective) is how to relate
transformed geometry to the label specification.
One solution is to allow a LABEL object within a STYLE object:
CLASS
NAME 'Streams'
STYLE
GEOMTRANSFORM (buffer([shape], 5))
LABEL
usual label settings
END # Label
END # Style
but that's a little strange as STYLE objects are currently allowed
within LABEL objects.
Another solution is to have "named" geometry and reference it in the
LABEL object (and keep the existing CLASS/STYLE/LABEL structure):
CLASS
NAME 'Streams'
STYLE
GEOMTRANSFORM my_label_shape = (buffer([shape], 5))
END # Style
LABEL
usual label settings
GEOMETRY my_label_shape
END # Label
And I'm sure there are other (and hopefully better) solutions.
Best Regards,
Brent Fraser
On 6/6/2011 11:02 AM, thomas bonfort wrote:
> Yes, the resulting shape seems like a nice candidate for offseting
> labels, but the problem with buffer is you will have more difficulty
> in deciding what is to the left from what is to the right of the line.
> We'd also have to make sure that the buffer operation is not too
> costly on cpu cycles.
> Anyways, until geomtransform is not applied at the layer level, there
> is no way to use this method as the label does not operate on the
> transformed geometry.
>
> On Mon, Jun 6, 2011 at 17:30, Brent Fraser<bfraser at geoanalytic.com> ( mailto:bfraser at geoanalytic.com ) wrote:
>> Steve,
>>
>> I think just buffering the line would apply a type of smoothing (see
>> attached image). Using the resulting buffer line (or perhaps doing some
>> simple line smoothing on it) for labeling would be good enough.
>>
>> Best Regards,
>> Brent Fraser
>>
>>
>> On 6/6/2011 9:04 AM, Stephen Woodbridge wrote:
>>> Duh! you are correct, I always forget this point until I after my second
>>> cup of coffee has kicked in :)
>>>
>>> That article looks very interesting, I have to read up on that.
>>>
>>> In a past career in computer aided design and manufacturing, we used the
>>> idea of a rolling ball offset because it modeled a milling machine. The
>>> rolling ball offset is defined as the curve traced by the center of a ball
>>> of a given radius as you roll it along a curve. The circumference of the
>>> ball can not cross over the original curve so for tight "S" curves if the
>>> diameter of the ball is larger than the gap in the "S" then the ball does
>>> not enter the gap but floats over it. This same concept would make for well
>>> behaved and good looking labels along tight twisty paths like rivers and
>>> roads.
>>>
>>> Another idea for smoothing out curves for labeling might be to apply an N
>>> point moving average and allow that to be the label path. I don't think this
>>> has been mentioned as an option in the past.
>>>
>>> -Steve W
>>>
>>> On 6/6/2011 10:20 AM, thomas bonfort wrote:
>>>> There are two problems with the solution you propose:
>>>> - if you offset the geometry in postgis, the distance of the offset
>>>> will be in geographical units, i.e. it will not give correct results
>>>> at all scales when rendered with mapserver (what you basically want is
>>>> to offset the line by a number of pixels roughly equal to the size of
>>>> the font used for labelling)
>>>> - angle follow on offset line should probably be done on a
>>>> simplified/smoothed geometry. see
>>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.6970 .
>>>> Ideally someone will want the feature badly enough to fund it :)
>>>>
>>>> --
>>>> thomas
>>>>
>>>>
>>>>
>>>> On Mon, Jun 6, 2011 at 16:02, Stephen Woodbridge
>>>> <woodbri at swoodbridge.com> ( mailto:woodbri at swoodbridge.com ) wrote:
>>>>> There was some recent discussion on the dev list about potentially using
>>>>> the
>>>>> GEOMTRANSFORM to do something like a single sided offset then using that
>>>>> to
>>>>> apply the label to. BUT I do not think that has been implemented yet in
>>>>> mapserver.
>>>>>
>>>>> Google for "mapserver geomtransform" also look at "geoprocessing" for
>>>>> some
>>>>> other ideas.
>>>>>
>>>>> Anyway, you might be able to do what you want if you:
>>>>>
>>>>> 1. import your data into PostGIS
>>>>> 2. create offset geometry in another table
>>>>> 3. export that table to a shapefile
>>>>> 4. then label that as an annotation layer so you do not draw the
>>>>> geometry
>>>>> only the label and use the original data to draw the grometry ie: two
>>>>> layers.
>>>>>
>>>>> I have not tried this, but it might solve your problem.
>>>>>
>>>>> -Steve W
>>>>>
>>>>> On 6/6/2011 9:48 AM, uvg wrote:
>>>>>> Thank you, Thomas.
>>>>>> Are there any workarounds for this problem?
>>>>>> Is there 'best practices' for the problem?
>>>>>> Maybe unvisible layer or other?
>>>>>> 06.06.2011, 17:35, "thomas bonfort [via OSGeo.org]"<[hidden email]
>>>>>> </user/SendEmail.jtp?type=node&node=6445194&i=0>>:
>>>>>>
>>>>>> The status has not changed: label follow with offset is not
>>>>>> supported.
>>>>>>
>>>>>> regards,
>>>>>> thomas
>>>>>>
>>>>>> On Mon, Jun 6, 2011 at 15:33, uvg<[hidden email]> wrote:
>>>>>>
>>>>>>> Hi all!
>>>>>>> Sorry for my bad English.
>>>>>>>
>>>>>>> I am trying to achieve is a label that follows the rivers that is
>>>>>> also
>>>>>>> OFFSET so that
>>>>>>> the label does not 'above' on the line for the river.
>>>>>>>
>>>>>>> Sample code of mapfile:
>>>>>>>
>>>>>>> LABEL
>>>>>>> COLOR 0 40 255
>>>>>>> FONT "arial-italic"
>>>>>>> TYPE truetype
>>>>>>> SIZE 7
>>>>>>> OFFSET 5 0
>>>>>>> ANGLE FOLLOW
>>>>>>> POSITION LC
>>>>>>> FORCE true
>>>>>>> PARTIALS FALSE
>>>>>>>
>>>>>>> END
>>>>>>>
>>>>>>> "OFFSET" does not work.
>>>>>>> How can I offset a label?
>>>>>>>
>>>>>>> I found a message posted for a long time:
>>>>>>> click here.
>>>>>>
>>>>>> View this message in context: Re: ANGLE FOLLOW and Label Offset (v.
>>>>>> 5.6.6)
>>>>>>
>>>>>>
>>>>>> <http://osgeo-org.1803224.n2.nabble.com/ANGLE-FOLLOW-and-Label-Offset-v-5-6-6-tp6445138p6445194.html>
>>>>>> Sent from the Mapserver - User mailing list archive
>>>>>> <http://osgeo-org.1803224.n2.nabble.com/Mapserver-User-f1969211.html>
>>>>>> at
>>>>>> Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>> _______________________________________________
>>> 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
>>
>>
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20110607/fc15a843/attachment.htm>
More information about the MapServer-users
mailing list