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
