mapper
mapper copied to clipboard
OpenOrienteering
Consider extending CoVe to vectorise area symbols as well
@lpechacek commented in https://github.com/OpenOrienteering/mapper/issues/833#issuecomment-283711859 that he didn't intend to implement vectorisation for area symbols in CoVe as line features are more common.
This is true for forest maps but for urban maps, area symbols are far more prolific, for example, buildings, forbidden areas, open areas, paved areas etc. There are far more area area than line features. Therefore for aiding in vectorising urban maps it would be useful if CoVe also supported area features.
Ack. I myself needed area outline vectorization while working on sponsor logos for a map. Your argument about building outlines is persuasive. On the other hand, I can anticipate the issue reports about corners not being sharp enough and walls not being parallel. ;)
IIUC, potrace (which is underlying CoVe) is much more a tool for areas than for lines?
The implementation of the "Fill bounded areas" tool is quite similar to the desired feature. It normally works on a pseudo-color raster image generated from map objects, but it could work on a pseudo-color raster image from classified colors as well.
IIUC, potrace (which is underlying CoVe) is much more a tool for areas than for lines?
Yes. One of the possibilities of implementing area vectorization is a reuse of more Potrace code, specifically decompose.c.
The implementation of the "Fill bounded areas" tool is quite similar to the desired feature. It normally works on a pseudo-color raster image generated from map objects, but it could work on a pseudo-color raster image from classified colors as well.
I can sense the idea. Feeding the BW bitmap directly into Potrace image decomposer looks, however, easier to me. Potrace was written specifically for the task of vectorizing areas, including holes(!). We can easily build on P. Selinger's work here, in my opinion.
In fact I also very much like Potrace's path conversion from straight lines to curves (http://potrace.sourceforge.net/potrace.pdf, chapter 2.3). I'd like to use that same algorithm in Mapper for path smoothing. In my opinion, Potrace places curve control points in a more natural way than the current Mapper algorithm. But I've already started hacking too many bits without finishing them, so I won't start another one at the moment.
GDAL's polygonize algorithm seems to have users not only in QGIS: https://www.dropbox.com/s/3vxnj0eurr6y9hp/polygonize.zip?dl=0&file_subpath=%2Fpolygonize.txt
FIY: https://stefansolsida.wordpress.com/2017/08/06/gora-om-bilder-till-editerbara-objekt-i-kartprogrammet-med-hjalp-av-programmet-polygonize/
As a result, this feature could not be installed, right?
Someone needs to do the work.