Register | Login
Attackpoint - performance and training tools for orienteering athletes

Discussion: Veg or png to dxf for OCAD?

in: Orienteering; General

Apr 27, 2020 8:59 PM # 
Mr Wonderful:
I thought I read on here about a way to take something like the KP vegetation and end up with an editable .ocd type object, maybe dxf or similar. But my searches thus far have been fruitless, or my memory was wrong in the first place!

Any hints or tips? Thanks in advance, not much else to do right now except make maps!
Advertisement  
Apr 27, 2020 10:25 PM # 
Spike:
Joakim Svensk has a little program to create shapefiles from KP vegetation. There's a link on this page (Swedish page):

https://stefansolsida.wordpress.com/2017/08/06/gor...

I have used QGIS. The basic steps are to open the vegetation.png file. Then:

(1) raster > conversion > polygonize.;
(2) In the processing tool box use "vector geometry simplify";
(3) The last step is to use the processing tool box to smooth the simplified vector (vector geometry smooth").

Step (1) is enough to get a file you should be able to open in OCAD. Steps 2 and 3 are only needed to simplify and smooth the shapes to make them less blocky. You can probably do similar smoothing in OCAD.
Apr 28, 2020 1:12 AM # 
haywoodkb:
The vegetation PNG has an associated "world file" for georeferencing, and the newest OOMapper has a vector tracing option. It should be possible to turn the vegetation template into vector symbols within OOMapper.
Apr 29, 2020 5:40 AM # 
cedarcreek:
There’s a recent thread on Facebook about this:

https://www.facebook.com/groups/485564718218028/pe...
Apr 30, 2020 7:31 AM # 
Terje Mathisen:
My own set of tools do just this, i.e. the last stage of my batch file that processes lidar will first do a point cloud to vegetation raster step, one for each tile of typically 256x256 or 128x128m, then it converts each of those tiles to a DXF file before optionally combining all the tiles into a single DXF covering the entire map.

In order to work best, my program require you to calibrate the vegetation recognizer, typically by surveying a few percent of the target area in order to come up with a set (10-30) of reference patches of vegetation, at least one for each type of vegetation that should be mapped as a particular shade of green, green stripes, white or yellow.
May 1, 2020 4:04 PM # 
MIclimber:
I too have the ultimate goal of trying to auto generate veg that is generalized and vectorized for import into OCAD for easy initial base map creation. Have been stumbling around on this part for weeks. It's fairly disappointing that OCAD does not have this type of function natively built in and forces you to do tedious field work / drawing veg by hand or accept their pixelized raster veg.

Joakim's polygonize program errors out on my file, even though the example works. I get a MemoryError, polygonize returned -1. I have 16 colors apparently versus the example having only 7. I'm hoping to hear back from him, as this one if it works seems to be the easiest to work with.

I tried Qgis as well, and was somewhat successful. I was able to convert raster to vector, then simplifying and smoothing, but then everything just turned red and it seemingly lost all my colors. I was able to export to .dxf and import then into OCAD. The smoothly and generalizing objects were sublime, so if I could figure out how to retain original colors that would also be easy to work with. But as it stands, editing each object and changing colors is also way to tedious for my liking.

Trying to run Terje's lidar-adaptive batch on a win10 machine on my .laz file, but it keeps erroring out on the .pl scripts. Getting the file does not have an app associated with it. I added .pl to the win environment variables - pathext section, but that did not help. Hoping Terje or someone can advise what I'm doing wrong.

Thanks,
Steve
May 1, 2020 4:29 PM # 
jjcote:
In the Qgis case, can you select all of the objects (Select By Symbol), and just change the color of all of them in one step?
May 1, 2020 8:21 PM # 
Terje Mathisen:
@MIclimber: I have just updated my mapping page, so that the lidar-adaptive script has all the latest programs.

https://tmsw.no/mapping/lidar_adaptive.7z

Please remember that you _have_ to first install a compatible Perl version, i.e. I recommend ActiveState Perl for Windows, 64-bit version (if you have a 64-bit Windows).

Good luck!
May 1, 2020 10:12 PM # 
MIclimber:
Hi Terje,

Thank you first of all.

I am using your latest scripts and have perl from active state installed already. I am not a programmer so I don't really understand perl beyond that I successfully installed it according to the version command. I tried reinstalling perl, I'm not sure if that made it worse, as now I can not get it to go into an activated state like before. I don't know if that is required or not. I tried a few things I saw online, but unsure if it had any effect.

Anyways whatever I did, I tried running your script again, and now the process partially ran, which I'll consider progress. It created tiles, but once again errored out once it hit the 4 .pl scripts saying it's not associated to an app. Any advice on how to fix this? I assume this is now a windows issue and not a perl issue? As I mentioned I added .pl to the PATHEXT in advanced settings already.
May 2, 2020 4:59 AM # 
Terje Mathisen:
You do need both perl.exe in the PATH and .pl associated with that executable.
A workaround is to edit the batch file and prepend all the xxx.pl commands with
"C:\Perl64\bin\perl.exe" or wherever you have the binary, that way you don't need either the PATH or PATHEXT to be setup.
May 5, 2020 8:23 PM # 
MIclimber:
I tried again to add to the system/user environment variables for PATH, but still did not work. However, adding the full path name inside the script to the .pl cmds worked, so thank you!
May 6, 2020 7:31 AM # 
Terje Mathisen:
OK, in that case you have probably installed this in a different directory than me (\data\orientering\), in which case you would have to adjust the PATH entry at the top of the batch file. Full paths work always though. :-)

