On 5 May 2011 00:02, Jody Garnett wrote:
> Aside; I went looking for docs and did not find any; thus you have the
> following notes* I have just added to the user guide:
> - http://docs.geotools.org/latest/userguide/library/render/map.html
Excellent - thanks Jody.
Michael
--
You arrived at the same solution I did; please commit :-)
--
Jody Garnett
On Thursday, 5 May 2011 at 12:02 AM, Michael Bedward wrote:
> Adding the event to FeatureLayer.setStyle seems to allow the
> SelectionLab app to work with the new JMapPane code:
> http://jira.codehaus.org/browse/GEOT-3562
Cool; let me look for a moment:
public void setStyle(Style style) {
this.style = style;
}
Yep; no event in sight! My understanding is we should add the following:
fireMapLayerListenerLayerChanged( MapLayerEvent.STYLE_CHANGED )
(the method is nice and efficient and only bothers to do something i
Adding the event to FeatureLayer.setStyle seems to allow the
SelectionLab app to work with the new JMapPane code:
http://jira.codehaus.org/browse/GEOT-3562
Michael
On 4 May 2011 23:32, Michael Bedward wrote:
> Thanks jody, that gets me further.
>
> Now comes the tricky bit. The current Selection
Thanks jody, that gets me further.
Now comes the tricky bit. The current SelectionLab example implicitly
relies on the do-everything nature of JMapPane.paintComponent.
In my local "improved" JMapPane the paintComponent method's only job
is to blit the backing image to the pane. The actual map dr
Reading ...
> I'm trying to work out whether updating the example will make it work
> with the changed JMapPane code, but I'm a bit lost in the new Layer
> code.
Okay - my goal was to make it exactly the same (but this time with a set class
for each kind of layer - rather than a bunch of magic met
Hi Jody,
I'm looking at SelectionLab now. I was mistaken before. It still works
fine with the current JMapPane. The problem is with the supposedly
"improved" JMapPane.
I'm trying to work out whether updating the example will make it work
with the changed JMapPane code, but I'm a bit lost in the n
Sorry, that's a stupid idea. I should just change the event type to
Type.CRS in the MapViewport.setCoordinateReferenceSystem method.
http://jira.codehaus.org/browse/GEOT-3561
Michael
On 4 May 2011 20:33, Michael Bedward wrote:
> Hi Jody,
>
> Just looked for you on IRC.
>
> I found the problem w
Hi Jody,
Just looked for you on IRC.
I found the problem with CRSLab. The old event handling set a bit
flag MapBoundsEvent.COORDINATE_SYSTEM_MASK and JMapPane checkes for
that. The new event handling in the MapViewport class always sets the
event as MapBoundsEvent.Type.BOUNDS. I guess this mea
Your fuzzy memory beats my blank one. I'll have a quick go with the
debugger and try to work out what is (not) happening.
Michael
On 4 May 2011 19:35, Jody Garnett wrote:
> I cannot remember exactly when we introduced Layer; I thought this was done
> specifically before the last workshop
> (so I
I cannot remember exactly when we introduced Layer; I thought this was done
specifically before the last workshop
(so I would not worry about teaching people all the magical methods for
MapLayer).
thinking...
I do remember putting in a lot of additional effort to get the wms example to
work; s
Hi Jody,
I've been testing some stop-gap changes to JMapPane (as per
http://jira.codehaus.org/browse/GEOT-3560) before committing them.
Some of the example applications weren't working properly and I
assumed my changes had broken them. However, when I revert my local
changes the example are still
12 matches
Mail list logo
