Yes, offset is intended for lines, using it on polygons is abusing it. the buffer+difference method is probably the way to go.
note to myself and steve: the OFFSET keyword should be moved into a GEOMTRANSFORM instead of residing in a keyword of its own. -- thomas On Tue, May 10, 2011 at 16:21, Brent Fraser <[email protected]> wrote: > Thomas, > > Interesting. I suspect all the polygons are digitized the same was as I > think this is a requirement for shapefiles. The result of using: > > STYLE > OUTLINECOLOR 255 211 127 > OFFSET 1.5 -99 > WIDTH 3 > END > > results in http://i54.tinypic.com/25a22k4.jpg Close, but notice the "bleed" > outside the polygon at the sharp corners. > > Thanks! > > Best Regards, > Brent Fraser > > > On 5/10/2011 1:38 AM, thomas bonfort wrote: >> >> Brent, >> >> those are interesting questions >> >> On Mon, May 9, 2011 at 21:51, Brent Fraser<[email protected]> >> wrote: >>> >>> While testing v6, I can up with the following list of things I couldn't >>> do >>> (see http://i56.tinypic.com/8vvprn.png for a graphic): >>> >>> 1. Render lines inside polygon boundary (with or without opacity) >> >> Along with Steve's buffer proposition, you can already more or less do >> that with OFFSET , except you don't have the notion of inside/outside, >> but left/right. If all your polygons are digitized in the same >> direction (i.e. clockwise or anticlockwise) this can be done with: >> >> STYLE >> #FILL >> END >> STYLE >> OUTLINECOLOR r g b >> OFFSET 1.5 -99 >> WIDTH 3 >> OPACITY 50 >> END >> >> >> >>> 2. Place polygon annotation on/inside boundary line >>> (http://trac.osgeo.org/mapserver/ticket/1592 point 8.) >> >> not possible in a single step, but by using the polygon layer a second >> time in a TYPE LINE layer for labelling should get you close. >> >>> 3. Rotate anno if required to fit inside a polygon >> >> would be a nice addition, ANGLE AUTO for polygon labels. We should >> probably give some way to define if the label should always follow the >> longest polygon diagonal, or if it should be first placed horizontally >> and fall back to automatic angling only if the horizontal one does not >> fit. >> >>> 4. Place polygon annotation outside polygon if anno doesn't fit inside >> >> The fine tuning on how to place the label text compared to the feature >> would require new mapfile keywords, but that would seem possible to >> implement. I'm not sure these kind of automatic adjustments would >> really enhance the rendered quality though. >> >>> 5. Place line anno above (or below) when using ANGLE FOLLOW >> >> This is something I would like to add to. There's a paper detailing >> the underlying algorithm here: >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.6970 >> >>> 6. Rotate vector symbols to follow lines (a font might work but is a pain >>> to >>> create) >> >> how is this different than what we already have with a negative GAP? >> On a side note, vector symbols are currently rather ill-defined in >> mapserver and would need to be tightened up before being able to use >> them for precise symbol placement like here. >> >>> 7. User specified character spacing >> >> SIZE AUTO for labels in polygon layers would be a nice addition. We'd >> have to be able to define how the size of the font varies in >> accordance with the spacing that is applied between characters. >> Before going down that road, we shall have to implement the >> refactoring proposed in http://trac.osgeo.org/mapserver/ticket/3611 so >> as not to clutter the glyph rendering functions of each renderer. >> >> >>> 8. Erase lines (but not other objects) under annotation >> >> This seems rather involved. It would be difficult to keep the ordering >> of layers, as the modified feature could only be drawn during the >> labelcache phase, i.e. after all other features in the map. >> >>> My goal was to use the published shp files >>> >>> (http://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/092/h/canvec_092h06_shp.zip) >>> without modification and see how close I could get to the published PDF >>> >>> (http://ftp2.cits.rncan.gc.ca/pub/cantopo/50k_geopdf/092/h/cantopo_092h06_geopdf.zip). >>> >>> Any suggested rendering techniques are appreciated. I'll file tickets >>> for >>> those problems deemed worthy. >> >> So, most of these enhancements seem possible, some were already on my >> laundry-list of rendering enhancements I'd like to tackle. Creating >> enhancement tickets for those features is a first step, and funding >> them is the second ;) >> >> regards, >> >> thomas >> >>> -- >>> Best Regards, >>> Brent Fraser >>> >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> > > _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
