On Sat, Jan 21, 2012 at 3:26 AM, Simfake Fake <[email protected]> wrote: > Since i'm not too sure how to reply to the same thread in teh mailing list, > i'll just send this to you.
That's OK -- it's a low enough traffic list that keeping the threads intact is not critical. But ideally, please join the list, then simply cc the list on these emails. > On that note, it's a good bit too difficult to find documentation on how to > call functions when the default map (or guimode) modes are changed. To call > panning mode without clicking the button (when using a navcanvas), it's > self.Cavnas.SetMode(self.NavCanvas.Modes[3][1]). Actually, this is less a documentation problem (though that is a problem), than an architectural one -- the interaction between GUI modes and the toolbar is ugly. I'be been meaning to re-factor that, but haven't got the chance. What I'd like to do is have it be more straightforward: - To change the GUI mode, you call SetMode() on the Canvas - SetMode() should then post an event indicating that the GUI mode has been changed. - the Toolbar (and anything else that needs to know) should handle that event and change its display. This isn't how it works now, rather the toolbar is keeping track of the modes, and setting it on the Canvas -- works OK if the only way to change the mode is with the toolbar, but not so well when you want to change the mode as teh result of other actions -- as you've discovered. >>>I have had in mind a tiled image draw object for a while -- nice to > >>see it done. Do you think your implementation is generic enough to > >>include with the lib? > It may be generic enough for map data, straight from open street maps (and > since google maps/others use the same sort of system (tile sizes, etc), it > may be for them as well), however at the moment it's fairly specific. OK -- hopefully I can take a look and maybe make it a bit more generic -- but you're right, the "google maps style" tiles are a common case, nice to support that. As side note -- I've actually got a project that is kind of FloatCanvas -- like, but specifically for maps, that better supports projections, etc. It also used OpenGL for faster rendering -- it's a bi tof a mess now, so I'm sot sure I want to recommend others use it -- unless they want to contribute a lot to its development.... > But > >>FloatCanvas can't handle that (though it should...) did you project > >>all the coords of your data first? > I think I am. Using the guide > http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames ,I'm simply grabbing > tiles and showing them at the correct distance apart. hmm -- that appears to be doing lat-lon to tile number, so are you using tile number as the "world coordianat" in FC? Or using lat-lon as the world coordinate, and then computing which tile to put where in that -- that would be the better way, and... > The only part that may > be considered complicated is figuring out where to put markers for > particular latitudes/longitudes. This would be dead-simple then if you keep lat-lon as the world coordinate. > Currently i'm working out how far > above/below the tile it is corner it is, then i'm figuring out where the > tile corner is in the floatCanvas, and then i'm moving the circle there. that sound like linier interpolation within a tile, which is probably close enough for just about anything. > really need to test how it works when panning/zooming, as well as how > accurate it actually is. I'll see if I can take a look, but not sure when. Anyway, coolstuff! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ FloatCanvas mailing list [email protected] http://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
