You've got it
pretty much spot on. There aren't any tricks right now that
would let you index a non-default geometry. However, you can
add indices after schema creation. That functionality has not
been in an official release yet, but it is in the current 1.2
and 1.3.x branches.
Thanks,
Emilio
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
_______________________________________________
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
