Hi,
I am trying synchronize quite simple 3D model, but this error is reported during the synchronization:
ERROR [0x0000475c] iModelBridge - Project extents are too narrow: 0.000000 (ratio of largest footprint dimension to height; expected greater than than 0.100000). Element geometry this expansive will affect display performance, and often indicates corrupt elements or transforms.
I do not understand what is wrong and how DGN file should be corrected.
With regards,
Jan
Hi Jan,Not sure how the 3D model is created, but could you check if you have the correct geometry in the dgn.
Generally we have an issue that the 3D geometry is set to large or we have some outliers, but it looks like there it is a 2D flat model, is that the case ?
We do have ways of setting the extents, but for the z element, you may want to consider adding some height. I am going to guess that in this case we could downgrade the message to a WARNING rather than an ERROR
One more comment...
The biggest object in model has its range:
So it's flat (6 meters height), but large (> 160 meters length), placed in big negative coordinates. Common situation for all civil projects in Czech Republic.
Regards,
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
The validation is based on width/height (x/y) vs. depth (z), not the absolute position. The intention is to detect very tall but narrow extents (e.g. bad geometry up in space), so a model that is very flat should not trigger this (the larger of width/height divided by depth will be a large number, not less than 0.1).
I think the bigger problem here is actually a crash in the MicroStation bridge. It seems related to converting the GCS information. I'll let the Connector team know about the crash. It is also quite possible the extent report is a red herring due to the incomplete conversion.
Answer Verified By: Jan Šlegr
Thanks a lot!
If there will be any need for testing with specific data, I am ready
Hi Jeff,
Jeff Marker said:It seems related to converting the GCS information.
I did a few more tests and it seems you are right about GCS:
Both tests were done with the same DGN file, where elements are placed in "correct" location (big negative coordinates). Target iModels had no limits assigned.
Fortunately, because we have one standard coordinate system in Czech republic only, to synchronize models without GCS assigned is possible. Even though it can cause troubles when GCS has to be assigned for any other reason in MicroStation (e.g. to reference data sources published in WGS84).
The current diagnosis is that the MicroStation Connector does not contain the data for EPSG 5514. While fixes to merely avoid the crash can be done quickly, we'll need more internal discussion to modify the GCS delivery to fully support the data.
Thanks for the information. I am looking forward to the solution, fortunately it's not blocking issue for my customer ;-)
Jan,
As you know there are 7 versions of GCS marked as EPSG:5514.
Two of them are for older Czechslovakia (S-JTSK/gc.Krovak and S-JTSK/gc.Krovak-Prec), two of them are for The Czech republic (Czech/JTSK.Krovak and Czech/JTSK-A.Krovak) and three for Slovakia (Slov/JTSK.Krovak, Slov/JTSK-A.Krovak and Slov/JTSK-B.Krovak)
There are none named explicitly EPSG:5514 for the obvious reason the definition is ambiguous.
My guess is that when you speak of EPSG:5514 you are refering to Czech/JTSK-A.Krovak or is it a user-defined GCS or originating from another source (An ESRI Shape file)?. User-defined and external GCS could cause issues with the Connectors in some cases.
I would be grateful if you could provide a DGN with the GCS set and possibly a vector of any kind ranging over the apporximate area of the project.
Alain
Hi Alain,
Alain Robert said:As you know there are 7 versions of GCS marked as EPSG:5514.
you are right, one EPSG code represents several variants of S-JTSK coordinate system. In fact, it's still the same system, but I guess usually with different Datum defined, which leads to different transformations to e.g. WGS 84.
Alain Robert said:My guess is that when you speak of EPSG:5514 you are refering to Czech/JTSK-A.Krovak
Yes. My experience is that when users for any reasons need to assign GCS in MicroStation, they typically select Czech/JTSK.Krovak or Czech/JTSK-A.Krovak.
Alain Robert said:User-defined and external GCS could cause issues with the Connectors in some cases.
No custom GCS is used.
Alain Robert said:I would be grateful if you could provide a DGN with the GCS set and possibly a vector of any kind ranging over the apporximate area of the project.
Because I am not allowed to share original data, I created own one: The content is different, but is placed at the same coordinates and I attached also some ItemTypes, because they are used in the original data too.
The attached zip file contains 3 files with the same content:
So the problem is not whether delivered or custom GCS is used, but that the synchronization fails alwyas, when JTSK is assigned.
I had not forgotten about you. I was just caught up in a million things including grasping the whole iTwin process I am moderately familiar with.
A safeguard for unknown GCS during publication of an iModel was added but was not required for EPSG:5014 with a locally built version of the Connectors. I beleive the issue was solved at the same time as another fix I had made earlier.There is one remaining issue I am investigating in Design Review that is specific to EPSG:5014 and it concerns display of Bing Map in Design Review. Bing will not display if opening the model is performed using a Saved View, It will display however when selecting the 3D Model tab instead. It may be related to the position of the Saved View or not. I will keep you posted.
Of course I meant EPSG:5514 above; not EPSG:5014.