This approach makes sense, I think. Something similar is done in the Imagery API - an Image is just a Feature with some special attributes, which the Imagery renderer knows how to interpret (display on the screen).
The one trick is that if you intend your label boxes to have a coordinate system which is different to the CS used by the LayerView (e.g. the one used by the Features in other Layers), you may have to pull some trickery in various places in the rendering pipeline to get this to work correctly. It sounds like you want to create the concept of a Layer which renders in window space, rather than Feature space. At a high level this is certainly supported (e.g. the Scale Bar draws on a "pane" which is in window space), but I'm not sure how easily this generalizes. I would instead look at keeping the label geometry in Feature space - this will be much simpler. Imagery works this way already. Sunburned Surveyor wrote: > I've been thinking a little about the "test" I will be writing for my > pluggable renderer system and plug-in dependency system. This "test" > will be a new plug-in that allows the user to place and manipulate > labels on the layer view. The system will be vary simple to start, but > could be expanded in the future to support more complex label layout. > > The plug-in will allow the user to specify the alignment, > justification, font, font size, and content of each label. I hope to > allow the content of the label to be based on the feature attribute of > a feature stored in another layer. I will also store a rectangle that > encompasses the text label with some buffer space as a JTS geometry. > This should allow the user to select labels in spatial queries. (For > example: "Select all the labels on the Road Labels layer within 100 > feet of Interstate 5".) The user will also be able to make the > background rectangles visible and will have the option to control > their fill color, stroke color and stroke thickness. > > I'm pretty sure that I can store most, if not all, of the information > for a label as attributes of a Feature object. In essence, I want to > make the labels implementations and store them in a class that extends > Layer. This means the user will be able to manipulate these labels as > they do other layers. Obviously this type of Feature will be displayed > by a custom renderer that I plug into OpenJUMP. This type of Feature > will also have to obey a strict FeatureSchema. (I can't have someone > renaming the font size attribute or deleting the font type attribute.) > > Does anyone see major problems with implementing text labels as > implementations of the Feature interface? Does anyone see major > problems with storing these labels in an extension of the Layer class? > > Do I need to create a new Label class from scratch to avoid problems > that might result from the fact that a label is not a true geographic > feature? > > Thanks for sharing your thoughts with me. > > The Sunburned Surveyor > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
