Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> accumulo geo


Copy link to this message
-
Re: accumulo geo
I'm fine with whatever guidelines you all put together regarding
contribs.  My plugin is built against an older version of Accumulo so
will need to be ported to the latest version.  Initially, I'm just
inquiring into whether anyone has interest in geo related functionality
and has thought about an architecture for providing that kind of API.

On Fri 28 Oct 2011 05:53:25 PM EDT, [EMAIL PROTECTED] wrote:
> At Karaf we set up all of the contribs as their own sub-projects. We
> release them seperately and ensure that the core karaf project doesn't
> depend on the contribs. This way, if a contrib falls behind, we don't
> have any depedencies and can easily remove them. I would suggest
> creating an accumulo-geo sub-project for this reason.
>
> Mike Van
>
> ASF Committer
>
> ------------------------------------------------------------------------
>
> *From: *"Todd Lipcon" <[EMAIL PROTECTED]>
> *To: *[EMAIL PROTECTED]
> *Cc: *[EMAIL PROTECTED]
> *Sent: *Friday, October 28, 2011 5:06:48 PM
> *Subject: *Re: accumulo geo
>
> Hey Billie,
>
> A word of warning on contribs: one thing to be wary of is the "drive
> by contribution". We found in Hadoop and HBase that many contribs were
> added to Hadoop as part of a research project or other "passing
> interest", and then not maintained. Since the core committers had very
> little knowledge of the contrib components, and the authors were no
> longer actively maintaining them, they ended up as rotting appendages
> to our codebase. Users would run into issues and then we'd be unable
> to help them work through them - not good for anyone.
>
> In HBase, we ended up ejecting our contribs to github. This worked out
> well - some have done OK, others have died off. But the ones that died
> off had no maintainers anyway - so better to let them die on their own
> than drag them forward unmaintained in SVN. We've always had the
> stance that, if an HBase-related project on github or elsewhere wants
> to enter contrib, then they can do so provided they have active
> maintainers who are truly committed to long term maintenance. For
> example, our REST server module graduated from contrib into a core
> part of our project, since its maintainers are also HBase committers
> who run the stuff in production.
>
> Not sure if this is "Apache-like" -- just my opinion as another developer.
>
> -Todd
>
> On Fri, Oct 28, 2011 at 1:52 PM, Billie J Rinaldi
> <[EMAIL PROTECTED]> wrote:
> > Anthony,
> >
> > It sounds interesting. I have been thinking about how to start
> fostering a set of contrib projects for Accumulo, but am unsure how we
> would manage such things effectively (e.g. how do we make sure they
> work? are they versioned and released with Accumulo?). Perhaps we
> could begin to work this out with your project.
> >
> > Billie
> >
> >
> > ----- Original Message -----
> >> From: "Anthony Fox" <[EMAIL PROTECTED]>
> >> To: "Accumulo dev" <[EMAIL PROTECTED]>
> >> Sent: Wednesday, October 26, 2011 4:30:40 PM
> >> Subject: accumulo geo
> >> All,
> >>
> >> I would like to gauge the interest in an extension to Accumulo to
> >> enable
> >> geospatial capabilities. Currently, I have developed a schema for
> >> storing
> >> raster data as tiles in Accumulo and a plugin to Geoserver that allows
> >> Accumulo tables that use the specified schema to be exposed as WMS
> >> layers
> >> for importing into a GIS. This is a natural fit for Accumulo since the
> >> individual tiles are not large but the aggregate set of tiles that
> >> make up
> >> a single layer can become very large. Accumulo packages those tiles
> >> into
> >> blocks and distributes them around the cloud for quick access and
> >> redundant
> >> storage. The implementation is in an early state.
> >>
> >> I am currently investigating the feasibility of implementing an API
> >> for
> >> storing, querying, and processing vector data in Accumulo. I would
> >> like
> >> the API to be able to answer nearest neighbor queries, perform