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 - 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. 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. -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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
