Adam,

Was able to replicate your problem. It looks like there are minor issues with 
both gdalwarp and ParaView that together are causing the crash.

The first problem is that gdalwarp is not writing the units attribute correctly 
when outputting the coordinates in feet. Instead, the units are set to an empty 
string. This seems wrong. The attribute should be set to “ft” or “feet”. When 
you use gdalwarp to write units of meters, it correctly writes this attribute 
as “m”. This is probably a bug, but it shouldn’t cause ParaView to crash.

So you probably already see where this is going. NetCDF attributes of empty 
strings are odd, and the ParaView reader probably has never encountered one 
before. Lo and behold in this case the reader tries to pull a pointer out of an 
empty std::string, and std::string throws an exception.

I’ve raised a bug for ParaView 
(https://gitlab.kitware.com/paraview/paraview/issues/17173) and will look into 
fixing this. I’ll leave it up to you whether you want to contact the GDAL 
developers about the issue with gdalwarp.

-Ken

From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Adam 
Dershowitz
Sent: Monday, February 13, 2017 9:20 AM
To: ParaView@paraview.org
Subject: [EXTERNAL] Re: [Paraview] Paraview crashes with netCDF

I found a bit more information.  When pareview crashes, here is part of the 
crash log:

Application Specific Information:
terminating with uncaught exception of type std::out_of_range: basic_string
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib                 0x00007fffcb43add6 __pthread_kill + 
10
1   libsystem_pthread.dylib              0x00007fffcb526787 pthread_kill + 90
2   libsystem_c.dylib                           0x00007fffcb3a0420 abort + 129
3   libc++abi.dylib               0x00007fffc9efb85a abort_message + 266
4   libc++abi.dylib               0x00007fffc9f20c37 
default_terminate_handler() + 243
5   libobjc.A.dylib                 0x00007fffcaa2af33 _objc_terminate() + 124
6   libc++abi.dylib               0x00007fffc9f1dd69 std::__terminate(void 
(*)()) + 8
7   libc++abi.dylib               0x00007fffc9f1d9f2 __cxa_rethrow + 99
8   QtCore                             0x000000010db17d2d 
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 845
9   QtCore                             0x000000010db1ad97 
QCoreApplication::exec() + 199
10  org.paraview.ParaView             0x000000010b083fd2 main + 386
11  libdyld.dylib                   0x00007fffcb30c255 start + 1

Any idea why that happens with one feet, but not meters in an otherwise 
identical file?

-- Adam


From: Dershowitz Adam 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>
Date: Tuesday, February 7, 2017 at 11:58 AM
To: "ParaView@paraview.org<mailto:ParaView@paraview.org>" 
<ParaView@paraview.org<mailto:ParaView@paraview.org>>
Subject: Paraview crashes with netCDF

I have a geotiff file that I want to view in Paraview.  But, Paraview seems to 
not show the correct offset (0,0 instead of respected the offset).  The work 
around I have been trying is to warp it to the correct location using gdalwarp 
and to export it as a netCDF.  Then Paraview should be able to show it 
correctly.
But, I have run into a crash.
If I do this:
gdalwarp  -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc

then I try to open test.nc in Paraview immediately crashes.

While, instead if do this:

gdalwarp  -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc

then it opens fine.  The difference between these two files is that EPSG 3652 
uses feet (which is better for me, for this particular project) while 3651 uses 
meters.  Both appear to be valid NetCDF files.  I’ve tried both readers “CAM 
NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the 
same results.

I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3.  But, I have seen 
identical results on an older Mac with a prior OS.  I had also tried an older 
version of Paraview with the same result.

Any ideas why this consistently crashes Paraview, or what to do about it?  
Using netCDF was already a work around, and I willing to try others to view 
these files.  The offset and scale are important because I then need to put in 
other data that is in the correct location and units.

The files are too big for me to send to the mailing list, so I have not posted 
them.

Thanks,

-- Adam

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Reply via email to