johann.sorel ha scritto: > Andrea Aime a écrit : >> What's more painful is to have all this duplication around >> (gtxml vs jaxb, streaming renderer vs go renderer, ...) but it >> seems like the only way we can collaborate. We need more interfaces >> so keep everybody working on its implementations, eventually >> we may end up having two parallel set of modules doing similar >> stuff for most of the functionalities, but I'm not really seeing >> any good way out of this. >> > Seens I work on the go-renderer, I can only say : "duplication was the > only solution" . > > There is one component I compare to the streaming renderer : the JMapPane . > The JMapPane is straight forward and does what it's made for. > For streaming renderer it's the same thing. > You can't plug things in it, it can only display maplayers and it's > stateless. > > But it's not enought for us, we need to be able to make edition, allow > dynamic > graphics and have higher performance by being statefull. > Can you say the streaming was design to allow this ? the answer's no. > > I've experimented the streaming renderer for longgg months, and I still > use it a bit. > I've made a complete set of swing widgets based on it, but when you come > to selection and edition > you discover it hasn't been made for this. I tryed to, and believe me I > really tried. > I even made small videos for edition and selection, but I was each time > stepping in a new problem. > > It was at the beginning of this year that I finally admitted this fact : > "The streaming is perfect for the web but not for desktop app" > > You are saying we duplicate work, yes, we have no other choice : the > streaming doesnt offer a single interface we could share. > > Beside, you had the go interface a very long time ago, I'm only > improving it, and you had martin's renderer too, and > this before the streaming renderer started. So I believe the streaming > renderer was the first one to duplicate.
Incorrect. The LiteRenderer was there before in gt2, we learned about Martin's one later (not sure if the renderer still was in SeaGIS or it was in Gt2 already but we did not notice it), and I also spent time trying to integrate it into gt2 (SLD styling) before giving up on it. > Well, I understand why you duplicated at this time, martin's renderer is > a tought one :-) . > It took me a few weeks to really dive in it. but now I can say as a > result of the last months of work : > "there is no possible comparaison with the streaming renderer", > It's above it, using referencing and mathtransform a bit everywhere, > it's extendable, > plugabble and it can be used for 2D and 3D. > What I see is you had a chance to have this renderer some years ago, but > didn't made enough efforts to grab it. I was working on weekends, it was not clear how to make it not memory bound, and I wanted a renderer I could explain to students at the uni in a couple of lessons. But thanks for the compliments anyways, so is life, someone is enlightened by birth, and someone else is condemned to grovel in the mud for his entire life :( The nice thing about grovelling in the mud is that you don't feel alone, Jesse and James tried to use J2D as well, but you know, the mud is so charming you cannot avoid going back. > I'm not talking as a member of geomatys is this mail, after all I'm an > enthousiatic guy (like jody says :-D ) > who worked for free in geotools before being at geomatys. Same here, most of the work I did years ago on the (then) LiteRenderer I did for free, as I did the same to help Martin integrate his J2DRenderer in the GeoTools styling API. Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
