Paul wrote: "I'm wondering if there is a better way for users to select the decoration styles. What I was thinking is we can divide them into the following categories.
Start End Segment Vertex (also applies to Point) Then each style implementation would implement say LineStartStyle interface to indicate the kind of style it is. The UI would then have 4 sections where you select the style for each one. The decision there would be if that was a multiple selection or a single selection. What do people think of this idea?" I like this idea. Eric wrote: "with OJ, is there a way to separate a vector object's geometry from it's appearance(easily)? handling appearance by a class called OJDrawingStyle, which is a tree of graphical attributes and drawing behaviors that can be attached to the vector objects. objects can share styles, so changing the style alters the appearance of all the objects sharing that style, for example. alternatively, a 1:1 relationship between objects and styles could also be adhered to(more conventional for a vector application). however, it would be nice to take styles beyond fill of path and stroke, supporting any number of components. making sure styles define what is drawn, and in what order." I get nervous about creating to great a separation between the appearance of vector geometry and the Layer that contains it. One of the things that makes OpenJUMP beautifully simple is that all the features on a Layer share the same style and basic appearance. At some point I think we must make a choice between this simplicity, both from a user perspective and a programmer perspective, and complex functionality. I personally think OpenJUMP excells as an editor of spatial data. I'd like to think it fits into the editing/analysis spot on the FOSS GIS tool chain, whereas other tools might be used for cartographic map production. I think we can preserve our simplicity if we follow this basic model. I would love to see a situation where OpenJUMP is used to create the basic layers of spatial data, but where FOSS drawing and graphic design programs are used to produce the acutal maps. I'm working on some tools that will facilitate better data exchange between OpenJUMP and Inkscape. I think this is a step in the correct direction. Inkscape is an incredibly powerful drawing tool that uses an open drawing file format. Why reinvent the wheel when great FOSS tools for graphic design already exist? On a side note, you can always use different layers to style your data differently. I realize this presents some challenges. For example, if your main highways are on a different layer than your rural roads, you can style the two (2) types of roads differnetly, but spatial analysis of a road network is more difficult. I'm not sure if there is an ideal solution to this problem. Even ESRI recognizes that different projects can be used for "analytical" GIS and cartogrpahic map design. I do trust Paul's judgement on the style decisions. It seems like he has done a lot of good work with this code. The Sunburned Surveyor On Thu, Apr 3, 2008 at 9:46 AM, Paul Austin <[EMAIL PROTECTED]> wrote: > Eric, > > I have in my own version of JUMP a filter based styling mechanism where you > can define styles based on attributes of the feature (e.g. different style > for two lane paved v.s. one lane gravel road). It also then allows you to > turn on/off rendering of specific filter styles in the layer menu. > > Unfortunately there was a clash with the filter theme styles and I haven't > had chance to do the refactoring to allow this to work nicely. Hopefully > I'll get a chance at some point. > > We can then look at fancier styling such as adding edges to lines so you > could have a different fill portion for a line. > > Paul > > > Paul Austin > President/CEO > Revolution Systems Inc. > > +1 (604) 288-4304 x201 > www.revolsys.com > > Eric Jarvies wrote: > > Hello, > > with OJ, is there a way to separate a vector object's geometry from it's > appearance(easily)? handling appearance by a class called OJDrawingStyle, > which is a tree of graphical attributes and drawing behaviors that can be > attached to the vector objects. objects can share styles, so changing the > style alters the appearance of all the objects sharing that style, for > example. alternatively, a 1:1 relationship between objects and styles could > also be adhered to(more conventional for a vector application). however, it > would be nice to take styles beyond fill of path and stroke, supporting any > number of components. making sure styles define what is drawn, and in what > order. > > it would be wonderful to select a 4 lane highway from the menu, or a dirt > road, or a 2-lane with dirt frontage road on the left side(add long list of > visually fun possibilities here), and apply that to an existing > path/linestring. or some yellow bricks(yellow brick road), or whatever. > so please consider this when considering decorations for roads, because at > the present time, most all gis apps have really boring single-line, > single-color decorations to apply to lines. > > eric > > > On Apr 3, 2008, at 9:51 AM, Paul Austin wrote: supporting multiple strokes > with different line, dash attributes, along with width and colors. > > All, > > I'm wondering if there is a better way for users to select the decoration > styles. What I was thinking is we can divide them into the following > categories. > > > Start > End > Segment > Vertex (also applies to Point)Then each style implementation would implement > say LineStartStyle interface to indicate the kind of style it is. > > The UI would then have 4 sections where you select the style for each one. > The decision there would be if that was a multiple selection or a single > selection. > > What do people think of this idea? > > Paul > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace_______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ________________________________ > > > ------------------------------------------------------------------------- > Check > out the new SourceForge.net Marketplace. > It's the best place to buy or sell > services for > just about anything Open > Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ________________________________ > > _______________________________________________ > Jump-pilot-devel mailing > list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
