NITF support contribution

[Brad Hards]

As I've previously discussed with Micheal, I'd like to contribute the NITF
reader I've been working on (https://github.com/bradh/nitf-file-reader) to
Codice.

I see the NITF code (which I hope to turn into more than just a reader,
although that is the main short term goal) as having application both inside
and outside DDF. One potential outside use would be the core of a ImageJ data
source.

Now the hard part - a name.

The development name is nitf-file-reader, which is literally correct now, but
probably far from ideal in the longer term. I've been using
org.codice.nitf.filereader as the namespace during development.

I think there could be a case for considering it the start of something like
Codice Imaging, so this would be Codice Imaging : NITF. That would allow for
future work (e.g. some future remote sensing format or RAW metadata support).

We could also think larger (although Codice Data seems a bit vague).

Assuming something like Codice Imaging, the namespace could look like
org.codice.imaging.nitf.core for the code I have now

That leaves space for a renderer as a separate package (which will likely need
AWT, JAI and other dependencies that won't be needed for basic metadata
extraction):
org.codice.imaging.nitf.render

It also leave room for the non-production tools like the metadata comparison
tool as:
org.codice.imaging.nitf.engtools

So the project in a JIRA sense would be Codice Imaging (as a peer to DDF,
OpenDX, Opendj), with components for nitf-core, nitf-render, nitf-engtools.

I'm really trying to put this out as a starting point for discussion. Does it
look reasonable? Suggestions for improvement? Is it completely overcooked?

Brad

[Kit Plummer]

Hey Brad.

This is awesome.  Why is the name always the hard part?  :)  Technically I think you’re right on with the extensibility.

I believe this goes hand in hand with the “Marketplace” discussion.  As far as contributions go, there’s two ways (in my mind) to make it happen.  It is either a first-class citizen in the DDF distribution, or it’s a Feature that can be installed from the Administrative interface (from the Codice-hosted repo).  What sayeth the DDF PMC?

As far as Codice goes…let’s answer the first question first.  But, is this something that makes sense as a sub-project?  From Brad’s commentary and what I know about the NITF arena I can imagine input/contributions from others.

Kit

--
You received this message because you are subscribed to the Google Groups "Codice Foundation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codice-foundat...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Vettraino]

My opinion is, this should definitely be a top level project with no direct dependencies on DDF.  It should be focused on all things imagery as Brad mentioned.

DDF can (and should) have a component which leverages the imagery code, and that of course should live in under the DDF project.

Jeff Vettraino
Cohesive Integrations
jeff.ve...@cohesiveintegrations.com
(602) 332-1377

[Michael Menousek]

This is a good case to incubate as a TLP because it can (and will) live on its own.  It is simply a Java NITF (or Imaging) library -- the same that everybody has been looking for, and it has no tie to DDF.  There would certainly be a DDF subproject that would use it, but the library itself is needed.

Just look at the recent posts about use of Nitro and how it required additions to the System path to run.  With a pure Java library, things just work.

I also like the name "Codice Imaging" as long as it is understood that other imaging libraries would be admittable as subprojects.

Michael

[Brad Hards]

On Wed, 6 Aug 2014 07:49:07 AM Kit Plummer wrote:
> I believe this goes hand in hand with the “Marketplace” discussion. As far
> as contributions go, there’s two ways (in my mind) to make it happen. It
> is either a first-class citizen in the DDF distribution, or it’s a Feature
> that can be installed from the Administrative interface (from the
> Codice-hosted repo).

I should have linked to the DDF-related feature in my original post:
https://github.com/bradh/ddf-nitfinputtransformer

I'd see that moving into DDF eventually.

The discussion here is just about the NITF library that supports that DDF-
related feature.

Brad

[Brad Hards]

There hasn't been any active dissent in the last week, so I'm taking that as
"approved, lets start incubation".

As the next step, can someone with enough karma on the Codice JIRA instance
create the "NITF Imaging" project and give me rights to create components
under that project?

That will allow me to move the open tasks list out of my (paper) notebook...

Brad

[Michael Menousek]

All set Brad!  You are admin of the new IMG space.

https://tools.codice.org/jira/browse/IMG/

Let me know (via a direct email) if you need anything else.

Decided to respond to the group so it'd be semi-official :-)

Michael

[Kit Plummer]

+1 coolness!

From: Michael Menousek <michael....@connexta.onmicrosoft.com>
Reply: codice-f...@googlegroups.com <codice-f...@googlegroups.com>>

--

[Brad Hards]

On Mon, 18 Aug 2014 07:46:27 AM Michael Menousek wrote:
> All set Brad! You are admin of the new IMG space.
>
> https://tools.codice.org/jira/browse/IMG/

Thanks.

> Let me know (via a direct email) if you need anything else.

I'll probably need some help to change settings that require global admin
rights later, but I need to explore what I have now, and will work out what
the right target is.

One possibility would be to put a "Codice" project on Jira, to track these
infrastructure things.

> Decided to respond to the group so it'd be semi-official :-)

ack.

Brad