GeoTrellis is a geographic data processing engine for high performance applications.
BTW, progress is being made: https://circleci.com/gh/s22s/rasterframes/1757
@pomadchin
yeh, sorry. Say you want to write out a bunch of DL chips as geotiffs, organized via some arbitrary partitioning scheme. Maybe some json sidecars for metadata (or not).
Another way of looking at it (from a RasterFrames perspective) is how might I write out unstructured tiles in a form that's not, say Parquet or ORC... some form that could be slurped up by other tooing.
Not really a hard lift... just wondering if you'd gone down that path before.
I'm trying to render a GeoTIFF as PNG, but don't know a priori if it is single or multi band. Getting an assertion failure on color when I attempt renderPng if I don't do the following:
val gt = GeoTiffReader.readMultiband("my.tif")
gt.bandCount match {
case 1 => gt.tile.band(0).renderPng.write("my.png")
case i if i > 1 => gt.tile.renderPng.write("my.png")
}I'm a GT newbie, so I'm sure overlooking something obvious, but is there not a single mechanism through the API to render an n-band GeoTIFF?
but if you have a nice API suggestion feel free to throw ideas!
thanks for the quick reply @pomadchin. I can work with it, it's just awkward, but I think it may have more to do with me needing to work with the library differently. For my purposes, I probably need to get a little smarter on combining bands since I'm ultimately going to want to render a single layer image.
The reason why the render function behaves differently is because renderToPng converts a multibandtile into a single banded png => it means that it needs to combine for instance 3 bands somehow to build a valid png; usually you want to visualize a 3 bands raster (rgb)
In case you have a single band raster it means that you already combined them into a valid band so you can render it
yes - I meant singleband, and yes combining into a single band for rendering is the goal. I sometimes receive single band tiffs (grayscale) and other times get RGB multi band tiffs. I was actually trying to use renderJpg to do this originally, but even when calling that from the multi band object it seemed to give me a strangely colored (maybe just blue and red without green) raster, so I had to fall back to renderPng which was giving an accurately colored output (albeit a much larger file). I hadn't gotten far enough with using renderJpg to see that the api mechanism was different.
Following up on my renderJpg issue, I finally figured out how to get a JPG with proper colors from an RGB multiband geotiff. I wasn't able to use the color() extension method on MultibandTile because it produces RGBA and ImageIO renderJpg wants RGB (and could probably work with ARGB). As before, I'm probably missing something, but I created a colorRgb function to solve my problem. Should I have done something different?
def colorRgb(t: MultibandTile): Tile = {
t.convert(IntConstantNoDataCellType).combine(0, 1, 2) { (rBand, gBand, bBand) =>
val r = if (isData(rBand)) { rBand } else 0
val g = if (isData(gBand)) { gBand } else 0
val b = if (isData(bBand)) { bBand } else 0
if(r + g + b == 0) 0
else {
new java.awt.Color(r, g, b).getRGB
}
}
}
:balloon: :balloon: RasterFrames 0.8.4 is Live! :balloon: :balloon:
https://github.com/locationtech/rasterframes/releases/tag/0.8.4
https://github.com/locationtech/rasterframes/releases/tag/0.8.4
@natonic77 indeed; it is a bit weird that you’re facing this problem, since renderJpg() for multibands uses this method https://github.com/locationtech/geotrellis/blob/master/raster/src/main/scala/geotrellis/raster/render/ColorMethods.scala#L46
which is pretty much the same as yours
renderJpg() works like ~ multiband.color().renderJpg
would you create an issue? I think awt.Color is pretty heavy for this map step though; you can do the same manually to avoid extra objects allocations
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f4b6ed53a82, pid=37772, tid=0x00007f315015f700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_112-b15) (build 1.8.0_112-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.112-b15 mixed mode linux-amd64 )
# Problematic frame:
# V [libjvm.so+0x6d0a82] jni_SetByteArrayRegion+0xc2
#
# Core dump written. Default location: /mnt/data08/yarn/local/usercache/guiet/appcache/application_1571662316912_1404/container_e54_1571662316912_1404_01_000002/core or core.37772
#
# An error report file with more information is saved as:
# /mnt/data08/yarn/local/usercache/guiet/appcache/application_1571662316912_1404/container_e54_1571662316912_1404_01_000002/hs_err_pid37772.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Got this error while trying to load las file using :
val las = spark.read.format("geotrellis.pointcloud.spark.datasource").option("path","hdfs:///user/guiet/Orleans_36_rue_de_la_Borde_Fond_L93.las").load()
I need to load las file into Hive
maybe I can use
val testDir = new Path(s"hdfs:////user/guiet/test_geotrellis/USGS_LPC_LA_Barataria_2013_15RYN6548_LAS_2015.las")
val numPoints = HadoopPointCloudRDD(testDir)
But how can I convert RDD to DataFrame
1.6g is not a big las file....I need to load a 50giga las file I am worried
@fguiet yo Im very sorry that you faced this issue, it is a known bug / feature / limitation of the current geotrellis-pointcoud implementation. geotrellis/geotrellis-pointcloud#14
it will require much more time and thinking to allow arbitraty file sizes to work with
as a workaround you can split them into smaller chunks via pdal-pipeline
but at this point I don’t have time to look into it; it is a pretty serious issue - so I would be happy to assist you if you would come up with some really good solution
Check Iqumuls library as it seems to be able to load big las file into Hive
worth a look at the implementation at the implementation
thank to point me this known limition
limitation