Why this error is reported (and synchronization is not finished)?

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

Parents
  • 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:

    • min: -824908.989m,-1069967.295m,328.492m
    • max: -824738.035m,-1069917.237m,332.343m

    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,

      Jan

  • 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 ;-)

    Regards,

      Jan

  • 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,

    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.

    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.

    User-defined and external GCS could cause issues with the Connectors in some cases.

    No custom GCS is used.

    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:

    • iModelBridge JTSK test (no EPSG).dgn ... no GCS is assigned, synchronization works fine
    • iModelBridge JTSK test (EPSG 5514 JTSK).dgn ... EPSG:5514 Czech/JTSK.Krovak, the synchronization fails
    • iModelBridge JTSK test (EPSG 5514 JTSK-A).dgn ... EPSG:5514 Czech/JTSK-A.Krovak, the synchronization fails too

    So the problem is not whether delivered or custom GCS is used, but that the synchronization fails alwyas, when JTSK is assigned.

    With regards,

      Jan

  • Jan,

    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.

Reply
  • Jan,

    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.

Children