OpenOrienteering
Double line mode
I am currently drawing a sprint map with many linear pavements with many different widths.
- One way to do it would be to define many different paved footpaths. --> That would clutter the symbol set plus it would hide contours bellow the street infill, see issue #972.
- The other way would be to draw all sidelines "manually" and then fill with pavement area. That is very labour intensive :(
Expected behaviour
- There might be a third way: In Double line mode you could define width of pavement (as when drawing circle) and then draw a linear pavement with desired width (no infill). --> That shall make drawing more efficient and also mitigate the issue #972.
Related #650 with the concentric shift you would draw a border, duplicate it and then move the double to its position. Then fill with the common pavement.
I've used two different approaches so far for sprint maps, the first with line symbols for paths and area symbols for everything else and the second drawing all the boundaries first and then use area fill. Both were awkward. I have also tested the "trick" where you can add a border along the edge of a line object. My first impression of the latter is that it's also awkward (maybe because I'm using a Mac laptop with a trackpad).
I'd like to suggest another way. How about a tool that converts a (non zero width) line object to an area object. That way we could use border-less brown line symbols to draw the paths, convert them to areas, merge them as needed and finally add borders. The result would be the same as drawing the edges first and filling at the end but with be much less work. It would also avoid the problem of finding and fixing all the missing edge pieces.
Thank you for your comments @sfroyen and @mlerjen. I would say your "workarounds" seem smoother than mine suggestion :) The trick of converting lines into areas is very appealing. And it would serve a "greater good". What do you think shall I change the issue into Convert lines into areas? I am adding also @lpechacek, perhaps he could also express his opinion. Thank you!
How about a tool that converts a (non zero width) line object to an area object.
The trick of converting lines into areas is very appealing. And it would serve a "greater good". What do you think shall I change the issue into "Convert lines ~~in~~to areas"?
@ollesmaps, use "Convert lines to areas". That is really must have feature!
(In Inkscape app such option called "Stroke to Path")
I am adding also @lpechacek, perhaps he could also express his opinion. Thank you!
Thanks for the trust in my opinion. :)
My first idea when I saw the request why just two lines and not an arbitrary number of parallel lines? Some sort of adjustable "rake tool", somewhat complementing the "Distribute points along path". If the tool were to mimic the Distribute points variant, it would create parallel lines around an existing line object. Of course, if it had configurable distances of the parallel lines, it would be usable for drawing road sidelines together with the pavements. The brown for the paved area could be added in the next step. However, this workflow does not fit the Mapper UI style, where most of the actions are performed using the mouse.
Then the next best variant is the use of parallel move (mlerjen's suggestion). I think it nicely fits the intended working style. The symbol conversion might be cool too but it feels like a dirty trick to me from the design point of view. The thing is that we are starting with a well-defined visual representation of an object - say a road - and we are splitting it into anonymous lines and areas. That is, we are losing the identity of the objects and prevent conversion into an alternate map key. I acknowledge that this is a pure programmer's view of the problem and an average map maker is not concerned about how the lines and areas are represented because by the time there will be a new map standard, the map will be obsolete anyway, so it will have to be reworked anyway. Think, however, about our peer programmers, who will contribute to the project in the future. They deserve to work with a sound program design.
That said, I still see a solution to the object breakdown problem - allow the use of existing symbols only. That is a road would be broken down into paved area infill and borderlines, and not anonymous lines and areas. That way, I'd very much welcome of decomposition of ISOM stony ground into individual dots for my practice.
For drawing multiple objects with the same width, it might perhaps help to have some kind of "Marker pen" tool, which lets you define width in a reproducible way, and then works very much like drawing line objects, except that it adds an area object when finishing.
However, such a tool doesn't help much when you want to edit the line later. For this, I would prefer to have a variable-width line. This is the actual problem: Some line symbols shall be used with width matching feature size, but our map software only knows fixed width. Tracking the width of the path as data (tag) may also help when changing the symbol set (update, MTBO, etc.).
There are a couple places, at least for sprint maps, where the distinction between line and area objects is blurred. The one that prompted my "convert lines to areas" idea was actually a vegetation issue. I wanted to add a light green "path" through a dark green area. Using the 406.2 (vegetation, slow running, minimum width) seemed like an obvious choice, but since dark green is on top of light green it won't work unless you also cut away the dark green underneath. This is similar to the path problem. Sprint map paths are mapped based on actual width (with a minimum value), so it seems natural to think of them as areas rather than lines. You also want them to behave as areas when it comes to tools like "fill", "cut", "borders" and similar.