Please report back with what sort of results you are getting!
May 6, 2020 4:47 PM # 
MIclimber:
I'm happy to report I was successful in creating a veg dxf and importing to OCAD using Terje's batch script. It auto created and merged into one dxf file. I imported to OCAD where it retained the symbol code, but didn't actually change to the proper color, even though I used the .crt file. But it was not a big deal, as only had a few colors. I used the change all object by symbol tool and quickly amended to the correct color. There was a bit of cleanup work, with deleting some extra features that I didn't need, like picnic tables and artwork, but again, fairly easy to do with selecting all by symbol type. A side note, was that for whatever reason, Terje's gif output did not load into OCAD properly, loaded as all black. Not that I needed the gif now that I had the dxf, but this led me to figuring out how to use QGIS to convert the gif to geotiff, which that properly imported to OCAD. KP's png had no issues either importing, so not sure what is up there, since the gif opens normally and the world file was fine.

Anyways, I wanted to run a comparison of the different methods, but I have not heard back form Joakim about getting polygonize to run fully. I did also attempt to do a test with QGIS. Which while perhaps using QGIS is more user friendly and I was able to follow the previously mentioned steps to get a dxf, it did not retain the symbol coding, even using Terje's crt file. So while QGIS might produce nicer curves in the objects, having to go thru and individually edit the objects to the correct color symbol is a non starter. Maybe there is a crt out there that keeps the code references in tact for QGIS, not sure?

So, I'm pretty happy that I've gone from a brand new user of OCAD to processing lidar, creating a viable base map with decent veg, all of which was auto generated and probably can be done in a few hours once process is honed in.
May 7, 2020 5:56 AM # 
Terje Mathisen:
Good to hear this!

You should in fact have gotten the proper ocad objects types, i.e. with white/yellow/green/stripes, did you try to apply the veg2dxf.crt file while importing the merged dxf?

Re. solid black (or any other color) filling the screen: This is most probably an artifact of the import process, when it happens I usually get a single object covering everything, but by just clicking on it and then deleting it, the normal/actual objects turn up underneath it.

Can you zip up and send/upload somewhere the dxf and crt files you tried to import?

PS. If you import my dxf without any crt file, then you can do a bulk conversion afterwards, using the [Map] [Convert Imported Layers to Symbols] function where you can either try to load the crt or use [Add all] to locate all symbol types in the dxf.
May 7, 2020 4:33 PM # 
MIclimber:
Ok that is where the confusion came in. veg2dxf.crt is in your old "mapping" bundle. I used the lidar_adaptive_vegetation.crt assuming that was the update to use. Now I realize that is for the gif creation I assume. Perhaps veg2dxf.crt should be included in your new bundle and the basemap page could use an update? Or a readme added to your new bundle? With info scattered about online and cobbling together instructions here and there, I may have easily misunderstood as well. Maybe I'll run another test now that I know which crt to use, and/or this other command to convert all.

I can email you the dxf file sure. Again thank you, for the help and what you've created.
May 7, 2020 6:47 PM # 
Terje Mathisen:
OK, I should definitely clean up my .crt file setup! I tend to create them programmatically in parallel with other conversion tasks, but those are never properly in sync so I'm just using a small static set which is what I should include. :-)

No need to ship the dxf over!
May 8, 2020 2:10 PM # 
MIclimber:
Just as a follow up for others who may stumble upon this in the future. I went back and used Terje's veg2dxf.crt in his "mapping" bundle, on my merged.dxf file from his "lidar adaptive" bundle and it did in fact convert the objects to colors without having to manually change them. So this method will work start to finish! Assuming you can install python, perl, lastools, unpack the scripts, and know a bit of dos commands...

On a side note, I attempted to do the same with my qgis dxf export using Terje's crt and it did not work. I also tried to do the map-convert imported layers to symbols function, and that also did not work on the qgis file. So perhaps it needs it's own crt to be successful, not sure.

So for me I was able to get Terje's script to work and import successfully into OCAD. QGIS might be more user friendly, but there would be additional training/knowledge to take place in order to over take ease of use.
May 17, 2020 6:40 AM # 
Jagge:
I never had need for vectorizing the vegetation image. If I auto generate map for instant use I find it better to have lost of green shades I don't edit it anyway, so no need of vectors or converting them to only three ISOM shades. And if I edit it, I ijust do some color palette editing, tuning green up or down. Easy to do when it's paletted raster image. And if it is for mapping, I prefer not doing any filtering to not lose any useful information. Often human eye identifies vegetation edges and features in unfiltered granular image pretty well, better than after image being pushed though filter algorithms and converted to only three shades of green. And there is no point converting such granular image vector, it would be equally impossible to edit.

May 17, 2020 6:58 PM # 
Terje Mathisen:
Jagge & I have agreed to disagree here. :-)

I.e. his algorithm tend to create more immediately useful contours and vegetation than my own, but my DXF vector vegetation have been reported, by several WOC-level mappers, to provide very useful information even if I by design tend to include more information than you want in the finished map: The important thing is to get most of the boundaries accurately located, at that point the mappers find it easy to modify a patch by changing type or even delete it.

Quoting one of the JWOC mappers: "In every place where you have generated a vegetation boundary, we can see it in the terrain, i.e. we understand why it is there. We still delete/ignore quite a few of them in order to generalize the map to make it more readable, but having those boundaries is really helpful."

It is well worth noting that in the mapant.no project which I'e been running for a couple of years now (most of the data has now been made accessible to us, but in formats and with an organization which is far less usable than the one selected in Finland), with very significant help from Henning Spjelkavik and Jan Kocbach, we decided to use Jagge's instead of my code for these functions! Since what we are producing is just raster maps, going the extra stage via vegetation vectorization would just increase the processing time without giving us any additional information.

Please login to add a message.