RandomEtc's dashboard

Not sure what's happening here. Can you post your full WMS provider constructor call?

It might be worth specifying an explicit zoom level in a call to setCenterZoom instead of setCenter... zoom levels can be tricky to derive but in general the projections we're using treat the whole world as 1 or 2 tiles at zoom level 0 and double the width and height after that. Try zoom level 17 or 18, judging by your MapExtent it's a pretty small area you're looking at?

The Bing Bird's Eye maps are great, but I've never seen them working with Modest Maps. It's not a simple question :) – RandomEtc, on October 14, 2009 21:38

Yes, it seems like Nathan took a couple of short cuts! Glad you found it.

Sorry, I just realised you already confirmed it's not a bad value. Let us know if you're using the debugging stuff, it will help locate the problem. – RandomEtc, on October 14, 2009 17:54

Hi Eric,

I'm not overly familiar with that exact code, but you might check a few things.

First make sure you're compiling and running with debugging enabled and using the debug version of the flash player - that way if an error occurs you'll find out where it is in your code.

Second, perhaps it's an erroneous value in your data? A bad lat/lon that doesn't get parsed might cause an error. Or if the size of the dots depends on a value from your file, watch out for errors like divide by zero.

There isn't a limit on numbers of Sprites that I'm aware of, except for the performance-related implications of trying to do too much stuff per frame in animations.

Tom.

Thanks for the bug report. Can you confirm which version of Modest Maps you're using?

If it's actionscript 3 then a short term fix could be to set map.grid.enforceBounds to false - does that help?

Otherwise a few things need rearranging in the TileGrid so that bounds are enforced correctly before events are dispatched - I've added this issue to the google code issue tracker and hopefully someone will get to it in the next couple of weeks (probably me!) http://code.google.com/p/modestmaps/i...

Flex is built on top of Flash as you're aware, and reuses a lot of the basic Flash elements. However, Flex overrides some of the default Flash behaviours (like addChild) in complex ways. For example, Flex components expect to be measured and sized by their parents. Flash components don't do anything except display graphics/text, it's up to you to measure and position them.

It's hard to write things that work both the Flex way and the regular Flash way. We chose not to worry about Flex, so I don't know for sure how to fix things to work the way you expect. Sorry!

Yes, that would work. You can use the Modest Maps python code to do things like this using a similar format for map providers. – RandomEtc, on September 16, 2009 14:44

What does the data look like? Can you link to an example?

It should be quite easy to adapt a common output format to Modest Maps. We haven't added this to the library because it's a fairly big commitment to maintain against all the different implementations, but if you have a specific one in mind it should be quite easy.

Look for examples that reference MarkerClip (this is built-in to Map, see Map.putMarker) and for polygons see PolygonMarker. You can safely ignore the Overlay and PolylineClip classes unless you know they do something you need.

e.g. http://modestmaps.googlecode.com/svn/... and http://modestmaps.googlecode.com/svn/...

Hi Neil,

Aha. Tricky. We might sound very mean and snooty, but...

It's a stated aim of Modest Maps to not include default markers, info windows and so on. That's for you to do yourself... if you wanted everything to look the same you'd just use Google Maps :)

However! There are some things like this in a Flex Builder project called Modest Maps Examples included in the source repository. And I'm interested in having things available for myself that make this sort of thing easier too.

I've posted an example at http://blog.modestmaps.com/2009/02/he... that's extremely simple, but it's easy to adapt to an infobubble that could also contain text, images etc.

As for why not addChild, if anything I think it was a mistake to add MarkerClip to Map at all. It should be completely separate functionality and only talk to Map via MapEvents. Overloading addChild for markers would be bad - there's quite a lot of complicated stuff that happens in MarkerClip to keep things off the stage unless they're visible... conflating that behaviour with the default behaviour of addChild would be confusing. Better that addChild does what it does with regular Flash DisplayObjects and putMarker (or attachMarker, sorry for the inconsistency) is the function you call to hand over responsibility for adding/removing as necessary.

Hope that makes sense! Let me know if you have any specific questions about the infobubble example and I'll try to help out as best I can. But in the short term it's unlikely we'd add anything like this to the library: we're expecting custom implementations of this kind of thing and Google, Yahoo and UMapper provide libraries for people who want out of the box functionality already.

It's definitely an attractive feature. The looping doesn't really take up much time though - I've timed it to less than 10ms per frame at its heaviest, and mostly 1ms. This makes sense when you consider that most of the arrays and dictionaries Modest Maps uses contain less than 100 things. And matrix maths is fast too.

The biggest overhead is rendering, and I'm interested in rearranging our use of the display list to keep that overhead to a minimum, but that wouldn't really need Flash 10.

Something you might want to try is to copy MarkerClip to MarkerClipTen and change the Arrays it uses into Vectors. I imagine for maps with lots of markers that it would help to have those loops run quicker when panning and especially when animating a zoom.

Hi,

This is my fault, sorry. The three errors above can be corrected in ModestMapsSample.as by changing the following values:


MarkerEvent.CLICK should be MarkerEvent.MARKER_CLICK
MarkerEvent.ROLL_OVER should be MarkerEvent.MARKER_ROLL_OVER
MarkerEvent.ROLL_OUT should be MarkerEvent.MARKER_ROLL_OUT


This is to avoid clashes (and event type errors) if you're also listening for MouseEvents on the same map.

We'll try to update the downloads soon - thanks for letting us know.

Right! Good stuff. Thanks for the speedy response. We're digging around TileGrid quite a bit in the new Google Code repository. It's not currently getting any cleaner, but it really should soon. Watch this space! – RandomEtc, on August 26, 2009 02:46

What modification did you make? Was something wrong, or was it just to get it working with the Flex ProgessBar? – RandomEtc, on August 26, 2009 02:20

No, there are no plans to fix it. We will redirect to Google Code soon. – RandomEtc, on August 26, 2009 02:19

Hi there - thanks for letting us know. We're going to move over to a new subversion host soon, sorry for the delay.

You can browse the repository via http (without trac) here:
http://modestmaps.mapstraction.com/sv...

There are a few ways to do this. My suggestion above is the quickest - use the calculator to define a transform where you pretend that latitude is y-pixels and longitude is x-pixels and use a LinearProjection. There might be a few places where this is awkward and annoying to code, but there's no real reason it wouldn't work reliably apart from that.

Another option is to make a copy of Map.as or TweenMap.as and adapt it to use Points instead of Locations. For the most part, TileGrid doesn't know about geography (only Coordinates) and Map handles the conversion from geographical Location (lat/lon) to Coordinates (row/col/zoom). So you could make PixelMap or something that does a translation from image pixels to row/col/zoom... does that make sense?

I'd try a dummy projection that treats lat/lon as pixels first though. That's something like what we ended up doing for http://sfmoma.org/artscope and http://calacademy.org/map

Not with Modest Maps. Routing requires a lot of server side support.