That could work. A better strategy would be to investigate MySQL's spatial extensions (or even better, the PostgreSQL extension PostGIS). Those are much better ways to stores polygons in a database and give you the ability to do a lot more with your shapes on the server side.
On Nov 5, 1:49 pm, PaulG <[email protected]> wrote: > I have done quite a bit of searching around on this group and just > thought I'd post my initial thoughts just in case someone can share > any heads up on what I am about to attempt. > > I am adding the ability to add/edit polygons to a CMS, the backend is > PHP/Mysql. I'd prefer not to have to go out to Google Fusion Tables > for storage. > > An example data set might contain say 20 polygons each with a max of > 100 coordinates. > > I can see us having around 10 of these data sets. > > I plan storing the coords of each polygon in a table as straight json, > that way I can retrieve it pretty painlessly for editing. > > The users would only be editing one polygon at a time. > > I then plan to "bake" (cache) the polygons from each data sets into a > single kml files for display. > > Given that the Gmaps v2 compression method for is now no longer > available, is my idea the correct strategy? > > Would you do it a different way? Pointers, gotchas? > > Thanks a lot. -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. 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-js-api-v3?hl=en.
