MBoustani / GISCube

Web Based GIS Application
Apache License 2.0
44 stars 11 forks source link

TIFF files not showing in Visualizer #56

Open wenzeslaus opened 9 years ago

wenzeslaus commented 9 years ago

I've tried a TIFF file from:

http://courses.ncsu.edu/mea582/common/GIS_anal_grass/lc96ras_cut.tif

but it did not showed up in Visualizer, it was visible everywhere else including the basic metadata. The same for TIFFs from Raster maps in GeoTIFF format collection:

http://www.grassbook.org/data_menu3rd.php

The TIFFs are in North Carolina State Plane Meters coordinate system. The projection definition should be OK (it is recognized by some other tools).

I used Vagrant installation for the test.

MBoustani commented 9 years ago

When you upload a GeoTIFF file, by going to visualization page GISCube on background starts generating tile, so it may take time depend on the size of TIFF file. By selecting your raster in visualization page, map does not automatically zoom on your GeoTIFF, so you have to manually zoom in the location to think is GeoTIFF and you should be able to see the tiles. I am working on map auto zoom when you select a raster (it works for vector).

Please try zooming on TIIF area on map and let me know if it shows up.

wenzeslaus commented 9 years ago

I zoomed to where it should be (Raleigh, NC, USA). I cannot be sure if I wait long enough but was trying it more than once.

MBoustani commented 9 years ago

Here is the error I get on you raster file, can you help me solve the issue?

gdal2tiles.py ..../GISCube/gi/giscube_app/static/uploaded_files/lc96ras_cut.tif lc96ras_cut
Usage: gdal2tiles.py [options] input_file(s) [output]

gdal2tiles.py: error: Please convert this file to RGB/RGBA and run gdal2tiles on the result.
wenzeslaus commented 9 years ago

When I try with lc96ras_cut.tif on (L)Ubuntu with standard packages, I get:

gdal2tiles.py ../lc96ras_cut.tif lc96ras_cut
Usage: gdal2tiles.py [options] input_file(s) [output]

gdal2tiles.py: error: Please convert this file to RGB/RGBA and run gdal2tiles on the result.

From paletted file you can create RGBA file (temp.vrt) by:
gdal_translate -of vrt -expand rgba ../lc96ras_cut.tif temp.vrt
then run:
gdal2tiles temp.vrt

So I did:

gdal_translate -of vrt -expand rgba ../lc96ras_cut.tif temp.vrt
gdal2tiles temp.vrt

And I got:

ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files. Is this a valid
EPSG coordinate system?
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
Generating Base Tiles:
0...

Tiles were generated but they are not referenced right, so I don't see the data in openlayers.html. The EPSG is 900913 (http://epsg.io/900913) which is a non-standard code, now replaced with EPSG:3857. The data haven't been updated for a while but GRASS GIS can import the files (I'm not sure if, it might be using different 'support files' but I found none in the source code). Also, there can be some other non-standard codes in use besides 900913.

So first thing is that it seems that some GeoTIFFs might need more care before gdal2tiles, or create a feature request for gdal2tiles to deal with it automatically (it's a script anyway). Another thing is that for the system setup it might be crucial to get the most comprehensive set of 'support files' for PROJ.4 and GDAL.

With the files from grassbook.org, I got the same projection issue and an error:

$ gdal2tiles.py ../ncrast/landuse96_28m.tif landuse96_28m
ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
Traceback (most recent call last):
  File "/usr/bin/gdal2tiles.py", line 2262, in <module>
    gdal2tiles.process()
  File "/usr/bin/gdal2tiles.py", line 472, in process
    self.open_input()
  File "/usr/bin/gdal2tiles.py", line 844, in open_input
    self.out_ds.SetMetadataItem('NODATA_VALUES','%i %i %i' % (self.in_nodata[0],self.in_nodata[1],self.in_nodata[2]))
IndexError: list index out of range

I don't have any suggestion here, perhaps write to GDAL mailing list.

MBoustani commented 9 years ago

Thanks @wenzeslaus.

I have updated the style of GISCube recently and would like to hear some feedbacks. Can you please git pull the recent version in GISCube folder on your VM and let me know how the app looks like? Also I would love to hear from you what are important tools missing in Tools page that I can add.

wenzeslaus commented 9 years ago

I like the tree for organizing tools. In combination with search that's what seems to work best for GIS. I don't like the different backgrounds - very dark and very light. It should be all light (different shades of light gray) for accessibility reasons.

I tried with (some older version of) QGIS sample data (http://docs.qgis.org/2.6/en/docs/user_manual/introduction/getting_started.html#sample-data). Shapefiles worked but there was a lot of other not supported formats (especially .img and GML). I did not test with the grassbook.org data, I guess it is still the same. Providing some files known to work with GISCube (and used in the documentation) would be really helpful. Using sample data from some OSGeo project (GRASS GIS, QGIS, OSGeoLive) is a good idea.

I had to redo the VM (vagrant up) the web app in the web app can't start after #55. Is there a way to start new session/user or delete the data?

The missing tools are for a longer discussion, so I don't want to mess this issue with it, however basically the question is what type analysis you want to support. For me the tools for data conversion are not really important, they just necessary. Look for example at GRASS GIS manual to see the wide range of tools (http://grass.osgeo.org/grass71/manuals/) or QGIS Processing.

MBoustani commented 9 years ago

@wenzeslaus I like the idea of providing set of datasets that are good to try the GISCube at first, but in general GISCube meant to work with all data as long as the format is supported. At the moment Shapefile, GeoJSON, GeoTIFF, KML, netCDF and HDF files are supported. I still don't know why the server breaks when you do some processing? but you don't need to redo the VM installation as you can start the server again.

wenzeslaus commented 9 years ago

Sure GISCube is meant to work with all data but the point is that GIS data are usually so bad that if you want people to try your SW it is good to give them data which were actually tested with the SW. OSGeo projects are pretty good in interoperability thanks to GDAL/OGR (well, if you have the right projection definitions) but proprietary SW is usually creating data in some specific ways (this may apply also to standardized formats). You don't have to create custom one, just use some of the QGIS, GRASS GIS or OSGeoLive datasets and add some netCDF and HDF files.

wenzeslaus commented 9 years ago

It is not clear which steps I should do to restart the server (and perhaps clear the data), please point me to the documentation.

For the processing braking the server, do you have some automated tests (unittest, ...) which can show when it works?