Matt,
> only opens an info window if the nearest is within 5km. With 9500
> points each search takes about 90ms, so it should scale to 20k data
> points acceptably.
This is fast. Would you share your algorithm? I'm tracking movement
over specific tiles, so your brute force approach should work even
better when limited to one particular tile (or neighboring tiles when
close to the border).
> porting my code to API v2. The reason I used the "datamark" v2 as my
> foundation was because I didn't see anything marker-like within the
> map athttp://
notebook.kulchenko.com/maps/gridapi.
right; it was just a proof of concept to show that it's possible to
use the same class to work with both APIs. It seems that the Marker
object can be handled in a similar way.
> Paul, re: the latest stuff you said you're working on - does it ever
> create API Marker objects (the way your "datamark" example does)? I am
> definitely still interested in making improvements on what I have
> working right now. In addition to performance, I will mostly likely
> want to draw different-looking markers (color, shape, etc) on the same
> map, which will require more tweaking based on my adaptation from the
> datamark stuff.
I currently don't create API marker objects at all and plan to provide
a lightweight object that callbacks can be attached to. The challenge
is to find a good way to avoid creating too many objects and still be
able to handle multiple overlapping markers in the same location. As I
briefly touched on earlier in this thread, I will probably provide a
callback that will receive an array of markers in the click location.
If you only care about one marker, you can just get the first one.
I also plan to draw markers of various types and colors; I already
have a heatmap-like presentation, but it doesn't currently handle any
interaction.
I'm still testing the idea of creating Markers on the fly (not for the
object on the script, but rather for the objects under the pointer),
but regular object only work for circular and rectangular markers. For
anything more complex SVG/VML needs to be used. The benefit is that
you get all DOM events for "free" without any additional work. the
challenge is that with hundreds or even thousands points I have in a
very small area I end up with dynamically creating large number of
objects, which is not workable.
Paul (
http://notebook.kulchenko.com/maps/)
On Oct 7, 10:22 am, Matt Ball <
mattjb...@gmail.com> wrote:
> On Oct 5, 9:39 pm, Paul Kulchenko <
paulclin...@gmail.com> wrote:
>
> > Matt, are you using the later code with canvas elements, or the
> > earlier example I provided with data: URLs and toDataURL conversion?
> > The latter (data: URLs) worked well, but didn't satisfy all my
> > requirements, so I probably will not do any improvement to it even
> > though the logic I'm working on should be applicable there too. Just
> > wanted to let you know.
>
> I'm using the example athttp://
notebook.kulchenko.com/maps/datamark,
> so I guess that would be the earlier example using toDataURL - though
> it does use a canvas!
> The basic thing I had to modify was to make it never create markers,
> because I want to be able to get info windows on mouse click at any
> zoom level. Instead what my version does is given the latlng of a
> mouse click, it find the nearest "marker" by looping over my array of
> all points and finds the closest one (using the Haversine formula). It
> only opens an info window if the nearest is within 5km. With 9500
> points each search takes about 90ms, so it should scale to 20k data
> points acceptably.
> The only real problem with this is that it searches for a nearby
> "marker" even if the click was nowhere near one - say, in the middle
> of the ocean. This is because the search is initiated by a click on
> the map, not on the tile layer. Since I don't understand terribly well
> how the tile layer works, or what constitutes a click on the overlay
> rather than on the map, I didn't try too hard to get it working with
> the click listener bound to the overlay.
>
> Speaking of which, I know this discussion is in the API v3 thread but,
> in light of Paul's example that I adapted (for v2), I did end up
> porting my code to API v2. The reason I used the "datamark" v2 as my
> foundation was because I didn't see anything marker-like within the
> map athttp://
notebook.kulchenko.com/maps/gridapi.