The following assume one is aptly logged in:
The older Markers were deprecated less than 2 weeks ago. The Advanced Markers required a MapID. A MapID is created in and associated with a Goo Cloud project.
For a few weeks in Feb, 2024, I had a working example. I've turned those off. The (public) code will still work if you make your own copy live and get your own key. Those examples were the early stages of a paid project. I will keep documenting stuff here as I work on that project.
Discussion:
It appears that MarkerClustererPlus got absorbed into the main Goo project. After a bit of digging, I am reasonably sure that this is the current version including client-side JS distributions. As of roughly January 29, 2024, the current version is 2.5.3. You invoke this version with "new markerClusterer.MarkerClusterer({map: GooMapObject, markers: markersArray });" The relevant comment in the README is "When adding via unpkg, the `MarkerClusterer` can be accessed at `markerClusterer.MarkerClusterer`." "Unpkg[.co?]" was a CDN site. I made my own copy. The code is under the Apache License, which I am reasonably sure allows copies (free and open source).
Meanwhile, I got "images" from another repo. It would appear that images are strewn about a number of repos. My current local copy gets them from and older "Plus" version. Here are some related links, all of which may be old:
Running over a few days:
marker clustering and other interesting-looking stuff.
Marker clustering solves the following problem quite well.
I made an observation that there is a non-linear effect from 750 markers to 1,500 to 3,000. I have an old computer but I was surprised at the degree it became CPU bound (client side JS) and crawled trying to render 3,000 markers. 1,500 is much faster but still slow. 750 is fairly fast, as I remember. At 3,000 markers the speed is unacceptably slow. 1,500 is still unacceptable. 1,000 and 750 are borderline. 400 is much better, but one can still see the rendering. One can still see it at 200. 100 is fast enough, although rendering is visible.
Note that styling map labels, below, involves creating a "map ID."
If you click the map and then start moving the pointer, you'll draw a line. If you click again, the line segment ends and moving will make the next side of the polygon. When you touch the original point, after 3 or more segments, Goo will shade the area of the polygon.
I need to display markers (pins) based on user data and then allow the user to select a polygon. Then I will check (on the server side) whether the various pins are within the polygon.
Here, I'm documenting this process and making note of non-obvious points.
For this first version, the code is (essentially) all on the front-end (so you can see it in a browser). Some notes on the code, starting (more or less) from top to bottom:
To start with the API script line, the browser console complained if I didn't have the async and callback params. Given the way the callback is declared, I defined initMap() above the Goo API inclusion (script tag). If I didn't do this, I could get an error to the effect that initMap() is undefined because it needs to be defined before the API inclusion line. Apparently one has to declare one's libraries, too. The drawing library allows one to draw the polygon.
To get an API key, you have to create a Goo Cloud project in the Cloud console. You have to include the Maps API in the project (using the console). You (almostly certainly) must have Billing / a payment method attached to the project. I am not certain about Maps alone. I started with a related API, and it enforced a payment method. Maps alone must likely would enforce this, too.
Note that the API key is publicly available in the HTML code, so you should secure its use. So far, I'm testing 4 different types of restrictions.
You set API, http referrer and IP restriction in the APIs & Services / Credentials Goo Cloud (console) menu. Note that IP restriction dosen't work in this case because the users' IP addresses are sent to the API from JavaScript / their browsers. My project is using 2 APIs, so I restricted the key to Maps.
Under AIM & Admin, you can set "Quotes & System Limits" per minute and day.
I'll link (eventually) to the prices for Maps. The amount wouldn't matter unless someone were malicious or you have a lot of users. During 6 hours of testing, I would have run up 41 cents, although there are mysterious "credits" have have made that 0. I have not figured out where those credits are coming from or how many I have. Under "Budgets & Alerts," you can set alerts when the money value goes beyond certain points. Based on my experience, the billing report takes at least 7 hours to catch up with usage. I'm not sure yet how long the quota count report takes: at least 45 minutes.
There were no surprises with the Map or Marker calls. The Marker "title" is the hover-over text.
It was very important to define the proper drawingMode for the drawing tools. That setting makes the user's actions a polygon draw by default. The drawingControl(s) would give the user several options. I turned them off (false) because I just care about polygons right now.
When the user connects back to the starting point and creates a polygon, the relevant handler gives the vertices of the polygon in the "coordinates" array in my code.
I included the click handler (in the original version) only to point out that it does not do what I expected. It doesn't even fire at all, as best I can tell, at least not with my settings. Supposedly the raw DOM click handler fires then the drawing tools then the map, but I'm not sure that happens, and it's not useful in my case in any event. The "polygoncomplete" action is all I care about for now.
In my original versions (in GitHub), these links were in the JS / HTML code.