Hi Theuns, I know this was mentioned before. Yet it keeps looking like the only reasonable escape route to me.. more than that, I think it could be quite an elegant solution.
I mean the use of ExternalGraphic and a custon URL protocol, plus a custom protocol handler. This is the first link I found that seems like a good explanation: <http://java.sun.com/developer/onlineTraining/protocolhandlers/> So such an URL could look something like "dgi://mil2525/police-car", where the "dgi" protocol name is just a silly acronym I just invented for "DYnamically Generated Image", you can use a better name. Then your implementation of URLStreamHandler, as explained in the above link, should provide the resource, whether it generates it dynamically or not. I would say the easiest way to do it is by packaging the icon images in a jar, and they your URLStreamHandler implementation would act as a proxy for the URL returned by getClass().getResouce(...). For example, if you define icons are stored in /wellknownicons, and suppose the well known name matches the file name, your implementation of openConnection would just be something like: public class DGIHandler extends java.net.URLStreamHandler{ protected URLConnection openConnection(URL u){ String iconName = u.getResource(); //I guess this is the method to use, may be wrong, I'm writing off the top of my head URLConnection connection; connection = getClass().getResource("/wellknownicons/" + iconName); return connection; } } I hope to have understood your problem well, otherwise all the above may be just nonsense or too naive. Cheers, Gabriel On Tuesday 01 April 2008 11:55:41 am theunsgis wrote: > I everyone > > sorry for the long explanation , but i would like to give as much detail i > can to get the > right message across. > > I would like to implement a plug-in for Well known Icons. > The challenge started when you investigated how to display Mil2525B icons > on a geotools layer , > where the icon images is generated dynamically in code , so there are no > images saved in any files. > > The geotools library does make provision for the display of points by > either a mark or > external graphics. > > By using a mark implementation , you can specify a well known name for a > symbol to be displayed like > “square”, “circle”, “triangle”, “star”, “cross”,and “x”. > further more geotools also try to implement the library according to > the OGC standard , and according to the standard these ("star" , "circle" > etc.) are the allowed > values , if i am wrong please set me right. > > By using the ExternalGraphic implementation , you have to supply a URL to > the graphic file > saved somewhere and the format of the graphic file. > > Me and Jody Garnett had a few emails flowing about this issue. > Jody also add a page to the geotools site about this issue > http://docs.codehaus.org/display/GEOTOOLS/Custom+Symbols+for+MIL2525B+and+E >mergencyResponse where he suggest a WellKnownNameIconFactory interface and a > WellKnownNameIconFinder class for finding > the correct icon for display. I totally agree with Jody's suggestions for > the problem. > > The big challenge is to HOW TO KNOW that the representation of the point > must be for a well known icon, > e.g "ambulance", "police-car","SHAPMF---------" were the later is the > mil2525 string representation > for military fixed wing, and some of the icons can be generated dynamically > in a class. > In the above example of well known icon names , we have three deferent > organizations who have > well known icons in there own domains, like the Emergency Response domain > ("ambulance") , > the Police Reaction Domain ("Police-car") and > the Military domain (Mil2525 String for Military Fixed Wing). > So each domain can provide a plug-in class for the interface > WellKnownNameIconFactory mentioned > on the web page > http://docs.codehaus.org/display/GEOTOOLS/Custom+Symbols+for+MIL2525B+and+E >mergencyResponse > > Now saying all that , is the well known names (“square”, “circle”, > “triangle”, “star”, “cross”,and “x”) for the mark implementation fixed to > the few names of the OGC? > > If its is not fixed then , the Well known name of the mark implementation > could be used to indicate > we are working with a WellknownName Icon , and the geometry property can > hold the WellknownName > icon string eg. "ambulance" or "police-car" or "SHAPMF---------". > > If the above is not feasible then we have to use the ExternalGraphic route, > which i personally > feel is the right thing , because we are working with a image > representation of the point. > However i can't figure out , without breaking the rules , how to show we > are working > with wellknownname Icon that will be generated dynamically , its not saved > in a file. > > Suggestions how the SLD could look like: > For the Mark implementation if the wellknown names are not fixed : > <sld:PointSymbolizer> > <sld:Geometry> > <!-- The Simple Feature will then hold the string eg. "ambulance" or > "SHAPMF---------" --> > <sld:PropertyName>WellKnownIconAttribute</sld:PropertyName> > </sld:Geometry> > <sld:Graphic> > <sld:Mark> > <!-- This will tell us we are working with WellKnownName Icons for the > point --> > <sld:WellKnownName>WellKnownIcon</sld:WellKnownName> > </sld:Mark> > <sld:Opacity> > <ogc:Literal>1</ogc:Literal> > </sld:Opacity> > <sld:Size> > <ogc:Literal>14</ogc:Literal> > </sld:Size> > <sld:Rotation> > <ogc:Literal>0.0</ogc:Literal> > </sld:Rotation> > </sld:Graphic> > </sld:PointSymbolizer> > > for the ExternalGraphic implenetation: > <sld:PointSymbolizer> > <sld:Geometry> > <sld:PropertyName>WellKnownIconAttribute</sld:PropertyName> > </sld:Geometry> > <sld:Graphic> > <sld:ExternalGraphic> > <!-- Something must go here for indicating a WellknowNameIcon --> > <sld:OnlineResource/> > </sld:ExternalGraphic> > <Mark/> > <sld:Opacity> > <ogc:Literal>1</ogc:Literal> > </sld:Opacity> > <sld:Size> > <ogc:Literal>14</ogc:Literal> > </sld:Size> > <sld:Rotation> > <ogc:Literal>0.0</ogc:Literal> > </sld:Rotation> > </sld:Graphic> > </sld:PointSymbolizer> > > Any input will be appreciated > Thanks > Theuns Heydenrych ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
