On Jan 30, 2010, at 12:29 AM, Jody Garnett wrote: Can we get access to this code? Why was it not contributed back? We have done a prototype already where we have charts and tables inside the uDIG printable page, but it would be best to do this based on Emily's work, if possible.
In general when a consulting company, like Refractions or LISAsoft, does work for a customer the work is not contributed back - unless the customer sees the value and is willing to pay for the extra overhead involved.
If you do find yourself working for a customer the ideas is roughly to trade reduced maintenance cost for the upfront cost checking with the community (perhaps a design to be reviewed from the PSC?).
i accept it (it is allowed), but I think it is a narrow perspective. The success of a software depends on how good it is. And the success of a company that (maybe among other things) develops that software is tied to the diffusion of the software (besides the ability of its management). No software diffusion, no business. I think there is a trade-off between different needs, and a behavior that maximize the company fitness which is not the complete closure.
However, this is just my humble opinion. For the community, I think it would be interesting to know an estimation of these extra-costs, which maybe could be conveniently paid by other.
Long life to udig.
riccardo
There is one other track that has seen success. We also have a number
of teams that have used BIRT in conjunction with uDig map rendering
capabilities; one of them did donate the code while I was at
Refractions but I never got a chance to look at it.
We reviewed BIRT last year but did not go ahead with it because it was actually a very complex system and we felt that would make it harder for us to use our report scripting ideas. But the code might still be worth reviewing.
The charting part of BIRT is actually independent and nicely done. Another strong hint that all new printing work has been done to udig-1.2 ;-)
No so much as a hint; more that I cannot remember the work that was done on 1.1.x since I was not part of it. That does; and it sounds superior to the best practice outlined
earlier. The Page / Box should be the content model; and BoxPrinter
(or any other printer you need) should be able to provide the
rendering. We also have the concept a "template" that can be used to
create a Page given a couple of bits of information (page size, a IMap
to start from etc...).
It is beginning to sound more like our DSL would actually generate the template itself. Since the DSL specifies the complete content, like number of maps, charts and tables and their ordering in the report. The only thing the DSL does not specify is the style (fonts, colors, etc.). When comparing with HTML/CSS, our DSL will generate the complete HTML and contained objects (maps, tables, charts, images), but not the CSS.
Andrea has started using a charting library; I have managed to use
BIRT charting before. So this may be a case where community discussion
sets the direction.
Great. It would be good to know how Andreas charts, your BIRT work and our JFreeChart work overlap, and we can try to converge a little.
Andrea was using JFreeChart I think; also JFreeCharts can be used *inside* the rendering process to place little pie charts and stuff directly on your map ...
Jody
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
________________________________________________________________ Universita` di Trento Dipartimento di Ingegneria Civile e Ambientale/CUDAM Via Mesiano, 77, 38050 Trento (ITALIA) Ph: +390461882614-10 Fax:+390461882672 _______________________________________________________________
|
