Hi Landon, A question following from your approach is : do you intend to synchronize labeled geographic feature with their "label feature" ? If both features and labels are in a distinct layer, it may be tricky to remove a label when the feature is deleted, or to change the label content when a geographic attribute value changes. I've not thought too much about your problem, but another solution I can imagine is to write a special feature implementation for labeled features : for ex. LabeledFeature lFeature = new LabeledFeature(Feature f) lFeature.getLabelPosition() If a label's geometry is cached in your labeled feature, may be a special style / renderer could display this geometry and make it possible to manipulate it as a normal feature geometry with jump's tools.
ok, may be just flights of fancy (is that a correct expression ?), it it makes no sense, please skip it. Michael Martin Davis a écrit : >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 >> >> >> >> > > > ------------------------------------------------------------------------- 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
