I did attempt to upgrade one of the
existing systems to this version for that fix for indexed
columns and the IN clause.
The geotools version seemed to match fine.
It was a working system running against accumulo 1.6.0 and
using GeoMesa 1.2.0 and GeoServer 2.8.1 I built from source
and I am attempting to go from GeoMesa 1.2.0 to GeoMesa
1.2.2.
It did not work, I cannot render data via
geoserver currently.
I shut everything down and placed the
geomesa-accumulo-distributed-runtime-1.2.2.jar on the accumulo
tablet servers and removed the 1.2.0 version of that jar.
For GeoServer I had taken the current war
and then overlayed the jars in the
geomea-accumulo-gs-plugin-1.2.2-install.tar.gz into the
existing geoservers WEB-INF/lib directory. I removed any of
the 1.2.0 based geomesa jars, I believe for imageio*, I had
to delete some older jars for that to be replaced by a newer
version of those same jars. I also noticed that the one jar,
geomesa-utils-gs-plugin-1.2.0.jar, seemed to become
geomesa-utils-1.2.2.jar. (It is a class in this jar that is
giving me issues on retrieving data via GeoServer to render as
a WMS tile.) and then started up accumulo stack and then
geoserver.
So when I took an existing configured
geoserver layer (backed by an existing geomesa accumulo store)
and tried to render the data I got a stacktrace that basically
started as:
[geotools.rendering] –
org.locationtech.geomesa.utils.geotools.SimpleFeatureTypes$.encodeType(Lorg/opengis/feature/simpleFeatureType;)Ljava/lang/String;
Java.lang.NoSuchMethodError:
org.locationtech.geomesa.utils.gotools.SimpleFeatureTypes$.encodeType(Lorg/opengis/feature/simple/SimpleFeatureType;)Ljava/jang/String;
at
org.locationtech.geomesa.accumulo.index.Strategy$.conifgureFeatureType(Strategy.scala:141)
at
org.locationtech.geomesa.accumulo.index.STIdxStrategy$$anonfun$conifgureIndexIterator$1.apply(STIdxStrategy.scala:177)
at
org.locationtech.geomesa.accumulo.index.STIdxStrategy$$anonfun$conifgureIndexIterator$1.apply(STIdxStrategy.scala:177)
at
scala.Option.foreach(Option.scala:257)
at
org.locationtech.geomesa.accumulo.index.STIdxStrategy.conifgureIndexIterator
(STIdxStrategy.scala:177)
….
When I tried to configure a new store and
layer in GeoServer to an already ingested GeoMesa table it
gave the same error. I then ingested new data again (ingested
fine). Configured another new store and layer in GeoServer
but got the same error.
So in looking at that class,
SimpleFeatureType.scala
In 1.2.0
def encodeType(sft: SimpleFeatureType):
String =
….
In 1.2.2
def encodeType(sft: SimpleFeatureType,
includeUserData: Boolean = false): String = {
…
So there is a difference in signature.
I have not been able to find that I didn’t
upgrade something correctly. Did I need to go from
1.2.0->1.2.1->1.2.2 or does that suggest something I
missed when I rolled the upgraded jars out?
Thanks,
Diane
On 05/19/2016 12:46 PM, Emilio Lahr-Vivaz wrote:
>
>Hi Diane,
>
>TL/DR: all versions of GeoMesa should
be backwards compatible going back to around Mar 30, 2015 (you
need to make sure your >jar versions match across all your
clients/servers, though).
>
>That said, we often improve our
indexing, which you won't be able to take advantage of without
migrating or re-ingesting your >data. If you're interested
in migrating it, we have a map/reduce job that you can run,
detailed here:
>
>http://www.geomesa.org/documentation/developer/modules/geomesa-jobs.html#updating-existing-data-to-the-latest-index->format
>
>The Z2 index is a case where we have
improved our indexing - for spatial-only queries, the new
index tends to be 2-4 times faster >than the old geohash
index, so it might be worthwhile to re-ingest.
>
>Thanks,
>
>Emilio
>
>On 05/19/2016 12:26 PM, Diane Griffith
wrote:
>
> Jim,
>
>
>
> What does the following in the release
change log of 1.2.2 mean:
>
>
>
> * GeoHash index replaced with a Z2
index.
>
>
>
> Will everything (GeoServer store
querying data from existing ingested code under 1.2.0) sill
work once I upgrade both the accumulo side and libraries in
GeoServer?
>
>
>
> Will I need to re-ingest for a new
index once I upgrade?
>
>
>
> Or if I wanted to add data to the
existing feature I already set up, will I have to change my
ingest code (does it still support the old index)?
>
>
>
> If there is a specific example that
helps me understand this part of the new release let me know.
>
>
>
> Thanks,
>
> Diane