aaime wrote: > > Ouch, no, this is not right. sld:Geometry is there to indicate > which attribute serves as the geometry (the point that is being > symbolized, that is) in the case where a Feature > has more than one geometric representation, we cannot coax it into > something else (the semantic would be just different). >
Ok , i do understand you guys have way more experience with the api and the SLD than me. The situation is like this , i have a shp file with point data , one of the fields in the dbf file is "wkicon" , so for each point the mil2525 string could differ , in the demo i compiled i created the SLD programatically with the org.geotools.styling.StyleBuilder , and i used the createPointSymbolizer(Graphic graphic, String geometryPropertyName) method and passed the "wkicon" as the geometryPropertyName. So in the SLDStyleFactory i use the simplefeature.getAttribute(symbolizer.getGeometryPropertyName()) method and it return the mil2525 string in the shp file back to me , which is what i need to create the icon through the plug ins? As i understand the property name is the attribute you would like to associate with the point? Now the data source could also be a shp file , a Postgres DB or MYSQL DB etc , the data of the geometryPropertyName would be associated with the Feature? aaime wrote: > > > What about the following: > <sld:PointSymbolizer> > <sld:Graphic> > <sld:ExternalGraphic> > <sld:OnlineResource > xmlns:xlink="http://www.w3.org/1999/xlink"; > xlink:type="simple" > xlink:href="mil2525://dynamic?symbol=wkicon_name_attr"/> > <sld:Format>image/mil2525</sld:Format> > </sld:ExternalGraphic> > <sld:Opacity> > <ogc:Literal>1</ogc:Literal> > </sld:Opacity> > <sld:Size> > <ogc:Literal>40.0</ogc:Literal> > </sld:Size> > <sld:Rotation> > <ogc:Literal>0.0</ogc:Literal> > </sld:Rotation> > </sld:Graphic> > </sld:PointSymbolizer> > > where symbol is a cql expresion (in this case, just > an attribute name, but in the general case you could > use string composition and the like to drive the > symbolizer). In the simplest case it could be > "mil2425://SFGPUCAAA-*****" (if the symbol it's a constant). > Looks Good. Few questions though about the URL xlink:href="mil2525://dynamic?symbol=wkicon_name_attr" 1. The protocol "mil2525:" , why not "wkicon:" ? Tthat way its a general protocol for the whole community , and the "wkicon:" protocol handler , use then the wkicon interface implementations to get the icon whether its mil2525 or police or disaster management etc. ? 2. "symbol=wkicon_name_attr" would this then be the "wkicon" field in the shp file that contains the mil2525 str in the discussion above? If it is i like the idea , that means the SLDStyleFactory don't have to alter the URL (also one of your concerns) , it can be handled in the URL handler , you will have to read the data from that field then , from the shp or DB? Furthermore i like this idea , because you don't like to go and setup a SLD rule for every mil2525 symbol , or symbols in other domains for the matter. aaime wrote: > > > Then we roll out an ExternalSymbolizerFactory working like this: > > public interface ExternalSymbolizerFactory { > public boolean canHandle(URL url, String format); > public Image getSymbol(Feature, URL url, size); > public boolean isStatic(URL url); > } > > SLDStyleFactory goes thru all ExternalSymbolizerFactory it can > find and looks for one that can handle the URL, after that, > it provides it with the current feature, the URL and > the size (grabbed from the Graphics element, in order > to build an appropriately sized BufferedImage). > The isStatic method is an optimization, if the graphic > defined by the url is not feature dependent we > can avoid re-evaluating the icon again and again > (something we already do, the SLDStyleFactory needs > to decide wheter a symbolizer is static or dynamic, > and will cache the static ones). > Understood. I saw the SLDStyleFactory creates a SymbolizerKey class for the symbolizer , this then would be something similar? aaime wrote: > > For the marks, the thing could be similar: > public interface MarkFactory { > public boolean canHandle(String markName); > public Shape getSymbol(Feature, String markName); > public boolean isStatic(String markName); > } > > but in this case the result is a java.awt.Shape, a > vector representation that can be resized, filled > and stroked at will. > The mark names would follow the same principles, > could be simple names, or URL with cql expressions > to drive some of the shape generation. > > How does this sound? > Cheers > Andrea > > All in all sounds good , i would like to ask for help , in the form of i ask questions you guys give answers to implement something like this ;-) -- View this message in context: http://www.nabble.com/Well-Known-Name-Icons-tp16417499p16627291.html Sent from the geotools-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
