Hey Adam, It's really one or the other unfortunately -- infra doesn't have the time or resources to keep them in sync (and doesn't really make sense anyways).
I brought it mostly just b/c I thought it might ease the pension for folks to go do things at Github when I think they should be doing them here at the ASF. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Adam Estrada <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, June 20, 2013 7:45 AM To: "[email protected]" <[email protected]> Subject: Re: [DISCUSS] Transition to Git after 0.3? (was Re: shapefile branch) >I really don't mind using Git either as long as SVN doesn't completely go >away. I am more of a SVN fan anyway...Are we able to run them at the same >time in a mirrored mode? > > >On Thu, Jun 20, 2013 at 10:37 AM, Mattmann, Chris A (398J) < >[email protected]> wrote: > >> Hey Travis, >> >> I would strongly urge you to do development on Apache SIS on Apache >> hardware. >> Github is great; and convenience. But when you commit there, we don't >>get >> email notifications and so forth here and the community loses out (and >>we >> lose >> out) on having email records; archives, and other things here that show >> work >> is going on in SIS. >> >> I have a simple proposal :) You guys are definitely more Git fans now >>than >> SVN fans. Martin D when he originally came onto the project wanted to >>use >> Git, and was more familiar with it, but took great effort to adopt SVN >>b/c >> ASF support for Git at that time was quite limited. >> >> However, with you here now; with Adam; with Martin; and with a number of >> other folks contributing (Joe W. are you a Git guy?) that are Git fans, >> it's worth revisiting this discussion. However, *after* 0.3 :) Let's >> release >> that using SVN so we don't hold that off anymore. After 0.3 maybe we can >> move to Git if this discussion is favorable. Apache now supports >>writeable >> Git repos (see http://git.apache.org/) and the project's canonical >> repository >> can be Git. We can still mirror to Github, etc., but the bits (and >>really >> the >> work) ought to be happening here at the ASF. >> >> So, discuss please :) FWIW, I'm +1 to move to Git (after 0.3). >> >> 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 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> >> >> >> -----Original Message----- >> From: Travis L Pinney <[email protected]> >> Reply-To: "[email protected]" <[email protected]> >> Date: Thursday, June 20, 2013 7:31 AM >> To: dev <[email protected]> >> Subject: Re: shapefile branch >> >> >Good to know about the OGC/ISO interfaces. >> > >> >It would make sense to apply processing to NetCDF, Shapefile, Mbtiles >> >files >> >etc. I can set up in another code repo on github. The reason I want to >> >work >> >on that concurrently is to stress test the existing library with lots >>of >> >data to find bugs that may not appear with simple unit tests. >> > >> > >> > >> >Thanks, >> >Travis >> > >> > >> > >> > >> > >> >On Thu, Jun 20, 2013 at 7:42 AM, Martin Desruisseaux < >> >[email protected]> wrote: >> > >> >> Le 20/06/13 12:47, Travis L Pinney a écrit : >> >> >> >> The java.util.Map is fairly basic now. An improvement could be a >> >>feature >> >>> class that has a map of <String, DataType>, where DataType >>corresponds >> >>>to >> >>> the appropriate DataType ( >> >>> >> >>>>>http://www.clicketyclick.dk/**databases/xbase/format/data_**types.html >> <h >> >>>ttp://www.clicketyclick.dk/databases/xbase/format/data_types.html> >> >>> .) >> >>> Currently I am converting everything to strings. >> >>> >> >> >> >> Actually Feature, FeatureType and related interfaces derived from >> >>OGC/ISO >> >> standards (in particular GML - Geographic Markup Language - schemas) >>are >> >> already provided in GeoAPI: >> >> >> >> http://www.geoapi.org/**snapshot/pending/org/opengis/** >> >> >> >>feature/package-summary.html< >> http://www.geoapi.org/snapshot/pending/org/o >> >>pengis/feature/package-summary.html> >> >> >> >> This is in the "pending" part of GeoAPI, so we have room for revising >> >> them, in particular make sure that they are still in agreement with >> >>latest >> >> OGC/ISO standards. Then we would need to provide an implementation in >> >>SIS, >> >> porting Geotk classes when possible or appropriate. However there is >>a >> >> somewhat long road before we reach that point, so it seems to me that >> >>your >> >> current approach (String in java.util.Map) is good in the main time. >> >> >> >> >> >> >> >> The bulk ingests would be an api where you can call a jar file from >> >>> hadoop, >> >>> give it appropriate directory to pull shapefiles in HDFS, and it >>would >> >>> process each shapefile per mapper. The first ingest I am working on >>is >> >>>a >> >>> transformation of points to a 2D-histogram to get an idea of >>density of >> >>> features of all the shapefiles. This could be extended to have >> >>>different >> >>> types of outputs (store in a database or more efficient format on >>hdfs) >> >>> >> >> >> >> I would suggest to separate the two tasks. I think that the above is >> >>what >> >> we call a "processing", which is the subject of (yet an other) OGC >> >> standard. Processing and DataStore should be independent, i.e. >>someone >> >>may >> >> want to apply the above processing on NetCDF files too... Maybe we >>can >> >> focus on ShapefileStore first, and revisit processing later? >>Processings >> >> will need DataStores first in order to perform their work anyway... >> >> >> >> Martin >> >> >> >> >> >>
