So the
workaround I heard (what to talk through what I heard we
needed to do) is:
-
We would have 2 schemas in one
table/catalog
-
We ingest once to primarySchema that
has the point marked as the default geometry with an * in
the schema string next to that point name with no polygon
geometry on that schema and let it build the Z3 and Z2
indexes
-
We ingest the data a second time
against another schema (so different simple feature type
name) that does not have a point geometry and has a polygon
geometry with an * next to it and could disable the non XZ
indexes. (via schema by adding
geomesa.indexes.enabled=’records,xz3’ or by using the
org.locationtech.geomesa.utils.geotools.SftBuilder.SftBuilder
and the .withIndexes(List(“records”,”xz3”,)) call. So will
that or will that not duplicate the data in the records
table? (Yes they will have the same primary id)
-
We would have to publish 2 different
layers in geoserver one for each simple feature
type/geometry
-
Then we would have calls to render
each simple feature type (via WMS), always to the primary
schema/simple feature type that has the point and then a
call to the secondary schema/simple feature type when we
wanted to render ellipses. For the WFS call I believe we
only care about getting the original data of the primary
schema (not the data with the polygon geometry in it). If
we wanted the polygon geometry then we could have added it
as a secondary geometry on that primarySchema/simple feature
type and the data would be there.
-
Those Z2/Z3 and XZ2/XZ3 are only
created on schema create not a way to do that after the
fact.
Any other
workarounds you call can think of, a way to trick it to
build the other indexes on secondary geometries or not at
this time?
Thanks,
Diane
Hi Diane,
Currently we don't support indexing secondary geometries. You
can query on them, but it will not be optimized (if you are
doing a mixed query with other predicates this may be
acceptable).
As a work-around, you could ingest your data a second time
with the second geometry marked as the default and with a
different type name. If you keep the same feature ID, you
would be able to effectively query both geometries, although
you would need some logic to route your queries to the
appropriate simple feature type. You can even disable all
other indices except the XZ* ones on the second ingest, in
which case you won't be duplicating entries on disk.
Thanks,
Emilio
On 10/19/2016 01:57 PM, Diane Griffith
wrote:
We are in the process of upgrading to
Geomesa 1.2.6 because we have point geometries and secondary
non-point geometries on our data (currently polygons but
expect to have line strings as well as additional data to
the point).
In looking at the Data Management section
for 1.2.6, I felt it implied by default it will see it is a
non-point geometry and then will create the XZ2 and XZ3 (if
there is time) indexes on createSchema.
So my questions are:
-
If a polygon geometry exists
but is not the default geometry for the schema (a point
currently is the default geometry), will it recognize there
is second geometry, a polygon, for example, and then create
XZ2 and XZ3 indexes on it?
-
If it will support indexing
additional geometries beyond the default geom (the point)
for one schema, is there a job one could run if the
schema/catalog was created pre 1.2.5+ geomesa?
We want to get better performance for our
ellipse/polygon rendering. As you can tell our current
approach was to have one schema that has both the point and
polygon. Curious if the indexing enhancements of 1.2.5+
will help if it is in the same schema or if we need to split
ellipses/polygons into their own schema where they are the
default geometry to get better indexing on them. I was
unclear if having all geometries in one schema would
hurt/negate our ability to leverage the new indexes or if
there was a way to tell it to create those indexes as well.
Thanks,
Diane
_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.locationtech.org/mailman/listinfo/geomesa-users