Bringing the scalability of distributed computing to modern geospatial software.
After adding the geowave plugin to the geoserver, tried to create the datastore from Geoserver admin console.
While creating the store only the dynamodb endpoint is specified, then how can we connect to the required tables in our aws account?
it uses your AWS credentials resolved through GeoServer to connect to dynamodb ... also it may be helpful to use geowave CLI instead of geoserver admin console which should setup the geoserver datastore exactly the same as the CLI
I tried to use region but getting this error
also, have you tried adding the dynamodb store using geowave's CLI?
I haven't tried it from cli
@rfecher I tried to create the store using geowave cli, it worked and not getting any error like with geoserver admin console.
But I am not clear how the store can be linked with a dynamodb table in the aws?
Our requirement is to create a geoserver layer from the geometrical data in dynamodb. Is that possible with geowave?
When trying from geoserver console, only the endpoint required and the parameter list not mentioning anything related to the aws credentials to access the dynamodb. So how the credentials are resolved by geoserver?
we use the DefaultAWSCrednetialsProviderChain for which there are a series of approaches for providing credentials. Here's some more docs on it.
I'm curious if anyone could help me understand the implications of this passage from 'theory':
At some point, with high precision, high dimensionality curves, the number of possible unit cells can become too large to deal with. In such a case, GeoWave optimizes this by treating the curve as a “lower cardinality” curve than it actually is. So the unit cell size might not be 1, but instead 64, 128, 1024, etc. This allows the user to still achieve high precision when selection windows are small but not spend an inordinate amount of time fully decomposing for large selection windows.
when constructing an index, are there knobs that can be turned to alter this behavior to avoid generating what are sometimes prohibitively large queries?
GeoHashes somewhat clearly explain the big idea around gridding. The wiki page may get to some of the ideas I'm talking about: https://en.wikipedia.org/wiki/Geohash
@moradology perhaps this code gives a good reference within geowave...the "knob" this description of "theory" is referring to is the constant "UNIT_CELL_SIZE"
basically unit cell size is a cap on the worst case amount of cells produced in decomposition (practically speaking it does not hit this worst case decomposition but it at least provides a ceiling) ... generally speaking when in multi-dimensional space the max range per dimension from the query range is sufficiently small enough to imply that decomposition could not exceed that unit cell size, you get a cell size of one and full decomposition, if you don't cap it though it could lead to exponentially extreme decomposition on large query windows with a high precision curve
I am aware of GeoWave's capability of storing and managing point clouds. But I haven't seen work that shares the performance benchmark of using GeoWave for point cloud data management. Are there any while paper or research paper in this. My objective is to compare the performance in terms of storage, loading and querying with other solutions such as PostgreSQL/PostGIS and Oracle.
could you please share it ? I found papers that say GeoWave provide facility to manage Point cloud data. But didn't find any work that has done experimentation with point cloud in GeoWave. The materials refer GeoWave as an example system. But I was unable to find a paper that use GeoWave for point cloud data management. could you please share it with me. many thanks!
@rfecher :tada:
interesting that the netCDF reader is giving you a GridCoverage2D for each band in the image ... so for term clairification a "Coverage name" refers to a homogenous gridded dataset (the same sample model, which can be multiple types, where each band is of a given type, but every grid position is going to have the same bands/types) and from my experience with multi-dimensional data using net CDF each dimension is a band, not a separate coverage ... basically, my understanding of your statement "using the geotools netCDF reader, i got a GridCoverage2D for each band in the image" is that for
n bands you got n single-band coverages rather than one n-band coverage. If thats the case, and you want a single multi-band coverage I've used geotools' BandMerge operation successfully before (just make sure you do it before ingesting into geowave so geowave gets a consistent representation of the coverage). Actually this is exactly one of the options available within geowave's landsat8 ingest so here's code referencing how to do exactly this
@rfecher Yeah i misused the terms, since i need to have a only a single multi-band GridCoverage2D to do preliminary operation before ingest, using the NetCDFReader i must use getGridCoverageNames() and for each coverage name i can call reader.read(converageName, PARAMS), as you said. I'm actually trying to use BandMarge operation but the problem is that i always get "Input Coverages must have the same data type" on almost all my netCDF files, cause the bands has different dataType and so i can't merge them. Do you have any suggests about it?
so I my understanding is the purpose of the band merge operation is to make a multi-band coverage from multiple different coverages with one (or more than one) band. It surprises me to hear that there are issues with geotools' band merge when the bands are of different data types (that just seems to arbitrarily limit the applicability), but I can't say I've ever really stretched it too much. I think I've at least merged perhaps a panchromatic band with a different resolution and numeric domain with other bands, but I'm not sure and I don't remember details. Regardless, it sounds like you're having an issue specific to geotools' band merge, which isn't really a core part of what geowave maintains. Seems like a good question for geotools devs. Also, I'd bet you'd have success with GDAL. Its pretty industry standard and robust for handling raster transformations such as a band merge.
I am new to Geowave and spatio-temporal data storage and querying in general. I have a use case where I need to store trajectories in geowave and perform queries like finding if a trajectory intersected with a polygon or with another trajectory, or finding all trajectories within a certain distance from a point. Any help in how to go about storing such data and querying would be very helpful.
Thank you
Thank you
@rfecher Not really. I went through the past posts and as far as I saw there is just a small discussion on a topic related to this.
As of now I was thinking of using the "m" dimension in the linestring and use the set of points with time as one entry in the table along with start time, end time etc. But am facing issues when it comes to linestring intersection with a polygon. The JTS library doesn't handle the "m" dimension well. It would be great if you could point me to some resources.
As of now I was thinking of using the "m" dimension in the linestring and use the set of points with time as one entry in the table along with start time, end time etc. But am facing issues when it comes to linestring intersection with a polygon. The JTS library doesn't handle the "m" dimension well. It would be great if you could point me to some resources.
so you don't need to attach the time directly to the geometry object ... if you're ingest vector data in the form of SimpleFeatures (basically all the geowave vector ingest formats and any vector data derived from geotools follows this format) you really need fields that are a Date attribute type. It will infer one of those fields is the timestamp, or if you have a Date field that starts with "start" and one that starts with "end" it will infer those are actually time range rather than an instantaneous time. You can manually configure the time fields as well, and here's instructions when using the CLI.
These time fields would be used appropriately for spatio-temporal indexing (and of course simple temporal indexing as well). Here's documentation for adding these index types through the CLI.