implement offseted line outlines #4716

Closed
wants to merge 1 commit into
from

Projects

None yet

3 participants

@tbonfort
Member

We currently have no way of easily rendering line outlines only, i.e. without an accompanying "fill", given that currently outlines are generated by stacking solidly stroked lines. Thus these kinds of renderings are difficultly/not supported for tunnels (note that the the "fill" is semi transparent, it could also have been completely left out):

line-outlines

Obtaining such a rendering with the current version requires a bit of mapfile hacking, using

style #right outline
  color 0 0 0
  offset 5 -99 #offseted to the right by half the road width
  width 1
  pattern 4 4 end
end
style #left outline
  color 0 0 0
  offset -5 -99 #offseted to the left by half the road width
  width 1
  pattern 4 4 end
end
style #fill (optional)
  color 255 0 0
  width 10
  opacity 50
end

This solution has two major drawbacks:

  • the value of the offset has to be explicitely set to half the value of the road width
  • we need two STYLE objects, which plays rather badly with the stacking of cached styles (i.e. other road classes will need a fake empty STYLE..END block to push them up one level in the style caching process)

Current patch extends the OFFSET keyword

style #outlines
  color 0 0 0
  offset 10 -999 #offseted to the right and left, 10 pixels apart
  width 1
  pattern 4 4 end
end
style #fill (optional)
  color 255 0 0
  width 10
  opacity 50
end

The special -999 offset Y value, similarly to -99, offsets the input line in both directions by half the value of the specified offset X value. The resulting shape becomes a multiline object.

@tbonfort tbonfort was assigned Jul 29, 2013
@woodbri
woodbri commented Jul 29, 2013

Does this work with UNITS or is it always in pixels?

I fundamentally object to these magic numbers because they are not intuitive so it is had to remember are they mean or where you can use them. I would rather see additional keywords or an optional keyword modifier(s) if that were an option.

@tbonfort
Member

Steve,
Yes, the X part works with units / symbolscale, exactly the same as for the long-existing -99 case.
If you can find the funding for removing these special values while all the while maintaining backwards compatibility, please be my guest. Given that I do not see this happening anytime soon, and that the burden of treating this new -999 value should this happen (it's used a grand total of 3 times throughout the code) is close to zero, I fail to see a reason to object to this.
my 2 cents ...

@rouault
Contributor
rouault commented Jul 29, 2013

I'm not sure if the fact that the value given in the -999 case if divided by 2 won't be confusing, since it is not the case for the -99 case (the doc of -99 in http://mapserver.org/mapfile/style.html is confusing by the way)

May I just suggest using the following macros in the code ? a grep in the code base shows that -99 is used several times for different meaning.

#define OFFSET_CURVE -99
#define OFFSET_CURVE_LEFT_AND_RIGHT -999
#define IS_SPECIAL_OFFSET(y) ((y) == OFFSET_CURVE) || (y) == OFFSET_CURVE_LEFT_AND_RIGHT)

@woodbri
woodbri commented Jul 29, 2013

There are two issues here.

  1. cleanup existing code
  2. propagating more behavior that makes clean harder (all be it marginally)
    The question I see for all of us is do we want to use magic numbers as a standard way of doing business?

Regardless, I can't fund a different path so I'm -0.

@tbonfort
Member

Steve, I don't think I have anything more to add. To put it bluntly, the issue here is do we put up with another magic number at a place that was already using them, or do we forget about this feature altogether until the hypothetical day someone wants to fund a cleanup from OFFSET(x,y) to a multiple list of geomtransforms that do the same thing.

@tbonfort
Member

@roault what part of the documentation is confusing? Aside from the fact that we could explicate that SIZEUNITS defaults to pixels in the general case, I find it rather self explanatory.
As for the half value, it is to simplify the automatic creation of mapfiles, and/or to be able to use attribute bindings, as you would be using the same value for the x-offset as you would for the road width instead of having to pre-compute the value of width/2 . This would need to be documented.

@rouault
Contributor
rouault commented Jul 29, 2013

The doc mentions a 'n' variable, that is dependant of the context either x or y. I think It should rather be" For lines, an OFFSET of y = -99 will produce a line geometry that is shifted x SIZEUNITS perpendicular to the original line geometry. A positive x shifts the line to the right when seen along the direction of the line. A negative x shifts the line to the left when seen along the direction of the line."

Got it for the explanation of x-offset = width / 2

@havatv havatv pushed a commit to mapserver/docs that referenced this pull request Jul 29, 2013
Håvard Tveite Updated documentation of offset (-99) for style as suggested in mapse… 3288654
@tbonfort tbonfort added a commit to mapserver/msautotest_DEPRECATED that referenced this pull request Jul 31, 2013
@tbonfort tbonfort add tests for failed geosoffsetcurve, and outline-offsets aacfd16
@tbonfort tbonfort added a commit that referenced this pull request Jul 31, 2013
@tbonfort tbonfort implement offseted line outlines (#4716) e498ec4
@tbonfort tbonfort added a commit to mapserver/docs that referenced this pull request Jul 31, 2013
@tbonfort tbonfort add docs for -999 offset (line outline) 5c36995
@tbonfort tbonfort closed this Jul 31, 2013
@tbonfort tbonfort deleted the tbonfort:offset999 branch Jul 31, 2013
@tbonfort tbonfort added a commit to tbonfort/mapserver that referenced this pull request Aug 23, 2013
@tbonfort tbonfort expand clipping rectangle to account for offset (#4554)
also adresses cleaner defines for single-sided offsets from #4716
d231a75
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment