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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
