It doesn't hurt to ask...
9 posts • Page 1 of 1
It would be nice if we could perform a function, resize heightfield for example, and not have it attempt to render or display after....almost command line if you will. For very large maps it can take as long to display as it did to resize and since I can't perform another function until it finishes it slows work flow. It kind of defeats the purpose for some where you need to see the output but as with most GIS programs displaying really large files is not always a good thing (most allow you to work and display certain areas) and with something like a resized HF it can be a lengthy process given that your tile size is now much smaller....am I making sense?
Hi Aaron, thanks! I canceled but could not perform anything else as it said the heightfield map was busy. It's not a terribly big problem but if I want to try different climate settings for my attribute map it needs the HF displayed...is that correct?
No, that just sounds like a bug. Cancelling the rendering should not leave the heightfield in a busy state. I'll look into it.
In theory, the operations should work regardless of which map is displayed (exceptions: export active map, split to mosaic, combine mosaic, and duplicate tile borders, which depend on the map that's displayed).
Following-up on the command-line stuff, I've started to implement the plugin (ZeoScript). At the moment, the scripting plugin can only handle function calls with arguments that are basic data types (int, float, string, etc.) This means you can run basic scripts like:
... to save the map project. I still have to implement handling of more complex data types like maps and file formats, but that should be fairly quick work. Anyway, once that's settled you'll be able to do stuff like:
or maybe even:
The list of available functions to be called (e.g. 'file.SaveMapFile') is already viewable in the 'atFuncBrowser' plugin (installed by default), which you can open using the 'Extensions->atFuncBrowser->Browse functions' menu option. Of particular interest may be the functions under 'calc->HF', which includes the lion's share of L3DT's heightfield effects. Once I've got those '<m:...>' and '<z:...>' things working, you'll be able to run them all. I was going to add menu options for all of those functions, but now I think I'll scupper that idea since they'll be accessible via ZeoScript.
Anyway, as I said above, it's not quite ready yet. If I have the time, I'll get this going tonight, but otherwise it will have to wait until next week.
Last edited by Aaron on Fri Mar 30, 2007 3:11 am, edited 1 time in total.
With cdPython (0.9), this task should be as easy as
However, on L3DT Version: Std 2.5 build 16
Build date: 04-Mar-07
I get a bunch of errors in the log:
The generated wrapper code for ScaleMap is:
Aaron, can you spot a bug in the generated code?
Where you do:
You should do:
SetVarRef makes hVarhMap an alias of hMap (it accesses the same data). This way, a copy of the map is not created, which is important given the size of those things. Generally, when passing large objects around, I'll use SetVarRef to avoid copying the data.
The purpose of var_SetValue (and var_GetValue too) is for is accessing simple data types like integers, where you can do stuff like this:
int i = 50;
That is, the second argument is a handle to the actual data type wrapped by the variable. In the case of a map variable, the data type is a class, the source code for which is not provided with Zeolite, so you can't call var_SetValue with a map (same goes for the other classes like formats, lists, etc).
Thanks, I have modified my Python C API generator script to take into account types that are set by reference (temp.GetTypeID() >= zeolite.VarID_colour and temp.GetTypeID() <= zeolite.VarID_ProgBox).
I'll upload cdPython-0.10 shortly.
The above example doesn't give me errors now, however I don't really notice any difference in the HF.
9 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest