Just for the record: we upgraded today to api version 1_20 and this problem no longer appears.
Although we requested version 1.9, since this morning we got 1.17 from Google. The API is deprecated, and apparently some plugs are pulled? 1.17 again produced the problems stated earlier in this thread (Invalid BitmapData). This time, upgrading to 1.20 and setting GroundOverlayOptions.renderContent = "false" was successful. - koen On Wednesday, September 30, 2009 9:26:13 PM UTC+2, Koen M wrote: > > Thanks for your response Shaun, Pamela, > > I don't think the effect I see is related to these issues. > In a few days I'll try to reproduce the effect in a simple test app, > which I'll put online along with its code. > > We'll go from there. > > Till then, > Koen > > On Sep 30, 3:53 am, "pamela (Google Employee)" <[email protected]> > wrote: > > I haven't had a chance to read this whole thread, but are you > > perchance referencing this bug? > http://code.google.com/p/gmaps-api-issues/issues/detail?id=834 > > > > That one is due to an Adobe error with sizing large images (more > > comments there). > > > > If not, and you think it's a bug on our end, please file. Thanks! > > > > - pamela > > > > > > > > On Wed, Sep 30, 2009 at 1:53 AM, Shaun <[email protected]> wrote: > > > > > Hi Koen, > > > Sorry I don't have much more good news for ya but I tried something > > > out to determine what was going on with my line drawing in my overlay > > > when it was getting all wacky and it turns out there's some sort of > > > limit (that i have never seen documented) for drawing lines that they > > > cannot be more than 32,768 in height or length (actually they must be > > > less than that, equal to it also fails, must be a 4 byte signed int is > > > my guess). Here's the little test app, I have sliders that go up to > > > 100,000 that adjust the width of the line and the height of the line > > > then the numeric stepper/segmentation kicks in whenever the line is > > > greater than 32767 and it draws segments of whatever length is > > > specified in the stepper, at 32767 with a width/height combo that > > > results in a line longer than 32767 you'll see the line draws fine, > > > step it up to 32768 and now we're in bogus math wrap around territory > > > it's not consistent but if you drag around the sliders you'll find > > > spots where the line becomes more of a shape, if you hit it it will be > > > obvious, shorter segments work too but really just slow it down, 32767 > > > seems to work without a problem, so I solved one of my problems but > > > sort of extended yours since this shows you can have UIComponents (and > > > I would assume sprites) that are larger than the limits I stated > > > initially. I believe the 4096x4096 is only a limitation of the > > > BitmapData object. Sorry I don't have any better news but at least > > > this gives you a little more info that may be useful :( who knows. > > >http://www.shaunhusain.com/LineLengthTest/ > > > Good luck, > > > Shaun > > > > > On Sep 27, 5:00 pm, Koen M <[email protected]> wrote: > > >> Thanks for your reply Shaun. > > > > >> Good to mention the 4096px limitation. I run into this sometimes too > > >> indeed. > > > > >> I guess a GroundOverlay is most often used to overlay a bitmap image > > >> over a Google map. Not so on fietsnet.be; there we use GroundOverlay > > >> to overlay a sprite with its own display hierarchy of vector objects. > > >> So I'm not sure the 4096px limitation applies in this case. > Supporting > > >> that, we manage to groundoverlay 100K by 100K sprite in api 1.9, even > > >> earlier in Flash player 9 (where the limit was 2048px by 2048 I > > >> believe) > > > > >> Anyway, you may be correct that large GroundOverlays no longer > > >> function due to this reason. Perhaps the overlay content gets > > >> converted to a bitmap unintentionally in the new api, although I > > >> explicitly opt to not do so (renderContent=false). > > >> That would be a real pity as we'd have to stay with api 1.9 then. Is > > >> this a regression issue perhaps? > > > > >> Thanks, > > >> Koen > > > > >> On Sep 27, 9:00 pm, Shaun <[email protected]> wrote: > > > > >> > Hi Koen, > > >> > You might just be hitting a limitation within flash rather than in > the > > >> > maps api, I think you're right it's the sprite size and 1K by 1K > > >> > should work and 100K by 100K shouldn't work (4096px * 4096px at > max) > > >> > so you could get 1/25th of you're data, the only other option I've > > >> > seen is cutting up the original image and loading pieces of it into > > >> > different bitmap data objects then laying them down next to each > other > > >> > using flash (so you could do this making 5 rows and 5 columns out > of > > >> > you're image). Check out the posts herehttp:// > www.bit-101.com/blog/?p=1426 > > >> > about the size limitations in the comments there's some links to > > >> > potential solutions depending on your needs. Sorry I can't be more > > >> > specific I have run into this problem myself with drawing line's > > >> > between points on the map when I'm zoomed in really far since the > > >> > starting point can be far off screen, I don't get an error but my > > >> > lineTo or curveTo calls end up drawing these huge shapes, it > appears > > >> > some sort of estimation that is used in drawing the lines gets > wacky > > >> > when it's drawing over a huge distance, so far I've just toggled > the > > >> > visibility off when the zoom level is high which is sort of ok > because > > >> > you can't see where the line is going to if you're zoomed in that > far > > >> > anyways, but obviously its not ideal. Also I don't have anything > on > > >> > the additions to GroundOverlay, was this working for you at some > > >> > point, seems strange if it was? Only way I could see this working > is > > >> > because you're loading the image rather than calling the > constructor > > >> > on a bitmapData with a size larger than 4096x4096 which I've heard > is > > >> > a hack to get around the limitation. > > >> > Good luck, > > >> > Shaun > > > > >> > On Sep 27, 5:26 am, Koen M <[email protected]> wrote: > > > > >> > > Hi all, > > > > >> > > I was working on our fietsnet.be project today, and > unfortunately I > > >> > > did not manage to upgrade that app from Google Maps flash api 1.9 > to > > >> > > 1.16 > > > > >> > > The error occurs in a custom GroundOverlay object, to display a > 100K > > >> > > by 100K pixel sprite object as overlay. Apparently the dimension > of > > >> > > the sprite is the problem, as reducing it to say 1K by 1K solves > it. > > > > >> > > Unfortunately, reducing the dimension is not an option for us. > The > > >> > > sprite is our base container for bicycle track networks in a > large > > >> > > geographic area, and we noticed polylines are not accurately > > >> > > positioned in Flash beyond two decimal digits. By going from 100K > to > > >> > > 1K we'd lose a hundredfold in positional accuracy; this would be > > >> > > become strongly visible when zooming in. > > > > >> > > I understand that in api 1.11, GroundOverlay was adapted a bit to > to > > >> > > accommodate for 3D viewing. Apart from setting > > >> > > GroundOverlayOptions::renderContent=false, are there additional > things > > >> > > I should know to make this approach work again? > > > > >> > > Thanks heaps, > > > > >> > > Koen | fietsnet.be- Hide quoted text - > > > > >> > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Google Maps API For Flash" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-maps-api-for-flash/-/kBgGzqXqbCcJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-api-for-flash?hl=en.
