Caice pt4 file import issue

Do you know what format is that file? it is not ascii...
communities.bentley.com/.../road_and_site_design__wiki

No this is not an ascii format file. The file needs to renamed or I can send you the pt4 file via email. There is an import option  for Caice import formats . I captured the right click menu below.

I get an error. I think there is something wrong with the file

Thanks Nico. I had feeling it was the pt4 file causing the issue. Thanks for trying!

Nico the issue is with the DTM boundary inside the Caice data. Geopak (SS4) is dumping on the translation due to the DTM boundary chain. Caice is an old piece of software that can be difficult at times to operate in OS above XP. The issue is that there is decades of FDOT survey data in this format. Much of this data should be migrated to OpenRoads Survey.

GeoPak should fix the translation bug. This issue is well documented by FDOT.

Any ideas?

Cliff

there is no defect. I found documentation from the FDOT that states

When dragging and dropping a CAiCE PT4 file into Bentley Survey the field book

automatically takes on the name of the CAiCE project. Note that the PT4 file is

not a stand alone data file. It must be in the CAiCE project folder for this to work.

 

I tried this with a full caice project and it works with no problem. You have to select the pt4 file from the project folder..

see image

Nico the issue only seems to occur on longer (more points) DTM boundary chains in Caice. It appears to fail when the clip chain has somewhere between 50 and 100 points. I did speak at length with FDOT central office about the process. I'm now aware of the need to have the complete Caice dataset in the same directory as the pt4 file (the pt4 is a pointer file). This specific issue was resolved by deleting the dtm clip chain in Caice. The pt4 was successfully imported to SS4 once this was step was taken. I can provide the complete Caice database if you have a way to transfer a 24 meg zip file. Let me know and I will setup a temporary ftp site.

Cliff

Nico the issue only seems to occur on longer (more points) DTM boundary chains in Caice. It appears to fail when the clip chain has somewhere between 50 and 100 points. I did speak at length with FDOT central office about the process. I'm now aware of the need to have the complete Caice dataset in the same directory as the pt4 file (the pt4 is a pointer file). This specific issue was resolved by deleting the dtm clip chain in Caice. The pt4 was successfully imported to SS4 once this was step was taken. I can provide the complete Caice database if you have a way to transfer a 24 meg zip file. Let me know and I will setup a temporary ftp site.

Cliff

did you try with the complete project in the directory where the pt4 resides?

Yes that was my workflow.

====> Drag and drop pt4 from the (complete) Caice project directory.

That did not work with this data. I have done this several times over the last year with other databases.

My past success has been:

1. With my personal Caice data.
2. With smaller Caice projects provided by either consultants or FDOT.

My personal workflow with Caice did not involve clipping the final DTM in Caice. I always used Geopak to resolve the final surface and deliverables. That explains why I hadn't had any personal experience with this defect.

Many other Caice surfaces were not clipped so this defect hasn't been an issue. We are seeing more migration requests. There is no doubt this will become a bigger issue going forward.

Cliff

Hi Guys,
I have been seeing this for about 4 or 5 years. If the CAiCE database has a very large Survey Chain and I don't know how large, I will guess 50 points or more, the Import of CAiCE using the PT4 will fail. So far the only Survey Chains that I have found that are that large and have to be removed are the Boundary chains used to limit the DTM. The problem is no more complex than this. A large CAiCE chain will cause a CAiCE import to fail when using the CAiCE PT4 method.

ok. send the data and we can take a look.

Great info. thanks. looks like we have a workaround