Loading Profile...
Beginner Questions: Transformations and Map Providers
I'm somewhat new to Flash (especially CS3 and AS3) but an experienced programmer in javascript (and java, python, etc). I'd like to use MM (the AS3 release) with custom tiles, and I've gone over the Oakland tutorial, and I have a few questions.
I already have my tileset ... they are rendered from a fairly high resolution shapefile using geoserver. The projection is 4326 (WGS84) which I think would be your linear projection.
OK, here are my questions:
1) If I know the exact boundries of my tileset do I still need to use the calculator? I'm not quite understanding the Transformation construction.
2) To create my own MapProvider it seems all I really need to override is the getTileUrl() method, right? The only other portion that seems non-trivial is defining the limits. The __topLeftOutLimit seems easy enough, but I'm not getting the __bottomRightInLimit. What is going on with the zoomTo(zoom - 8) in defineImageProperties() of AbstractZoomifyMapProvider?
I think that's enough to get me started. MM looks to be a great package and will save me a ton of time in development.
I already have my tileset ... they are rendered from a fairly high resolution shapefile using geoserver. The projection is 4326 (WGS84) which I think would be your linear projection.
OK, here are my questions:
1) If I know the exact boundries of my tileset do I still need to use the calculator? I'm not quite understanding the Transformation construction.
2) To create my own MapProvider it seems all I really need to override is the getTileUrl() method, right? The only other portion that seems non-trivial is defining the limits. The __topLeftOutLimit seems easy enough, but I'm not getting the __bottomRightInLimit. What is going on with the zoomTo(zoom - 8) in defineImageProperties() of AbstractZoomifyMapProvider?
I think that's enough to get me started. MM looks to be a great package and will save me a ton of time in development.
I’m learning MM!
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Hi,
You do still need to use the transformation calculator - the Transformation is for bridging the gap between the geographical projection you're using and the pixels in your image tiles. Internally, it's a small bit of linear algebra that takes the raw output of the linear (or other) projection and converts it to the internal Modest Maps Coordinate form.
The "In" part of "__bottomRightInLimit" refers to the highest level to which you can zoom in on a map. The reason it's calculated with the "zoom - 8" tacked onto the end is because that's effectively a division by tile width and height, 256 pixels, or 2^8. The zoom variable is initially set to the base-2 logarithm of the largest image dimension (which is how far you'd be able to zoom in if tiles were 1x1 pixels), then adjusted by 8 to account for the standard 256x256 tiles that are actually in use.
Hope this helps!
-
Inappropriate?Hey Migurski ... thanks for the response, I have a couple follow-ups and one other additional non-related (but hopefully easy) question.
> You do still need to use the transformation calculator
OK, so then should I just triangulate the entire extent? Say, take the far upper left and right corners and the bottom center? I assume it doesn't matter which zoom level I pick (which is part of the next question)? I have 9 zoom levels which I've numbered from 0-8, but they are completely custom (but do follow the 4^N pattern).
> "__bottomRightInLimit" refers to the highest level to which you can zoom in on a map
I *think* I'm following what you're saying but don't fully understand. If it isn't too much of a bother I was hoping you or someone else knowledgeable could help with my tileset. My bounding box is this:
minlat = 39.0
minlon = -130.0
maxlat = 49.0
maxlon = -120.0
Tiles are 256x256 and as I said, I have 9 levels, 0-8, where the number of tiles at each level is 4^N where N is the level (or 2^N in each dimension). That should be all the relevant information right?
OK, as for my non-related question, it had to do with the AS3 sample FLA file. I can't figure out how the FLA is referencing any of the AS3 code. I don't see any actionscript embedded anywhere in the timeline, and I can't find any settings anywhere else that say where to get the actionscript or the libraries.
Thanks again!
-
Inappropriate?In the as3 fla file in Modest Maps trunk, the setting you're looking for is in the Actionscript 3 settings.
Go to File, then Publish Settings... then Settings... (next to the Actionscript version drop down) you can then add folders to your class path that will be available to .as files in the same directory as your .fla file.
Neither Mike nor I use Flash CS3 however, and someone else wrote the example, so sadly you're on your own with the other details.
I’m not sure how to get a latlng projection working either
1 person says
this answers the question
1 Comment Add a comment
This answers the question
-
Thanks ... that was what I was looking for! I'd prefer to not use CS3 eiher but others in my project require it. -
Inappropriate?Hi,
If I understand correctly, you have that 10° x 10° area fitted to a single tile at zoom level 0, and then you subdivide from there to get the remaining zoom levels? If that's the case, then it sounds like your bottomRightInLimit would be: Coordinate(1, 1, 0).zoomTo(8). (row 1, column 1, zoom 0) is the bottom-right corner of the "world" tile, and zoomTo(8) is as far in as you'd go. Your topLeftOutLimit would just be Coordinate(0, 0, 0).
This gets you as far as proper zoom & pan behavior.
Plugging your values into http://modestmaps.com/calculator.html, I just entered:
49, -130, 0, 0, 0
49, -120, 0, 1, 0
39, -120, 1, 1, 0
...and got back:
var t:Transformation = new Transformation(5.729577951308224, 0, 12.999999999999982,
0, -5.729577951308231, 4.899999999999999);
__projection = new LinearProjection(0, t);
These numbers smell about right to me.
I’m hopeful
1 person says
this answers the question
1 Comment Add a comment
This answers the question
-
I just wanted to let you know I gave it a cursory try and it mostly worked. I might have a problem or two that I'll write about later, but I just wanted to say thanks for the help.
-
Inappropriate?Hey migurski ... your numbers look right to me, that's exactly what I was thinking. I'll plug it all in tomorrow and report back.
Thanks so much for your time ... I'm sure I'll have more for you in the future, and hopefully before too long, I can even contribute something back.
I’m wishing I had software here to test.
-
Inappropriate?I've been playing around with what I have for most of the day and I have two issues that I'm looking at. Some direction would really help and be appreciated.
1) When a zoom is requested the tiles at the current zoom level are scaled up and the new tiles at the next zoom level are placed in over the scaled tiles.
This works great and has a nice effect, but the problem is my tiles are transparent, so the scaled (and relatively ugly) tiles are still visible behind the correct tiles, and it takes a while (sometimes 10-15 seconds) for them to go away. Is there any way to speed up this process?
2) Related ... I'm thinking of not just adding markers but additional tile sets. Essentially, entirely new map providers. Is there any support for this or would I have to build in multiple providers via multiple tile grids?
I’m making progress.
-
Inappropriate?Hi,
1) We've mostly assumed that tiles are opaque, so I'm not sure there's a way to make that process go faster. Are you showing something else through the map, or can you add an opaque shield to your map provider so that lower-res images don't show through?
2) I think you've asked this in another thread - overlays are something we've identified as important. So far, we've been implementing them by creating tile providers with internal layers, but we may go for a more traditional multi-layer approach soon.
1 person says
this answers the question
-
Inappropriate?Hi migurski ... thanks for the response. Here are some comments:
1) Actually ... I figured this one out. It can be adjusted by messing with the condemnationDelay() method in the TileGrid. You can't put it to 0 because it results in flickering, but setting it to about 1/2 a second really helped out.
2) Right ... I broke out my questions into multiple threads as I thought this one was getting off target. Thanks for the suggestion and I'll look for those updates.
How does one get notified of updates? Just check modestmaps.com for new releases?
-
Inappropriate?Awesome, glad the condemnationDelay thing worked for you. It's definitely touchy, since the explicit time setting doesn't in any way account for slow connections, tile loading delays, etc. But if it works, great. =)
Updates: there's an RSS feed on the http://modestmaps.com homepage where we post updates. Right now, a lot of the bleeding-edge work is happening in a branch, where Tom Carden started by implementing some new ideas for the TileGrid:
http://modestmaps.mapstraction.com/tr...
That branch's stability has much improved due to a bunch of recent Stamen projects, so I'm hoping we can fold it back into trunk and give it a release number soon.
-
Inappropriate?Regarding the condemnationDelay ... I've just recently found it and started playing with it. In no way are my tests extensive. I don't completely understand the problem ... aren't there load listeners in flash where you can purge the old tile once the new one comes in?
And thanks for the info on the branch ... I'll be looking forward to updates.
-
Inappropriate?The problem we had was that the load listeners would need to behave differently depending on whether you're zooming in or out: when you zoom in, the old tile can only be purged once its four replacements have loaded. When you zoom out, four old tiles can be purged as soon as one new replacement is done. The process is of course possible, but it seemed a lot easier to assume opaque tiles and just let them expire themselves after what looked like a reasonable time.
The work on the branch in some ways makes the transparency problem even worse: we're experimenting with the idea that there might not be any condemnation at all, and that in fact up to three or four extra layers of zoomed-out tiles would be kept around in the background to smoothen out the visual behavior during fast pans and zooms. A quick pan to one side would reveal and already-loaded, lower-resolution tile for that area until the screen-resolution replacement can be loaded.
EMPLOYEE
EMPLOYEE
