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.
>>
>> > 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.
> - 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.
> - 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.
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.
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
