Bringing the scalability of distributed computing to modern geospatial software.
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.
this is assuming you're using the CLI though, all the same functionality should be available programmatically
For my use case I need to associate certain timestamps with each point and string those points to a line to form a trajectory. And when an intersection with a polygon is calculated I need those exact timestamps back if the points properly coincide or the timestamp of the closest point in the linesegment. I am not sure if setting a range for a single trajectory would help me achieve this.
it looks like you may be using geowave's python bindings? GeoWave's python docs have an example on the main page of a spatial index with spatio-temporal data (a SimpleFeature with a date field) ... it looks like all that would change from that example is to use a spatio-temporal index instead and you should at least have a starting point. Then the QueryBuild code in python could use spatiotemporal constraints per this documentation
Yes if I consider the points as separate entities I can model them as per the example. But then this would not cover the case where in I need to know if a trajectory intersected with a polygon. For that I need to model the individual points as a line and then find the intersection. I am looking at a case where there is a polygon and a set of points that are supposed to be part of a trajectory. If none of the points actually intersect with the polygon, yet a line joining those points would pass through the polygon. For such use cases I need to model my data as set of linestrings in which case I end up with the problem I have mentioned.
yeah, using geowave I'd suggest both. You could ingest the points with a timestamp in a spatio-temporal index for "exact coincidence" and alternatively if closest approach is needed instead, you could have a separate "feature type" for the linestring and time range. GeoWave out of the box won't perform the closest approach algorithm although it'll give you quick access to just the overlapping spatio-temporal trajectories that match and you can find other libraries to utilize or roll your own algorithm to get the closest point of approach
also, PostGIS has this function built-in: https://postgis.net/docs/ST_ClosestPointOfApproach.html ... there are pro's and con's to PostGIS and GeoWave, 2 very different technologies that solve similar problems, but if you can satisfy all your requirements easier/better using PostGIS you should give that a shot
unfortunately 1.17 is not a binary compatible release :/ and in creates issues because of that
since all examples I found is relevent to point
another question is that possible to manage massive point cloud in geowave
thanks
one more questions does it support to store and index linestring/polygon with x,y,z-coordinate
regarding linestring/polygon x/y/z I think there should be many examples of linestring/polygon with x,y. We store/retrieve "Z" if any geometry has a Z component and it can be used for massive point cloud datasets although to index "Z" in either case requires some custom code outside of the general API (indices are discovered by the CLI using Java SPI, so you can inject any indexing scheme integrated throughout the application with some custom code, out of the box we support 2D spatial and spatiotemporal indexing).
if indexing X,Y and then post-filtering Z is sufficient for the linestring/poly x,y,z use case that should be pretty standard out of the box. But to interleave Z into the keys (ie. index) you'd have to add a new index to the app for that.
also regarding usage for point clouds there's locationtech/geowave#1799 someone else had raised about a month ago that could give some insight