Question : Internet mapping applications - benefits of sending vector data to client browser

Hello

I need some information to help to help me plan a web mapping application i am developing.

In the basic model for internet web mapping applications each pan/zoom operation sends a request to the server and a new map is redrawn and sent to the client as a simple image. I was wondering if it was possible to cut down on some of the processing time by sending the vector data to the client and then processing the maps on the client side.

I also thought that this might not be possible because of the sheer size of the vector data that you would have to send to the client. You would also have to make sure the vector data was removed from the client's machine as it would violate your licensing agreement for the map data if it was left on someone else's machine (well it would mine anyway).

I was wondering what people's thoughts were on this issue. Is it worth looking into a solution for sending vector data to the client or is it not worth the effort in terms of speed gains. My application isn't actually that slow sending each pan/zoom to the client but you have the potential to produce more effects with your map data if you don't have to keep making requests to the server.

Many thanks for your help
andrea

Answer : Internet mapping applications - benefits of sending vector data to client browser

I just thought about how much data would be required to draw a map of reasonable accuracy - I haven't thought of a specific implementation (yet). I don't have one ready, either.

I see the following ways to handle this:
A - Download all data to the client and tell the client which part of the map to draw. Huge download at the beginning, very efficient later because you'd need to transmit the borders of the map only. I guess this is what you're doing today.

B - Only download that part of the map which the user is interested in to the client. Quite efficient on the download side but requires you to some heavy maths on the server (because you'd need to calculate new endpoints for all vectors at the border of the map, remove all vectors outside of the map and those in the sub-pixel area). I actually wouldn't recommend this; calculation of a submap may require a few seconds of CPU on a server, so you couldn't server more than five or ten users with one box (just a rough estimate, I might be wrong here).

C1 - A variant of B where you work with pre-calculated maps of various sizes. When a request a map, you find the next bigger map available and send it; the client would then do the re-calculations.
C2 - Same idea but the server re-calculates the boundary vectors.

Both C1 and C2 require lots of storage for the pre-calculated maps plus some math on the client or server. It may be the most efficient solution at run-time but it requires quite a bit of coding work.

So, it depends a bit on your requirements and budget... If you have the ressources, I'd go for C2 (less constraints for the client) or C1 (less pressure for the server). If this has to be finished very quickly, A is the way to go - it's probably quite easy to code. B isn't really an option, I believe.