Re: [Geotools-devel] ExternalGraphic interface URL vs. URI for OnlineResources

[Frank G. <fg...@us...>]

2010/12/8 Andrea Aime <and...@ge...>

> On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf
> <fg...@us...> 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.


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

I'm going to create a patch for the ExternalGraphicFactory interface, so
it's properly easier to talk about...

Frank

Jody, do you know more?
>
> 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
>
> -----------------------------------------------------
>