GeoScripting outdated?

Uwe,

You are correct in that Bentley Map no longer uses a FEATURE table. The Bentley Geospatial Administrator is used to define feature classes and associated business properties, along with other aspects of an XFM project.

The scripting engine of Bentley Map has never been updated to support the XFM data model but can still be used to perform various tasks involving the analysis or manipulation of MicroStation elements. There is no single answer to the "...which parts can still be used?" question. Depending on the type of design file data you have and if you have MicroStation database linkages to external RDBMS tables you can use the majority of the scripting engine functionality.

If you've specific questions about the scripting engine, post them in this forum and we'll do our best to answer them.

Jeff,

thanks for your answer. From your point of view, is it future-proof to invest time and efforts in learning and working with the Geoscripting language? Or is Bentley going to kill it in future versions of Bentley Map since it doesn' work with XFM?

Regards, Uwe

Uwe,

As you may know, the Bentley Map scripting engine capabilities were originally developed for MicroStation GeoGraphics some ~17 years ago, before VBA was available in the MicroStation platform. Users that have invested time and effort to learn the scripting capabilities are often glad they did, especially when they begin to understand what can be done using only a few lines of scripting code. This is especially true for those requiring bulk data manipulation or spatial processing.

While the scripting engine provides many powerful capabilities it does have some shortcomings when compared to modern development tools. For example there does not exist an Integrated Development Environment (IDE) or debugger similar to what is available for VBA or Microsoft Visual Studio. Because of this larger more complex scripts can be difficult to develop and debug. This fact also influenced the Bentley Map product team decision to not add XFM support to the scripting engine, focusing our energies on more modern development and customization environments.

I've presented development and customization workshops over the past ~17 years for both the MicroStation GeoGraphics and Bentley Map platforms. Those courses always include working examples written in C/C++, C#, VB .NET , VBA and the scripting engine. Even though C/C++, C#, VB .NET and VBA are undoubtedly the most widely used programming languages used today for custom Bentley Map application development, I still cover the scripting engine. I do this to ensure that my students are aware of the capabilities to let them decide when it is appropriate to use C/C++, C#, VB .NET , VBA or the scripting engine in their data production, maintenance or analysis processes.

Looking towards the future, as we continue to expand the Bentley Map SDK capabilities with each release, we may consider implementing support for some of the advanced scripting engine capabilities and concepts into the Bentley Map APIs for C/C++, C#, VB .NET and VBA languages. We'd like to hear from those Bentley Map users familiar with the scripting engine on which capabilities they would most want to see provided for other development languages.

Uwe,

As you may know, the Bentley Map scripting engine capabilities were originally developed for MicroStation GeoGraphics some ~17 years ago, before VBA was available in the MicroStation platform. Users that have invested time and effort to learn the scripting capabilities are often glad they did, especially when they begin to understand what can be done using only a few lines of scripting code. This is especially true for those requiring bulk data manipulation or spatial processing.

While the scripting engine provides many powerful capabilities it does have some shortcomings when compared to modern development tools. For example there does not exist an Integrated Development Environment (IDE) or debugger similar to what is available for VBA or Microsoft Visual Studio. Because of this larger more complex scripts can be difficult to develop and debug. This fact also influenced the Bentley Map product team decision to not add XFM support to the scripting engine, focusing our energies on more modern development and customization environments.

I've presented development and customization workshops over the past ~17 years for both the MicroStation GeoGraphics and Bentley Map platforms. Those courses always include working examples written in C/C++, C#, VB .NET , VBA and the scripting engine. Even though C/C++, C#, VB .NET and VBA are undoubtedly the most widely used programming languages used today for custom Bentley Map application development, I still cover the scripting engine. I do this to ensure that my students are aware of the capabilities to let them decide when it is appropriate to use C/C++, C#, VB .NET , VBA or the scripting engine in their data production, maintenance or analysis processes.

Looking towards the future, as we continue to expand the Bentley Map SDK capabilities with each release, we may consider implementing support for some of the advanced scripting engine capabilities and concepts into the Bentley Map APIs for C/C++, C#, VB .NET and VBA languages. We'd like to hear from those Bentley Map users familiar with the scripting engine on which capabilities they would most want to see provided for other development languages.

