Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [geomesa-users] future plans

 Hi Elad,

Yes, GeoMesa is under active development. 

We are working with LocationTech, a working group of the Eclipse Foundation, to open source GeoMesa.  As part of that process, the Eclipse legal team has been reviewing our dependencies to make sure they are not only open source, but business friendly and well maintained.  

Unfortunately, this has been a rather involved process.  GeoMesa has had enough features for a '1.0' release for awhile.  We do feel that completing the Eclipse Foundation's incubation will be beneficial.  In short, cutting release candidates is our best intermediate option.

In terms of documentation, our tutorials at geomesa.org should help some.  We do owe more complete documentation, and I am working to organize the team for catching up and staying on top of it.  

Most of the access to GeoMesa is mitigated by the GeoTools DataStore api.  I mention that to say that 80% of GeoMesa use boils down to creating a SimpleFeatureType, mapping your data into SimpleFeatures, writing those to GeoMesa, and then creating CQL filters to query for subsets.  (And those steps are demonstrated in the GeoMesa QuickStart*.)

Typically, I believe that providing code examples and tutorials will likely be more beneficial than Scaladocs.  That said, working with GeoMesa's Spark support is one of the areas where both would likely be beneficial.  

Yes, we will be supporting Accumulo 1.6.  We are planning to target CDH versions as well.  Which version are you using?

As for Joda and Spark, I have two suggestions...

1.  You can try rebuilding GeoMesa with the Joda-time which your version of Spark is using.  You would only need to update the version of Joda-time in the root pom.xml.  

If you still have the same trouble, then there may be conflicting Joda-time versions between Spark and a Hadoop or other library.  

2.  We could try shading GeoMesa's Joda-time dependency.  Arguably, this could be done in the geomesa-compute sub-module as we build up the fat jar which provides the kitchen sink bundle of dependencies for Spark use.

This option isn't terribly elegant, but it may cover many situations without hunting down versions of dependencies.

I definitetly want to get you going on Spark since you seem most of the way there.  Can you try out the first option?  If it doesn't work out, I'll cook up a quick branch to shade Joda-time.

Thank you for the great questions,  

Jim

* https://github.com/geomesa/geomesa-quickstart



----- Original Message -----
From:
"Geomesa User discussions" <geomesa-users@xxxxxxxxxxxxxxxx>

To:
"geomesa-users@xxxxxxxxxxxxxxxx" <geomesa-users@xxxxxxxxxxxxxxxx>
Cc:

Sent:
Sun, 22 Mar 2015 14:28:09 +0200
Subject:
[geomesa-users] future plans


Hi,
I am looking for a distributed database with spatial indexing capabilities.
Is GeoMesa under active developement?
Will it be released officially, with more extensive documentation (scaladocs?), and when (approximately)?
Will Accumulo 1.6 be supported (we use CDH)?
Also, a more specific question - when deploying a Spark GeoMesa-based application to the CDH cluster using spark-submit, some of the dependencies (to my knowledge, the Joda library) conflict, and I get a "NoSuchMethodError: org.joda.time.DateTime.<init>..." from index.scala:37.
I guess Spark uses a different Joda version, is it possible to make GeoMesa recognize its own version?

Thanks,
Elad

Back to the top