On Jul 25, 12:57 pm, William <[email protected]> wrote:
> yeah V2 sounds more logical, but V3 more efficient, so we need a data
> structure which reflects the relationships between all layers and
> their display state, backed by the V3 MVCArray, which only contains
> the visible layers in the correct order.
I had one idea for this generic data structure, based on the concept
of a SQL query, where the contents of the MVCArray are selected from a
table, based on a where condition, sorted in a particular order.
In this case we want the overlayMapTypes to contain the
"imageMapTypes" where "visible" is true, sorted by "zIndex".
So I made a composite MVCObject that contains mapType, visible and
zIndex properties, and created a generic SQLArray which adapts
MVCArray, with parameters for "select", "where" and "order". Each
layer was given a unique id (primary key) so it is easy for the rest
of the program to retrieve the layers.
so the constructor is as follows:
overlays = new SQLArray(anatomy.overlayMapTypes, {
key: "id",
select: "mapType",
where: "visible",
order: "zIndex"
});
with methods to add() and get() layers.
see the following example:
http://www.william-map.com/20100729/1/overlays.htm
....
--
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.
