Bah; scratch that it is GPL; however the idea may still be sound.
Jody
On 18/06/2010, at 4:01 PM, Jody Garnett wrote:
> Hunted down the implementation:
> - http://wiki.netbeans.org/NetBeansInOSGi
>
> And a presentation by the guy who wrote it:
> -
>
> Java 1.6 has ServiceLoader outed as a publ
Hunted down the implementation:
- http://wiki.netbeans.org/NetBeansInOSGi
And a presentation by the guy who wrote it:
-
Java 1.6 has ServiceLoader outed as a public normal thread safe class rather
then stuck in an out of the way corner of ServiceRegisery we use now).
ServiceLoader filter = Ser
Jody Garnett ha scritto:
> Morning crew:
>
> I just noticed a delivery requirement for a project here at work is
> being handled as source code rather then jar form; as such I would
> like to make a tag of trunk to refer to.
>
> Actually if I can get some writing done this weekend perhaps perhaps
Okay here is a slightly wilder idea; combined with a very good article:
Article first with a nice background on Factory SPI moving on to the netbeans
LookUp (think container, inversion of control etc...)
- http://java.sun.com/developer/technicalArticles/javase/extensible/
NetBeans has suffered a
Hi Jody,
+0
I can't see a problem. It's just a tag :-)
Michael
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize lis
Morning crew:
I just noticed a delivery requirement for a project here at work is being
handled as source code rather then jar form; as such I would like to make a tag
of trunk to refer to.
Actually if I can get some writing done this weekend perhaps perhaps I could
make a milestone release of
> Where is (are) this code located?
I think we will have to go look ... I would open up FactoryRegister and then
look for references in the current workspace.
There is a picture in the wiki but that is down for me right now.
>> So perhaps:
>> - we could try generating additional entries for the
Looks good!
On 18/06/2010, at 5:52 AM, Andrea Aime wrote:
> Andrea Aime ha scritto:
>> Jody Garnett ha scritto:
>>> On 17/06/2010, at 10:36 PM, Andrea Aime wrote:
>>>
Let's say the renderer would become... more aware of dpi.
It's actually already considering the dpi hint when it comes
> Mathieu - one thing that may help is that we have all our GeoTools code
> using the same "factoryregistery" class to check factory spi (and to hold
> onto a singleton of each factory found). We have extended this factory
> registery in a few cases to allow people to "register" additional
> implem
Andrea Aime ha scritto:
Jody Garnett ha scritto:
On 17/06/2010, at 10:36 PM, Andrea Aime wrote:
Let's say the renderer would become... more aware of dpi.
It's actually already considering the dpi hint when it comes to compute
the scale.
The rescale visitor would not go, that's actually the bi
Sorry Andrea, but I cant remember the point in time. Independent of
the result of the discussion I would propose to write at least a
warning to the log file if we do a toUpper(attribute).
I did something similar in the db2 module concerning limit and offset
handling.
"Warning: DB2 handles l
Jody Garnett ha scritto:
On 17/06/2010, at 10:36 PM, Andrea Aime wrote:
Let's say the renderer would become... more aware of dpi.
It's actually already considering the dpi hint when it comes to compute
the scale.
The rescale visitor would not go, that's actually the bit of code I
want to use t
Milton Jonathan ha scritto:
> Hello again
>
> Oh, I was just thinking about it theoretically, and trying to spare a
> separate rescaling phase.
>
> Probably it's not practical, but my view is that if people are not using
> units like meters or feet but still want the symbolizers to remain the
Hello again
Oh, I was just thinking about it theoretically, and trying to spare a
separate rescaling phase.
Probably it's not practical, but my view is that if people are not using
units like meters or feet but still want the symbolizers to remain the
same size on paper (or on screen), regardl
> You had some experience with the "udig lite" effort that had bundled up
> some of geotools as OSGi plugins? I cannot really remember any of the
> details since I was not active at the time. Is there anything you can
> remember that may help us?
>
Sadly, despite my best intentions to try out the
Craig: (got it right that time - sigh)
You had some experience with the "udig lite" effort that had bundled up some of
geotools as OSGi plugins? I cannot really remember any of the details since I
was not active at the time. Is there anything you can remember that may help
us?
Mathieu - one t
Hello
Does Geotools provide a widget that I could place in a status bar (below the
map)
showing a scale bar that gives the scale in meters (for instance) ?
I found the method calculateScale of class RendererUtilities
which seems to be useful but how can I link it to a widget ?
thanks a lot
J
Hi Mathieu, thanks for the intro Jody,
> Wanted to introduce you to Crag from the uDig project - who cheerfully
> asked me how geotools / osgi relationship was going. When he last checked in
> Harald was working on it (but as you saw on that page Harald left
> instructions and thus nothing has hap
On 17/06/2010, at 10:36 PM, Andrea Aime wrote:
> Let's say the renderer would become... more aware of dpi.
> It's actually already considering the dpi hint when it comes to compute
> the scale.
>
> The rescale visitor would not go, that's actually the bit of code I
> want to use to perform dpi r
Jody Garnett ha scritto:
> Thanks for bringing that context back to the discussion (I somehow
> missed it arriving partway along in the discussion).
>
> I am interested in seeing this happen as: - it is not wms specific -
> we run into this issue when printing from uDig - it really is not wms
> sp
Thanks for bringing that context back to the discussion (I somehow missed it
arriving partway along in the discussion).
I am interested in seeing this happen as:
- it is not wms specific - we run into this issue when printing from uDig
- it really is not wms specific; we are starting to run into
I am trying to think of a subset; the truth of the matter is that the library
is plugin based and that FactorySPI is the plug-in system. Even "basics" like
data access or support of coordinate reference systems do not work with out a
couple key facilities that are found via plugins.
Suppose the
Ok,
the discussion about DPI and rescaling did not exacly go well...
Jody suggested that my second attempt on GeoServer mailing list
(which basically suggests to do the work only on the server side)
is clearer in terms of explanations so... let me paste it here as well:
---
> I think we should do a few test on a small but consistent and
> representative subset of geotools modules which are using SPI (both
> geotools internal and from third parties)
>
> Which ones would you recommend?
Jody, could you recommend a small subset of modules using SPI?
I could maybe find so
Make internal multithreading configurable for ImageMosaic
-
Key: GEOT-3145
URL: http://jira.codehaus.org/browse/GEOT-3145
Project: GeoTools
Issue Type: Improvement
Components:
Just a quick note Andrea:
The solution I mentioned used for uDig right now was not done with UOM in mind;
I would like to set up something consistent at the geotools level and not have
to make use of workarounds outside of the core renderer. I view that visitor
that udig provides to rescale th
Andrea Aime ha scritto:
> Andrea Aime ha scritto:
>> That is problematic as they just know what the target printing dpi is.
>> I'm also asking the MapServer folks about what they do (e.g., if there
>> is a WMS parameter to do that, if they have, I'd prefer to just
>> align with theirs).
>> In the m
Andrea Aime ha scritto:
> That is problematic as they just know what the target printing dpi is.
> I'm also asking the MapServer folks about what they do (e.g., if there
> is a WMS parameter to do that, if they have, I'd prefer to just
> align with theirs).
> In the mapfile they basically specify t
Jody Garnett ha scritto:
> On 17/06/2010, at 5:37 PM, Andrea Aime wrote:
>
>> Jody Garnett ha scritto:
>>> DPI is an indication of pixels per inch; a ratio we can then go
>>> on to use to base line our configuration; when outputting
>>> results. To be explicit: - For a symbol size specified in pix
On 17/06/2010, at 5:37 PM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> DPI is an indication of pixels per inch; a ratio we can then go on to
>> use to base line our configuration; when outputting results.
>> To be explicit: - For a symbol size specified in pixels; I expect it
>> to shrink to
Jody Garnett ha scritto:
> Hi Andrea:
>
> I have been loath to enter this discussion as I quickly get confused
> between the different points of view (indeed most of the time reading
> these emails it sounds like you are both saying the same thing).
>
> There is a style visitor used by uDig to ad
Hi Andrea:
I have been loath to enter this discussion as I quickly get confused between
the different points of view (indeed most of the time reading these emails it
sounds like you are both saying the same thing).
There is a style visitor used by uDig to adjust a style to respect the current
Jody Garnett ha scritto:
> So we kind of have three things going on: - Our Filter interfaces
> support both case sensitive and case insensitive behaviour for all
> comparison operations and like filter - The Filter 1.1 specification
> screwed up and forgot a matchCase for Like; everything else is
>
So we kind of have three things going on:
- Our Filter interfaces support both case sensitive and case insensitive
behaviour for all comparison operations and like filter
- The Filter 1.1 specification screwed up and forgot a matchCase for Like;
everything else is covered
- Our CQL / ECQL parser/
[email protected] ha scritto:
> I can remember this discussion since I think I pointed out the problem
> with the indices. And I was against it.
Ah, so there has been a discussion on this? Do you remember when?
> I am wondering that this feature is implemented. Nobody, having a
> litt
35 matches
Mail list logo
