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