ExternalGraphic interface URL vs. URI for OnlineResources

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ExternalGraphic interface URL vs. URI for OnlineResources

fgdrf
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?

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?

Cheers, Frank

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

geowolf
On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf
<[hidden email]> 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.

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

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

-----------------------------------------------------

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

fgdrf


2010/12/8 Andrea Aime <[hidden email]>
On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf
<[hidden email]> 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

-----------------------------------------------------


------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

geowolf
On Thu, Dec 9, 2010 at 10:47 AM, Frank Gasdorf
<[hidden email]> wrote:

>
>
> 2010/12/8 Andrea Aime <[hidden email]>
>>
>> On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf
>> <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

fgdrf
See in line comments ...

2010/12/10 Andrea Aime <[hidden email]>
On Thu, Dec 9, 2010 at 10:47 AM, Frank Gasdorf
<[hidden email]> wrote:
>
>
> 2010/12/8 Andrea Aime <[hidden email]>
>>
>> On Wed, Dec 8, 2010 at 4:48 PM, Frank Gasdorf
>> <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

geowolf
On Fri, Dec 10, 2010 at 9:46 AM, Frank Gasdorf
<[hidden email]> wrote:

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

Indeed, that's how it's meant to work. Each factory should deal with a unique
url pattern


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

In that case you should put as part of the image url, the SLD opacity
is post processing on top of it. I would expect most symbols returned by
a graphic factory to indeed have a transparent background (well, unless
they are square and fill the entire image area).

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

Wow, that's big. By my (weak) understanding of the mil symbols when
one provides a symbol spec the resulting image would actually have
to be an overlay of some of those icons, right?

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

Sorry, confused. So you already went ahead and implemented the protocol handlers
instead?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

fgdrf
Hello List,

I'd like to present a simple module to render mil2525b symbols. What I've done so far:
- created a maven module
- added dependency to mil2525b_png.jar (taken from the openmap project), see pom file for version, artifactId and groupId to deploy/install it to your maven repository
- created a URLStreamHandlerFactory and the required classes that
  - handles mil2525b://${symbolId} URL's
  - handles symbolId's shorter than 15 chars and
  - case insensitive symbolId's
- created test cases 

Because I've no commit access to the gt repository and the extension doesn't have geotools dependencies the project sources are zipped and attached to this mail.

Feedback is welcome! Properly somebody like to commit it to unsupported?

Cheers, Frank

2010/12/10 Andrea Aime <[hidden email]>
On Fri, Dec 10, 2010 at 2:09 PM, Frank Gasdorf
<[hidden email]> wrote:
> Andrea, of course! But the question is how can I contribute? A separate
> unsupported module? How to handle the depencency, add it to the pom as well
> as the osgeo maven repository or same kind of integration as it is made for
> arcsde, where the jar has to be in classpath?
>
> Otherwise I could create a jar with the URL stuff and internal 2525b icon
> jar.
>
> Both are fine ;)

I guess a separate module would be the best solution. There are already modules
that only implement an ExternalGraphicFactory and that are separate because
of the heavy dependencies, the SVG one for example.
The jar would be better stored in a maven repository though, I can deploy
it there if you want to contribute the module

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

-----------------------------------------------------


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

gt-mil2525b.zip (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ExternalGraphic interface URL vs. URI for OnlineResources

jody.garnett
Hey Frank:

That is so cool; I have talked a number of teams through producing mil2525b symbols (and they never committed back)

Getting svn access for a new module such as this is covered in our developers guide and really does not take very long. Indeed you may already be done one of the steps which is sending an email asking for for an unsupported module.

I encourage you to do this and add it to unsupported under your own steam :-) Note to accept your work we would still need you to go through the process[1] of giving it to the osgeo foundation.

Jody


On 13/12/2010, at 5:35 AM, Frank Gasdorf wrote:

Hello List,

I'd like to present a simple module to render mil2525b symbols. What I've done so far:
- created a maven module
- added dependency to mil2525b_png.jar (taken from the openmap project), see pom file for version, artifactId and groupId to deploy/install it to your maven repository
- created a URLStreamHandlerFactory and the required classes that
  - handles <a href="mil2525b://${symbolId}">mil2525b://${symbolId} URL's
  - handles symbolId's shorter than 15 chars and
  - case insensitive symbolId's
- created test cases 

Because I've no commit access to the gt repository and the extension doesn't have geotools dependencies the project sources are zipped and attached to this mail.

Feedback is welcome! Properly somebody like to commit it to unsupported?

Cheers, Frank

2010/12/10 Andrea Aime <[hidden email]>
On Fri, Dec 10, 2010 at 2:09 PM, Frank Gasdorf
<[hidden email]> wrote:
> Andrea, of course! But the question is how can I contribute? A separate
> unsupported module? How to handle the depencency, add it to the pom as well
> as the osgeo maven repository or same kind of integration as it is made for
> arcsde, where the jar has to be in classpath?
>
> Otherwise I could create a jar with the URL stuff and internal 2525b icon
> jar.
>
> Both are fine ;)

I guess a separate module would be the best solution. There are already modules
that only implement an ExternalGraphicFactory and that are separate because
of the heavy dependencies, the SVG one for example.
The jar would be better stored in a maven repository though, I can deploy
it there if you want to contribute the module

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

-----------------------------------------------------

<gt-mil2525b.zip>------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel