Creating user-defined gaps in paths

[dg0yt]

puzzlepaint reported on Sourceforge [tickets:#150]:

Implement a tool which creates a gap in a path, so the path stays one object but the gap becomes invisible.

Applications:

• gaps in lines where the line is interrupted to show a point object
• gaps in combined objects consisting of area + border, to interrupt the border at this place. This would remove the need to keep the area and border symbols separate as the border can then be controlled using these gaps. Thus the symbol sets can be cleaned up a bit.

[mlerjen]

This issue maybe should be added to the OCAD import/export project. As "virtual gaps" are common use in OCAD10 upwards. fig.1. Virtual gap in contour fig.2. Virtual gap, one-sided in border symbol.

[dg0yt]

:+1: In my mind, it was already part of the project..

[dg0yt]

In fact, I had a "card" for this in the project. Removing this card now.

[valdisj]

Hi, any indications when this #150 issue would be moving towards developement? Anyone has any ideas how to implement this? Virtal Gap and Corner Vertex increasingly being used by mappers using other programms and import/export becomes a very seriouse issue.

[lpechacek]

Hi, any indications when this https://github.com/OpenOrienteering/mapper/issues/150 issue would be moving towards development?

Given that it's an accepted feature, nothing more than a person who writes the code, pushes it through the review and maintains it afterward is needed. My guess is 5 days for the initial implementation, which translates to about 7-10 evenings for a volunteer contributor because he/she is making living during the day, and then another 5 days to get it into shape for merging.

Anyone has any ideas how to implement this?

The majority of changes will be in the renderer and the cut line tool. That is, the data model and file handling routines will be little affected (it's just a flag on a node, IIRC) while the renderer will have to learn to split the lines around the virt-gaps.

[dl3sdo]

@lpechacek: I assume that the effort will be quite different if you consider full support also for one-side gaps in border symbols, like in @mlerjen's example. Not just because of the UI but also because of the data model if just one border of the symbols shall be cutted (and there are even combined symbols like 501 Motorway). Would it make sense to just start by cutting lines as a whole? BTW: In the past I mostly just cut contour lines for obvious reasons. Maybe that limitation would already address most of the usecases.

[lpechacek]

Good point, Matthias. I forgot about the side line cutting.

Ad the incremental approach, I'm a fan of any improvement regardless of its size. But I won't be the person merging the code, so don't take my answer as an authoritative statement.