theunsgis ha scritto: ... > 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?
The problem is, the GeometryPropertyName is what the renderer should use to decide which point to depict on the map. With shapefiles you just have one > As i understand the property name is the attribute you would like to > associate with the point? It's not what I would like to, it's what the SLD specification states that matters. From the SLD spec: "The Geometry element of a LineSymbolizer defines the linear geometry to be used for styling. The Geometry element is optional and if it is absent then the “default” geometry property of the feature type that is used in the containing FeatureStyleType is used." (same applies to other symbolizers) The only valid geometry property name in a shapefile is "the_geom". You cannot use as the geometry property name an attribute that contains a string, if it's working in your case, it's just because the renderer tries to be forgiving and uses the default geometry when you pass in an invalid value. The geometry property name is there because with spatial databases you can have multiple geometries in one feature, and SLD allows you to decide which one to use for rendering. This can be used for a variety of purposes, such as: * having extra geometries to be used as label points for main geometries that are polygons or lines * having generalized geometries that can be used for faster rendering when zoomed out (useful when the original geometry is very detailed) >> >> 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. ? Because it would allow for a quick scan of the possible icon renderer and identifies right away what kind of icon you want. Compare this: mil2425://SFGPUCAAA-***** font://wingdings?idx=0xFA acadSym://45degreesHatch with: wkbicon://SFGPUCAAA-***** wkbicon://wingdings?idx=0xFA wkbicon://45degreesHatch It seems to me the second is not as clear to the user, and not as easy to parse for the computer. But maybe I misunderstood what you said? > 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? Yes. > 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. Yes, that's the idea. >> 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? Yes, that's the idea. I will have to sort out details a little more in the proposal. > 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 ;-) The idea I had was that I stand up a proposal, we vote it, I create the framework, you try to implement your thing using it, so that we have a few use cases and we thus validate the interfaces and see if there are shortcomings. Deal? Cheers Andrea ------------------------------------------------------------------------- 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
