See in line comments ... 2010/12/10 Andrea Aime <[email protected]>
> On Thu, Dec 9, 2010 at 10:47 AM, Frank Gasdorf > <[email protected]> wrote: > > > > > > 2010/12/8 Andrea Aime <[email protected]> > >> > >> On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf > >> <[email protected]> wrote: > >> > Hello List, > >> > > >> > I would like to discuss the usage of java.net.URL's instead of > >> > java.net.URI > >> > in the interface ExternalGraphic. > >> > In my opinion it is quite difficult to extend SDLStyleFactory with an > >> > ExternalGraphicFactory implementation if the OnlineResource would look > >> > like: > >> > myprotocoll://code.... > >> > > >> > If extending the SLD Styler it is recommend to write a Handler for the > >> > protocol :( if it doesn't exists > >> > > >> > The OnlineResource interface instead uses URI for locations. Could > >> > somebody > >> > explain, why the SLDParser makes an URL object out of it? > >> > >> Because in the end that's what ExternalGraphic "location" property > >> demands: > >> a URL. > >> > >> Looked around, the change is not without pain: > >> - ExternalGraphic.getLocation is called 9 times in Geotools > >> - ExternalGraphic.getLocation is called 21 times in GeoServer > >> I don't have the stats for uDig but there might be calls there as well. > > > > Maybe it is possible to change the code within geotools and let String > and > > URL stuff in the interface as convenient functions and mark it as > > deprecated, so the geoserver and udig projects could change the code > within > > the next release cycle. > > Well, given we are moving towards SE 1.1 anyways what about having > SLDParser build a OnlineResource and use it to build the ExternalGraphic? > And then change the client code in geotools to use it and extract the uri. > One thing that surprises me is that there is no factory allowing to build > and OnlineResource, but I guess that for the moment we can get away and > just create OnlineResourceImpl inside the parser. > And then we can change the external graphic factory to just take a URI > or a String, yes. > Sound good! > > >> > >> > From my point of view it would be great to refactor the > ExternalGraphic > >> > interface. That could make it easier to extend the SDLStyleFactory. > >> > > >> > What do you think? Do you have any suggestions? > >> > >> That we need the get go for quite a bit of people here: ExternalGraphic > >> location seems to be used in a quite lot of places, URL and URI are > >> simply not compatible. Also, thought I'm not sure why, the setURI() > >> method is deprecated. > > > > Yes, the OnlineResource Object uses URI's as well and yes the value it > could > > be an URL but don't have to. In case of using a different protocol than > > http/ftp/file or protocols that are already implemented in jdk it leads > into > > programming a lot of overhead to implement an other URL protocol, that is > > only required to make a URL object out of string respective URI. > > The mil2525b example (mil2525b://${symbol} ) described in > > http://docs.codehaus.org/display/GEOTOOLS/Dynamic+SLD+Graphic+objects > > would not work without creating a new URLStreamHandlerFactory and the > > required URL classes. > > > > Andrea, I guess you are the one how designed the ExternalGraphicFactory > > interface. In combination to the issues discussed above I'd like to ask > some > > questions: > > - creating a new extension (like mil2525b) using the same format like > > ImageGraphicFactory would result into overlay Images. Was this the > initial > > thought or is it just a hidden feature? > > I don't know what you mean by overlay images. The result of a > ExternalGraphicFactory > is an Icon, if you built it internally by overlaying images (since mil > symbols > are a composition, right?) it's just an implementation detail. > I would expect such factory to create a ImageIcon backed by a buffered > image that you created by repeatedly painting all of the necessary elements > of the composite symbol on top of it. > Oh inconsistent description, initially i thought every factory that returns not null for the icon add it to the map. But after I had a look into SLDStyleFactory I understood, that it takes the first and stops querying the others. Means to me, that the first registered that would return an icon wins the race ... > - Would it be an enhancement if the Factory should implement kind of > > "evaluate" function that returns true to check whether the Factory would > > return an Icon. Right now the SDLStyleFactory checks if getIcon returns > null > > and within the getIcon method there are some checks (supported formats, > > evaluation with feature attributes). > > I honestly see this as a step backwards, more work for no gain. > > Got it ;) > > - What do you think about evaluating within SLDStyleFactory and call > getIcon > > with complete Graphic Object, that the implementations can use all the > > properties like size and opacity. > > The opacity is not the business of the graphic factory and would > require changes down in the renderer in all parts that paint an image. > The size is already provided. > but if the image service would have an attribute to return transparent icons the information would be nessesary... As a rule of thumb I'm not going to accept any change in the interfaces > that just make up for a different code aesthetics sense without providing > any extra functionality. > But I'm more than willing to accommodate anything that will make the > interfaces easier to implement or that allow to provide extra > functionality. > > Btw, wondering, are you going to donate back that new external graphic > factory implementation to GeoTools? There has been quite some interest > on militar symbols in the past around here. > > Right now it is an implementation based on (single threaded) ArcGIS Engine Runtime in combination with the free mole extension (supports app6a and 2525b). I guess the code from the project can not be donated back BUT I can change it to use the free mil2525b png jar file from openmap project: http://openmap.bbn.com/cgi-bin/viewvc.cgi/trunk/lib/milStd2525_png.jar?root=openmap&view=log in the sld document the OnlineResource would look like mil2525b://${symbolid} But it is not an ExternalGraphicFactory it is a implementation of URLStreamHandlerFactory and URLStreamHandler to extend the protocol. I started first using the ExternalGraphicFactory but if no URLStreamHandler it leads into MalformedUrlExceptions (unknown protocol) and if implemented it's not required to extend using the geotools interface. Frank Cheers > Andrea > > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- >
------------------------------------------------------------------------------
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
