Michael, You bring up an excellent point.
You wrote: " 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." To be honest, I haven't thought that far ahead. I would like to synchronize labels and features as you mention. For example, if the value of the "labeled attrbute' is changes I would like to change the label. If the "labeled feature" is deleted, i'd like to autmoatically delete the label if the user chooses this option. Note that I want to allow not only labels tied to the attribute in a specific feature, as typical of most GIS programs, but also independent labels. Michael wrote: "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." This is what I had intended. I would store the "geometry" of the label as a rectangle. This rectangle would be represented by a JTS geometry and would be sized as the bounding box of the label with a user specified buffer between the actual text and the rectangles outline. The Sunburned Surveyor On 5/15/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
