Element properties does not show area (the element is planar?)

Hi Eva,

Eva Ströberg said:

Does anyone know why?

Well, I think I know why (answer 1), but do not know why (answer 2) :-)))

What surprise me is a setting of working units in your design file, especially resolution and SWA (solid working area). Where the file, or a used seed, come from? It for sure does not come from standard MicroStation installation.

Standard metric seed file use Resolution 10000 (per meter) and Solid 1.000000 (km), whereas your is 1000000 (100x bigger resolution) and 4.294967 (I am not sure how this number was calculated).

Even though there should not be any impact on area calculation, maybe some exists. Maybe it's a bug? I recommend to create Service Request and to share the same design file (plus to add also link to this discussion), so support and developer can analyze it.

When I created empty standard 3D model and merged your file as reference to it (reference resolution is ignored in such case and the copy is done using master units, so element sizes are maintained), the shape area is displayed properly in Properties dialog.

With regards,

  Jan

Hi Jan

Thank you for your answer. The file comes from a seed from my organisation. I have talked to the IT people about this, and they have no clue as well. The thing is, I am working with a software that runs on Microstation CONNECT, the software is called Dandasgraf (Danish sewer software), and I found out that when I copied the seed file, I could read the area from the element properties without issue, but once I run the dandasgraf in the software (as in open the menu), then the rectangle no longer has the area properties shown.

So I don't think it's the issue with the working  units, because the original file was fine, and I didn't do much with it, apart from opening it from a certain software. The IT support at the organisation was looking into the upf, but that didn't help either. I'm still baffled with this.

Hi Jan

This is where it gets interesting, I use the software (Dandasgraf) for most of my projects. I have no problem reading the area from the element properties in other drawings even with the same software open. So it's only on this certain project that I have that the software is causing trouble, and I haven't done any change in the settings in the software that can cause this.

These elements are placed too far from the Global Origin [0;0;0]. After they are moved to the global origin, the area is displayed in the Properties. Generally it is recommended to place the elements inside SWA in the model, otherwise there are some issues happening such as this one.

Please have a look at following information on this topic:

https://communities.bentley.com/products/microstation/w/microstation__wiki/13543/troubleshooting-graphics-display-issues

https://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/marc_thomass_blog/posts/setting-up-in-the-real-world-or-quot-where-do-we-model-quot

Hi,

thanks for this hint.

A_F said:

These elements are placed too far from the Global Origin [0;0;0].

Unfortunately, I have to disagree with such (too) simplified statement.

I am not sure why these coordinates are used (maybe because of used Danish coordinate system), but e.g. when I will work with Czech cadastre system (JTSK), the values will be similar (1 200 000, 900 000) and I do not recall any issue.

More precise explanation is that the coordinates are too big when so detail resolution (100x bigger than usually) is defined, because it leads to calculations with (probably) too big numbers. When standard resolution (MicroStation seed) is used, the coordinates do not cause any problem, and as I wrote in my earlier reaction, the area is calculated correctly.

A_F said:

Please have a look at following information on this topic:

They are interesting, but primarily when solid modeling is used, and things like SWA is applied.

With regards,

  Jan

Yes, the file has Danish coordinate system (S34S) so the location is correct (now I have deleted the original drawing, and placed some rectangles nearby).

HI Eva,

I guess, based on Brien's explanation, it would be interesting to ask the software authors, why they use specifically this seed file with such configuration. I see two issues there:

It's "V7 based" , so about 20 years old, I guess. What I remember from V8 release time, it was recommended to use seed files delivered with V8 and to add custom settings, not to convert and use old V7 seeds, to do not drag potential issue and relicts to the new format.

The used resolution makes no sense and as demonstrated, leads to calculation problems. With this setting, the coordinate 1 159 550 is stored (and further used for calculation) as 1 159 550 000 000 UORs. It's still decimal number, but in floating point arithmetic (it's what processors use) with increasing value, the precision is lost.

The setting, used in V8i and CE seeds (10 000 per meter) is good balance between precise calculation, but still allowing to use big numbers over a million, which is probably a maximum used when geographical coordinates are used.

To use standard CE seed file and to add (e.g. import) all settings from the old one, should be quite easy. And when the application is written correctly, no change is necessary.

With regards,

  Jan

HI Eva,

I guess, based on Brien's explanation, it would be interesting to ask the software authors, why they use specifically this seed file with such configuration. I see two issues there:

It's "V7 based" , so about 20 years old, I guess. What I remember from V8 release time, it was recommended to use seed files delivered with V8 and to add custom settings, not to convert and use old V7 seeds, to do not drag potential issue and relicts to the new format.

The used resolution makes no sense and as demonstrated, leads to calculation problems. With this setting, the coordinate 1 159 550 is stored (and further used for calculation) as 1 159 550 000 000 UORs. It's still decimal number, but in floating point arithmetic (it's what processors use) with increasing value, the precision is lost.

The setting, used in V8i and CE seeds (10 000 per meter) is good balance between precise calculation, but still allowing to use big numbers over a million, which is probably a maximum used when geographical coordinates are used.

To use standard CE seed file and to add (e.g. import) all settings from the old one, should be quite easy. And when the application is written correctly, no change is necessary.

With regards,

  Jan

I have no idea why my organisation used seed from V7 file. I am working with Microstation CE btw. In their defense, I have also taken the same seed file for another project, with another software (Dandasgraf) where the element properties show the right numbers.

As I have explained it before, when I copied the file from the seed file, the element properties still works, so it's not about the version.

can you type go=? 

in each file  ie and tell us the result?

in old days here we used to put a false GO in V7 in our seed files so our state  would fit in the limited design plane in meters

This is no longer a requirement  in V8i or CE  they can both have a GO as 0,0 as the design plane is almost unlimited  its only a problem if you export V8 or CE dgns  as V7 dgn as they take the GO value  of the source with it and V7 files xref each other via the GO as their ref point ( this is layman explanation so no flames please)...and  both have to be the same values to work as  geo ref'd files.

I can type go= but I don't see the relevance in this situation?

Eva Ströberg said:

but I don't see the relevance in this situation?

You are right, this advice is mostly useless and is not relevant to the discussed problem in any way.

Regards,

  Jan