[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Unable to find custom function "Colourmap"
|
You need to "register" the function in META_INF/servies as described in the function tutorial. It will need to be loaded in the same classloader as geotools for the gt-main module FunctionFinder to see it.
There is a geotools FunctionFactory implementation that scans all the functions defined in META_INF/services and provides them to the library (including the renderer).
You can also take a larger gulp and register your own complete FunctionFactory implementation.
For more details:
- http://docs.geotools.org/latest/userguide/tutorial/advanced/factory.html
- http://docs.geotools.org/latest/userguide/tutorial/advanced/function.html
Jody
On 29/06/2012, at 10:39 PM, Trupti Pol wrote:
> Hi,
>
> I am trying to develope a custom function "ColorMap" which can be used in
> SLD to get the different style based on feature attributes.
>
> This function is mainly utilized to provide different draw color to each
> feature based on the "ColorIndex" attribute.
>
> My Sample function is as follows
>
> public class ColorMapFunction extends FunctionExpressionImpl{
>
> public ColorMapFunction(String name) {
> super("ColorMap");
> }
>
> @Override
> public int getArgCount() {
> return 1;
> }
>
> public Object evaluate(Object feature) {
> String colorIndex;
>
>
> try {
> colorIndex = getExpression(0).evaluate(feature).toString();
> } catch (Exception e){ // probably a type error
> throw new IllegalArgumentException(
Date: Thu, 12 Jul 2012 11:47:54 +1000
From: Jody Garnett <jody.garnett@xxxxxxxxx>
To: User-friendly Desktop Internet GIS
<udig-devel@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <4813169407374CC1A1A6DACE66498878@xxxxxxxxx>
X-Mailer: sparrow 1.6.1 (build 1081.52)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4ffe2cca_25e45d32_72aa"
Subject: [udig-devel] IService display thread safe
X-BeenThere: udig-devel@xxxxxxxxxxxxxxxxxxxxx
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: User-friendly Desktop Internet GIS <udig-devel@xxxxxxxxxxxxxxxxxxxxx>
List-Id: User-friendly Desktop Internet GIS <udig-devel.lists.refractions.net>
List-Unsubscribe: <http://lists.refractions.net/mailman/options/udig-devel>,
<mailto:udig-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe>
List-Archive: <http://lists.refractions.net/pipermail/udig-devel>
List-Post: <mailto:udig-devel@xxxxxxxxxxxxxxxxxxxxx>
List-Help: <mailto:udig-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=help>
List-Subscribe: <http://lists.refractions.net/mailman/listinfo/udig-devel>,
<mailto:udig-devel-request@xxxxxxxxxxxxxxxxxxxxx?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 01:45:36 -0000
--4ffe2cca_25e45d32_72aa
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I have been having bit of fun with a custom IService implementation that contains the following check:
if (Display.getCurrent() != null) {
throw new IllegalStateException(
"Access to the server not available from the display thread"); //$NON-NLS-1$
}
I have found this *very* helpful for catching code that has a chance of blocking the display thread while it waits for IO.
However it has turned up a few instances in uDig where we are incorrectly asking for IServiceInfo from the display thread under the assumption someone already loaded it. After our next release I would like to put a few Display thread checks (such as the above) in order to catch this kind of mistake early.
For reference where I get the problem in uDig is here:
at net.refractions.udig.catalog.internal.ServiceFactoryImpl.createService(ServiceFactoryImpl.java:241)
at net.refractions.udig.catalog.ServiceParameterPersister.locateService(ServiceParameterPersister.java:241)
at net.refractions.udig.catalog.ServiceParameterPersister.restore(ServiceParameterPersister.java:155)
at net.refractions.udig.catalog.internal.CatalogImpl.loadFromFile(CatalogImpl.java:1015)
at net.refractions.udig.catalog.CatalogPlugin.restoreFromPreferences(CatalogPlugin.java:201)
at net.refractions.udig.catalog.CatalogPlugin.start(CatalogPlugin.java:106)
I am going to think about a fix for that; it could be our habit of asking for getInfo to check if the service is any good is:
a) a bit of a hack
b) not needed when restoring the catalog no startup
--
Jody Garnett
--4ffe2cca_25e45d32_72aa
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div>
I have been having bit of fun with a custom IService implementation that contains the following check:
</div><div><br></div><div><div> if (Display.getCurrent() != null) {</div><div> throw new IllegalStateException(</div><div> "Access to the server not available from the display thread"); //$NON-NLS-1$</div><div> }</div></div>
<div><div><br></div><div>I have found this *very* helpful for catching code that has a chance of blocking the display thread while it waits for IO. </div><div><br></div><div>However it has turned up a few instances in uDig where we are incorrectly asking for IServiceInfo from the display thread under the assumption someone already loaded it. After our next release I would like to put a few Display thread checks (such as the above) in order to catch this kind of mistake early.</div><div><br></div><div>For reference where I get the problem in uDig is here:</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.internal.ServiceFactoryImpl.createService(ServiceFactoryImpl.java:241)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.ServiceParameterPersister.locateService(ServiceParameterPersister.java:241)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.ServiceParameterPersister.restore(ServiceParameterPersister.java:155)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.internal.CatalogImpl.loadFromFile(CatalogImpl.java:1015)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.CatalogPlugin.restoreFromPreferences(CatalogPlugin.java:201)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at net.refractions.udig.catalog.CatalogPlugin.start(CatalogPlugin.java:106)</div></div><div><br></div><div>I am going to think about a fix for that; it could be our habit of asking for getInfo to check if the service is any good is:</div><div>a) a bit of a hack</div><div>b) not needed when restoring the catalog no startup</div><div>-- </div><div>Jody Garnett<br></div><div><br></div></div>
--4ffe2cca_25e45d32_72aa--
