Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
chiuhow
@chiuhow
I could not get the jar file of the version of 2.5.0-SNAPSHOT for bigtable-datastore from maven repository even build from source. Do I miss anything or any steps I should follow?
Emilio
@elahrvivaz
due to licensing, we're not allowed to publish bigtable jars on the eclipse infrastructure, so there aren't any snapshots available. if you build from source you have to use -Pbigtable
jg895512
@jg895512
quick question.. when we add an attribute index via the command line tools, there are "full" and "join" options (https://www.geomesa.org/documentation/2.0.2/user/accumulo/commandline.html#add-attribute-index). What is the option selected when you select index=true on a converter? Is there a way to change it?
sorry, when you select it on a simple feature definition (all one big config file for me).
such as in this code snippet here: https://www.geomesa.org/documentation/user/convert/common.html#defining-simplefeaturetypes where index = true for name. Is that doing a full or join index?
Emilio
@elahrvivaz
yeah that changed at some point so make sure you're looking at the right version of the docs
seems like you are
jg895512
@jg895512
Thanks @elahrvivaz . One more related (ingest on accumulo) question. .. if I have source data coming in to different directories and I started command line ingest on one directory, but then I started getting data in a second directory..could I start command line ingest with the same catalog/feature from this second directory? Or is it bad to ingest with more than one command line at a time? I don’t think there would be a problem with two command line ingests at a time for the same feature, ( just thinking it through), but I am curious what you think..
Emilio
@elahrvivaz
there shouldn't be a problem
James Srinivasan
@jrs53
you might end up with a weirdly mixed up CLI log file
don;t know if you might miss log entries
@jg895512 changed from join to full around 2.1ish
Emilio
@elahrvivaz
you can run GEOMESA_LOG_DIR=/tmp/foo ./geomesa-accumulo ingest to separate out the log files
James Srinivasan
@jrs53
ah cool
jg895512
@jg895512
Thanks!
geoHeil
@geoHeil

What is wrong with the locationtech maven repository? My build tool is showing me various POM parsing failures.

[Fatal Error] gt-geojson-21.1.pom:7:3: Elementtyp "hr" muss mit dem entsprechenden Endtag "</hr>" beendet werden.
[Fatal Error] gt-main-21.1.pom:7:3: Elementtyp "hr" muss mit dem entsprechenden Endtag "</hr>" beendet werden.

A reproducible example is here:
https://github.com/geoHeil/debugging-locationtech-repository

Note: this worked previously. I deleted all the cached jars today and noticed the problem.

Emilio
@elahrvivaz
eclipse has migrated all the locationtech-specific things to eclipse urls. the new ones are here: https://github.com/locationtech/geomesa#maven-integration
first it was the mailing lists, then the maven repos
Emilio
@elahrvivaz
with our upcoming 3.0 release, you won't need to use the lt/eclipse repo any more - the only thing still there currently is sfcurve, but Jim just published a new version to maven central
right
sorry about not communicating that better... we should probably send out an email or something
geoHeil
@geoHeil
Indeed, this is the solution. Thanks. Yes, an e-mail would have been great. Do you plan to publish to both repositories in the future? Or only the central one?
Emilio
@elahrvivaz
ah, I'm not sure... @jnh5y what do you think?
we usually publish to both but i'm not sure if the hudson job we use to publish to locationtech (now eclipse) is still working
James Hughes
@jnh5y
to be honest, I haven't completely decided
the one thing that I'd insist that @elahrvivaz and I do is publish the same artifacts to both
so that folks don't see signed artifacts with one sha on Maven central and different ones from Eclipse
that's the big thing I'd like to avoid
Emilio
@elahrvivaz
hmm, could we have an eclipse job that downloads them from central and uploads them to eclipse?
every maven build process is going to produce different shas due to the timestamp
even if the contents are the same
James Hughes
@jnh5y
yeah, I was thinking that having Eclipse mirror would be best
since the jars would be the same, the shas would be the same, right?
Emilio
@elahrvivaz
yeah, if we could mirror central... but is there a point if we're just mirroring? seems like the main point would be to have an 'official' eclipse version, but mirroring means it wouldn't actually host the artifact right?
James Hughes
@jnh5y
shrugs I suppose by mirroring, I mean that we'd have a job to copy from one to the other
geoHeil
@geoHeil
So locationtech is basically obsolete, eclipse should be used and in the future also it will be obsolete and the main repository will be maven central?
James Hughes
@jnh5y
Yes, the LocationTech repo is obsolete. Hopefully the redirects were somewhat helpful (but that seemed to have fussy / have problems)
We'll still have to figure out what we want to do with the Eclipse repo. I definitely like having GeoMesa, JTS, SFCurve artifacts on Maven central
it wasn't tooo bad to setup and now I'm committed to keeping that going as best I can
esh99
@whoami99

Hi Team,
I am working on Geomesa 2.3.0 and created a Filesystem datastore with different combinations of composite index configs like "daily-2bit", "daily-4bit", "hourly-2bit" etc. The directory layout of the composite index is clear to me.

https://www.geomesa.org/documentation/user/filesystem/partition_schemes.html

From the above reference looks like it is possible to enable attribute index in the FS datastore,
How does adding an attribute index effect the directory layout?
Is it possible to include attribute scheme in the composite scheme?
What would be the best practice to include an attribute index, create a composite scheme or maintain two separate data stores one for composite index and another for attribute index.

Emilio
@elahrvivaz
the attribute scheme will be the lexicoded attribute value for each feature, so for something like name you would have /alice, /bob, etc
you should be able to create a composite scheme with an attribute layout
best practice would really depend on your query patterns - if you want to have multiple indices with the FSDS you can use the 'routed-view' data store: https://www.geomesa.org/documentation/user/ds_views.html#routed-data-store-view
andrijz
@andrijz
could you please advise algorithm: having a set of points to build a polygon covering all of them?
Emilio
@elahrvivaz
that's called a concave or convex hull - there should be some implementations out there already depending on exactly what you want
geotools has some i believe
concave convex is easier to calculate
andrijz
@andrijz
thank you!