Before I do anything about direct color, let's have a serious discussion about implementing feature style (implemented as right click Edit Feature Style?).
I'm willing to do the little bit of extra work to support more style characteristics (like line type and fill pattern) using the standard Change Style dialog, if we can figure out a reasonable way to stuff the data into the limits of dbf fields. It would be easy to add a line pattern since that is basically just a couple of numbers. Fill pattern can be specified by just a single number that is the index into the pattern list. Same for Line width, transparency, and Vertices Size. I would say that all these BasicStyle fields can be combined into a single string (not XML) that might fit into one 255 character field. Perhaps the same could be done with the Label Style and Decorations. I would say that would be enough since Color Theming and Scale are useful on a per feature basis. regards, Larry On 10/5/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > > Larry Becker a écrit : > > > Hi Michaël, > > > > Yes, the idea of a per feature style occurred to me too, but for what > > I needed it was a bit like shooting an bird with an elephant gun. > > There is also the problem of fitting the style (xml?) information into > > a 255 character DBF field. I had some hope that the R_G_B as hex > > field was such a simple idea that (like shapfiles) it might "catch on." > > Yes, the complex style should be broken up into several attributes. Ex. > (fill_color, fill_pattern, line_color, label_size...) > > > > > > > Exporting layers to a format that includes style information can be > > very complicated to implement on JUMP. SkyJUMP supports the export of > > a CAD-like format called CGDEF which does. Every time I add a new > > style like direct color, it breaks my export. What we need is an > > interface similar to batik printing that does call-back for all of the > > render hooks. I have worked on this concept, but am stuck on the > > problem of getting the geometry without it being transformed. > > In OpenJUMP, why feature styles should not be described the same way as > layer style (same internal representation and same xml representation) ? > They could overload layer styles globally (if there is a feature style, > don't use layer style) or style by style (for one particular style, if > feature style is null, use layer style). I don't know how batik printing > works and did not understand the problem with getting the geometry. > But I agree, adding complex styles at the feature level may involve a > lot of change in the code, and as I said in a previous mail, the normal > place for styling in a gis is at the layer level, and adding styles to > feature may not be a good idea at all. There are at least two other > solutions to obtain about the same result without introducing styles at > the feature level : creating several layers for features with different > represenations. Creating a color-theming style based on a unique > key-attribute (id, name...) > > > > > Perhaps a viable approach would be to implement a Style.paintToNull > > method that would simply return style state information. > > ? > > > > > I will be glad to port over direct color, but be warned that it will > > break some print routines and style exports, in the sense that they > > will ignore the direct color if they implement their own renderers. > > So, I'd rather let specialists like Sasha or Geoffrey give their opinion > as I don't know much about print routines and can't measure well the > side effects on other parts of the code. > Thanks for all your efforts. > > > > > The copy and paste Schema is a different matter. It should port right > > over without problems. > > :-) > > > > > regards, > > Larry > > > > On 10/4/07, *Michaël Michaud * <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > I'll need some feedback from the other developers before I > > port over > > > the direct color capability. > > > > Hi, I tested the direct color plugin and it sounds just fine to me. > > ... but if I imagine future developments around a per feature > > styling, > > here are some ideas : it could be possible to modelize more complex > > feature styles as a single special 'style' attribute (or an array of > > styles). The attribute could be hidden in the main attribute panel > > (or > > just iconified), but editable clicking on a special button as it > > is the > > case for geometries. > > Clicking the style button of a feature record would open a style > panel > > looking like the "basic style panel". > > Export drivers could be able to export styles as styles (DXF, > > MIF/MID...), as attributes (shapefiles, database,...) or not at all > > (optional). > > > > I also noticed "copy/paste schema" plugin that OJ misses and which > > is a > > very good idea ;-) > > > > Michaël > > > > > > > > regards, > > > Larry > > > > > > On 10/3/07, *Giuseppe Aruta* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > > > Hi Larry, > > > more i use SkyJUMP, more I think you have to port some of its > > > tools in OpenJUMP: > > > 1) KML support is a valid alternative for WMS, sometimes, > > > expecailly if users can access to geographic informations > > only by > > > Google Earth. I think that KML support has to be ported as > > OJ plugin > > > BTW what about add KML and DXF in OJ and drop FML and GML: > > writing > > > input/output files seems something very complicated. > > > > > > 2) the way to change colours seems very pratical. It saves > > colour > > > code text in a R_G_B attribute (which can be copied to other > > > layers). What about give this function even to OJ? What if > > related > > > to import DXF files? > > > > > > Thanks > > > > > > Peppe > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > ------------------------------------------------------------------------ > > > L'email della prossima generazione? Puoi averla con la nuova > > > Yahoo! Mail > > > < > > > http://us.rd.yahoo.com/mail/it/taglines/hotmail/nowyoucan/nextgen/*http://it.docs.yahoo.com/nowyoucan.html > > > > > _______________________________________________ > > > jump-users mailing list > > > [email protected] > > <mailto:[email protected]> > > > <mailto: [email protected] > > <mailto:[email protected]>> > > > http://lists.refractions.net/mailman/listinfo/jump-users > > > <http://lists.refractions.net/mailman/listinfo/jump-users > > <http://lists.refractions.net/mailman/listinfo/jump-users>> > > > > > > > > > > > > > > > -- > > > http://amusingprogrammer.blogspot.com/ > > > > > > >------------------------------------------------------------------------ > > > > > > > >_______________________________________________ > > >jump-users mailing list > > >[email protected] > > <mailto:[email protected]> > > > http://lists.refractions.net/mailman/listinfo/jump-users > > > > > > > > > > _______________________________________________ > > jump-users mailing list > > [email protected] > > <mailto:[email protected]> > > http://lists.refractions.net/mailman/listinfo/jump-users > > > > > > > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >jump-users mailing list > >[email protected] > >http://lists.refractions.net/mailman/listinfo/jump-users > > > > > > _______________________________________________ > jump-users mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jump-users > -- http://amusingprogrammer.blogspot.com/
_______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