Jeff,

thank you very much for your comprehensive and very interesting text. No chance to find out background info like those here in Germany ...
Please let me explain what I'm looking for in detail. When we started our business in 1996, we were glad to have GeoGraphics (GG) since it was one of only a few desktop Gis's on the market. Our main task (except base data collection from air photos) is topological data cleanup, polygon feature generation, simple analysis and overlay operations. The data is captured in pure MicroStation systems, not in GeoGraphics or Bentley Map. That's why there are no features at the first stage.

Since there are many files to be processed, things had to be automated as far as possible. I'm not a programmer, so I gathered some key-ins and Basic macro functions from the macro recorder to get the work done. Over the years, everything worked fine and stable, so we did not have to change a lot.  >never change the running system<

Now we need to (and we want to!) switch from GeoGraphics to Bentley Map. I'm not sure what is the best way to transform the old "macros" to the new system. Tool boxes and concepts have changed drastically, and most things from GG seem not to work any more. Let me please give an example:

Data is collected as lines and texts. From that, polygons are derived automatically and the polygons go into overlay operations with certain settings similar to the following example lines:

     MbeSendCommand "TLAYER DBOX POLYTOPOLY "
    MbeSetAppVariable "TOPO", "gSettings.operator", 3&
    MbeSetAppVariable "TOPO", "gSettings.polyPolyLinks", 1&, 1&
    MbeSetAppVariable "TOPO", "gSettings.polyPolyName", "myNewLayer"
    MbeSendCommand "TLAYER BUILD POLYPOLY PolygonName1=xabt PolygonName2=xuabt"

the next part is very important: the database links of the input layers have to be maintained and joined in the output! In GG, there was a join table and join cols for this purpose. How is this done in Bentley Map without having to call the C++ programmer and pay thousands for his work? And after that, not being able to change the least bit because I can't read the code?

         MbeSendCommand "TLAYER DBOX SPATIALJOIN "
    MbeSetAppVariable "TOPO", "gSettings.joinTableName", "myJoinTable"
    MbeSetAppVariable "TOPO", "gSettings.joinCols", "myFirstCol mySecondCol"
    MbeSetAppVariable "TOPO", "gSettings.entities", "myFirstEntity MySecondEntity"
    MbeSendCommand "TLAYER JOIN"

In Bentley Map basic, I did not find any comparable functions until now. The macro recorder does not record overlay actions when they are performed in Map Manager. The old GG recorder did so.

So I checked the GeoScripting help files and found wonderful things. I did not use it up to now because everything was working in GG. It looks like GeoScripts are almost exactly what's needed for most of my purposes. Is that right or are there still alternatives in Basic? And is there a source of info where can I read more details about it? For example, I found out that in GeoScripts you can "attach/insert" a table record for each element in a set. But how to make sure that there is a correct mslink entry for each record? While testing, I found that the system does not put in what I want for mslink. Numbers start somewhere and are not ascending.

I think it would be a little exaggerated (and too hard) for me to try learning C/C++/# for this. So my options are Basic or Geoscripting. For this reason, I'd like to know if it's a good idea to use Geoscripting and where I can learn more about it. Here in Germany, there are no GeoScripting workshops offered.

Regards, Uwe

Uwe,

I appreciate you taking the time to explain in further detail the data you have, the previously used process and the desired output. I also appreciate the fact that you do not consider yourself a programmer. Therefore we must attempt to find a suitable solution for you working with current Bentley Map capabilities.

Based upon the described data, previously used process and desired output it seems that you correctly identified scripting as an appropriate solution. I tend to agree with your assessment since you have MicroStation design file data with database linkages, both fully supported by the Bentley Map scripting engine. In addition generating polygons and performing spatial overlays are some of the scripting engine strengths.

To confirm whether or not the scripting engine can provide a solution and to ensure that "...the database links of the input layers have to be maintained and joined in the output" requirement can be addressed, would you be able to provide me (offline) with some sample data (e.g. design file(s), database)? If so please contact me offline with a direct message and I will provide you instructions for uploading the data to a secure site.