On Thu, Mar 18, 2010 at 11:35 PM, Mccleese, Sean W (388A) < [email protected]> wrote:
> Hey everyone, > > Just to follow up: I'm also subscribed to all the SIS lists (dev, user, > commits, private). > My comments are below: > > Patrick wrote: > > There are a couple of things I'd like to throw out there as ideas, let me > know > > what you think of them > > * Create a configuration factory > >> * Allow you to specify projection methods > > I totally agree with this. That would be hugely helpful for the various > sorts of use cases I think we're going to encounter moving forward. A lot of > the frameworks I've seen so far make far too many assumptions (or, simply, > try to make things too simple for their own good) on what sort of > projections you're going to be using (see: JTS). Putting some facility > upfront to specify that in a simple standard way would be a great first > step, I think. > > Chris wrote: > - Come up with a simple Object diagram: Point *...*, Coordinate System 1 > ... > * Projection, ... > > - Build a framework that takes in basic Java data types and converts them > to > our o.a.sis.core.Objects > Like java Point to SIS Point? > - Provide all of the distance functionality (point/radius, bounding box, > polygon) > - Provide translation mechanisms between coordinate spaces > - Provide a simple XML/JSON format for points to take as input and produce > as output > > +1 to this as well. It would be awesome to have a native XML/JSON > input/output factory. That would be awesome for the stuff we're trying to do > here at JPL and, I imagine, a lot of other uses in the community. > > +1 think that we should keep it simple, as output writers often become complex and restrictive very quickly > One addition: I think it would be awesome if we, natively, supported some > sort of elliptical / swath orbit polygon functions. Right now there's all > sorts of ugly stuff you have to do to fit that into the polygon paradigm > that so many frameworks force you into. I think that would really go far in > making SIS a go-to application for a lot of under served communities right > now. Anyway, just throwing that out there. > Yeah, makes sense as a corridor, which would be a range between 2 polylines, would the definition of it make sense as the center vertexes of the path, and a width? > -Sean > ________________________________________ > From: Mattmann, Chris A (388J) [[email protected]] > Sent: Thursday, March 18, 2010 10:12 PM > To: [email protected] > Subject: Re: Alrighty then > > Hey Patrick, > > I'm reply to list since I think we're all on sis-...@incubator: > > > So the list emails are set up, I believe we have commit karma, need to > check, > > I just got out of ER yesterday so taking things a little easy for a > couple of > > days. > > Sorry to hear that! I think karma is set up for everyone. Please check out: > > https://svn.apache.org/repos/asf/incubator/sis/ > > And start trying to commit. If you see any issues, just let a mentor know > -- > they should be able to fix for us. > > > Can folks subscribe to the following lists so we don't have to maintain > this > > list? > > [email protected] > > [email protected] > > [email protected] > > +1. I think everyone is on the list -- for a sanity check, could everyone > reply to the list saying you are here? > > > > > For mentors, committers, etc. > > [email protected] > > +1, done on my end. > > > > > Does anyone know how to get MarkMail subscribed ? > > Already done! Check out: > > http://markmail.org/browse/org.apache.incubator.sis-dev > http://markmail.org/browse/org.apache.incubator.sis-commits > > All good! > > > > > As for where we are with software, right now we have an ok framework for > > cartography style searching / coordinate system, a poly-line, and convex > hull > > method. > > Yep, we need to take the first step at porting that code into the o.a.sis.* > framework. I've reported SIS-1 for that. Was hoping to have a second last > weekend to make some headway but haven't found a chance yet. If someone > else > does or wants to take the initial step at moving it over from Sourceforge, > by all means. Otherwise, I'm thinking maybe this weekend I'll have time. > > > > There are a couple of things I'd like to throw out there as ideas, let me > know > > what you think of them > > * Create a configuration factory > >> * Allow you to specify projection methods > > +1 > > >> * Custom planetary radii (maybe Enumerate the planets of the solar > system to > >> begin with) > >> * A check to verify that some functionality is compatible with the > projection > >> method, as EPSG is not compatible with poly-lines (well not without > pain) > > +1 -- I would imagine that we could do this by checking what the coordinate > system is right? Like if it's lat-lon, in EPSG WGS84. We would need some > way > of automatically identifying the incoming spatial reference method though, > and perhaps an object hierarchy for this. I was thinking too that if we > have > Points, and Shapes and Polygons as core classes, then we should provide > easy > mechanisms to construct say an EPSG WGS84 point from a String, Double, Int, > etc. WDYT? > > > * Look at ways to blend transitions > >> * Can we come up with a way to transition a path from one coordinate > system > >> to another, such as drawing a line across the poles or meridians, > somewhere > >> polar coordinates might make more sense than sinusoidal or Mercator > >> projections? > > Good idea. I think if we can: > > - Come up with a simple Object diagram: Point *...*, Coordinate System 1 > ... > * Projection, ... > - Build a framework that takes in basic Java data types and converts them > to > our o.a.sis.core.Objects > - Provide all of the distance functionality (point/radius, bounding box, > polygon) > - Provide translation mechanisms between coordinate spaces > - Provide a simple XML/JSON format for points to take as input and produce > as output > > That would be a great framework to do some of the more complex stuff on top > of. > > Thoughts? > > Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/<http://sunset.usc.edu/%7Emattmann/> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >
