Google Maps pas meer markers laten zien bij inzoomen

[Verwijderd]

Voor een projectje wil ik een aantal markers op de wereldkaart laten zien. Ik heb me ingelezen en heb via de normale Google Maps, via Leaflet en via GMAP3 al wat werkende voorbeelden geproduceerd. So far so good.

Wat ik me nu afvraag, stel dat ik totaal 1000 markers heb. Die wil ik dan liever niet allemaal direct laten zien, dat lijkt me onnodig zwaar. Het liefste gewoon beginnen met elk werelddeel 1 (of een paar) markers, en als je daar op inzoomt dat hij er dan steeds nog een paar extra laat zien, totdat hij ze in een bepaald stukje allemaal laat zien als je heel erg ingezoomd bent.

Ik zie dit in veel voorbeelden, bijvoorbeeld op http://www.windfinder.com of bijvoorbeeld op Funda.nl, dus het moet mogelijk zijn. Ik heb alleen geen idee wat de techniek hierachter is. Volgens mij kan je niet het inzoomniveau checken terwijl iemand bezig is met zoomen en in de tussentijd op basis daarvan een nieuwe query voor meer markers doen, toch? Kan iemand misschien een duwtje in de goede richting geven?

2e vraag: ik las dat Google 1 'hit' rekent voor het raadplegen van een map. En dat je er 25.000 per dag gratis mag hebben . Is die hit ook nog afhankelijk van het aantal markers en hoe vaak iemand inzoomt op een map? Want dan zit je er zo aan met 1000 markers.

[MadGazelle]

ff googlen op marker clustering......dat is waar je naar moet gaan kijken met dergelijke hoeveelheden....

Als je idd 1000 markers hebt, dan gaat IE in ieder geval plat bij load......Firefox en Chrome kunnen dat soort hoeveelheden aan, maar ik raad het absoluut af...

Bij een zoomactie wordt dat deel van de map opgevraagt bij de server (hetzelfde deel, maar dan op een andere resolutie). Dat wordt normaliter gezien als een 1 view. Hetzelfde geldt voor panning; dus 1 keer de map verschuiven is weer een view. De vraag is even of Google rekent hits per map of per view. De hoeveelheid markers heeft, voor zover k weet, geen invloed hierop.

[Verwijderd]

Dank je MuseFan, dankzij je hulp kwam ik op https://developers.google.com/maps/articles/toomanymarkers terecht en de MarkerClusterer is inderdaad degene die ik kan gaan gebruiken. Via het linkje daar ook nog een paar voorbeelden dus ik ga hier wel uitkomen denk ik. Nogmaals dank!

[MadGazelle]

You're welcome! Thanks voor de terugkoppeling.

[R4gnax]

Verwijderd schreef op donderdag 30 augustus 2012 @ 15:27:
Dank je MuseFan, dankzij je hulp kwam ik op https://developers.google.com/maps/articles/toomanymarkers terecht en de MarkerClusterer is inderdaad degene die ik kan gaan gebruiken. Via het linkje daar ook nog een paar voorbeelden dus ik ga hier wel uitkomen denk ik. Nogmaals dank!

De MarkerClusterer heeft een grove fout in de implementatie van het clustering algoritme dat niet overal consistent rekening houdt met de wrap-around in longitude (tussen -180 en+180 genormaliseerd).

Een voorbeeld:
Gegeven een cluster met een centrum gelegen op lat/lng (0, -170) en een marker gelegen op (0,+170). De afstand tussen beide punten wordt door het algorithme correct berekend op basis van een verschil van 20 graden longitude. Deze afstand is kort genoeg voor de marker om aan de cluster toegevoegd te mogen worden. Nu wordt het gewogen centrum van de cluster aangepast. Dit gebeurt echter niet op basis van de kortste afstand, maar gebruikt een gewone, simpele lineare interpolatie tussen -170 en +170. Het nieuwe centrum kan hierdoor, afhankelijk van de zwaarte van het huidige centrum, heel ver richting longitude 0 verschuiven.

Het zijn dat soort grote verschuivingen die het clustering algoritme compleet overhoop sturen. Zonder dit te corrigeren is de clusterer dan ook compleet waardeloos voor alles wat markers op wereldschaal moet distribueren of op eniger wijze in de buurt komt van de breeklijn op +/-180 longitude.

Verder zijn sommige interne delen van de clusterer ook behoorlijk inefficient geschreven; partiële berekeningen van veel gebruikte constantes zoals 0.5 * PI worden bijvoorbeeld niet vantevoren 1 maal uitgerekend en daarna hergebruikt. Ook relatief dure operaties zoals Math.sin of Math.cos worden vrolijk 3 tot 4 maal herhaald met dezelfde invoer, ipv het resultaat eenmaal uit te rekenen en in een tijdelijke variable bij te houden.

Er zat geloof ik ook nog ergens een berekening in die wegens nummerieke onnauwkeurigheid van floating point getallen kan resulteren in delen door nul. Dat zou NaN terug geven en alle daaropvolgende berekeningen voor een cluster overhoop halen.

[ Voor 7% gewijzigd door R4gnax op 02-09-2012 14:27 ]

[MadGazelle]

Hmmm, interessant! Thanks R4gnax!

[Verwijderd]

Hmmmm, da's niet zo mooi allemaal. Raar dat Google dat niet 'even' verbetert dan. Nou ja, we houden het in de gaten...

[R4gnax]

Verwijderd schreef op dinsdag 04 september 2012 @ 13:06:
Hmmmm, da's niet zo mooi allemaal. Raar dat Google dat niet 'even' verbetert dan. Nou ja, we houden het in de gaten...

MarkerClusterer is niet een officieel onderdeel van Google Maps, maar een open-source third-party plugin.

Ik liep voor een website die mijn werkgever ontwikkelt voor een speler in de reisindustrie tegen bovengenoemde problemen aan en heb het clustering algoritme uiteindelijk maar zelf compleet geherimplementeerd. Dat scheelde flink: clusteren was met dezelfde set data bijna 2x zo snel.

Overigens is het longitude probleem vrij makkelijk op te lossen door gebruik te maken van de geometry library voor Google Maps; deze implementeert een nette spherical linear interpolation (slerp) waar je gebruik van kunt maken.

[ Voor 14% gewijzigd door R4gnax op 04-09-2012 20:08 ]

[Verwijderd]

Aha okee, komt de wiskunde me misschien nu eindelijk eens van pas. Hoeveel regels code had jij nodig voor het algoritme? (zomaar uit belangstelling, geen request).

2e vraagje: ik heb waarschijnlijk toch wel 5000 punten nodig in de maps. In het voorbeeld van de MarkerClusterer laden ze een data.json bestand in met 1000 markers en dat bestand is 454kb groot. Als ik er nou 5000 in moet laden zal dat bestand wel ongeveer 2,5MB worden. Is dat niet heel groot? Ik vind een plaatje van 100kb inladen al groot en lang duren voor de bezoeker.

[pieturp]

De grootte van de JSON is natuurlijk sterk afhankelijk van de hoeveelheid data die je wilt dat elke marker bevat. In 't simpelste geval is dat alleen een lat/long. Dat kun je misschien zelfs het best in een Array zetten. In ieder geval is dit waarschijnlijk overkill:

JavaScript:

{
    "photo_id": 6789223,
    "photo_title": "Exploding sky",
    "photo_url": "http://www.panoramio.com/photo/6789223",
    "photo_file_url": "http://mw2.google.com/mw-panoramio/photos/medium/6789223.jpg",
    "longitude": -69.930505,
    "latitude": 12.522579,
    "width": 500,
    "height": 333,
    "upload_date": "30 December 2007",
    "owner_id": 89499,
    "owner_name": "Michael Braxenthaler",
    "owner_url": "http://www.panoramio.com/user/89499"
}

En ja, dat is zomaar één marker uit jouw voorbeeld

Overigens, mocht je nu wél zoveel info willen meesturen, kun je altijd nog aan lazyloading-oplossingen gaan denken...

[R4gnax]

Verwijderd schreef op dinsdag 04 september 2012 @ 21:19:
Aha okee, komt de wiskunde me misschien nu eindelijk eens van pas. Hoeveel regels code had jij nodig voor het algoritme? (zomaar uit belangstelling, geen request).

2e vraagje: ik heb waarschijnlijk toch wel 5000 punten nodig in de maps. In het voorbeeld van de MarkerClusterer laden ze een data.json bestand in met 1000 markers en dat bestand is 454kb groot. Als ik er nou 5000 in moet laden zal dat bestand wel ongeveer 2,5MB worden. Is dat niet heel groot? Ik vind een plaatje van 100kb inladen al groot en lang duren voor de bezoeker.

Als je gzip er over heen jaagt zou dat echt geen 2,5 MB mogen worden. Verder belet natuurlijk niets je om markers in gedeeltes in te laden (en evt. je clustering iteratief bij te werken) om zo je resultaat te 'streamen'.

Het algo zelf is niet zo moeilijk te implementeren en valt in dezelfde orde van grootte als MarkerClusterer's implementatie. Ik heb er echter een paar lagen indirectie tussenuit gesneden waardoor het wat compacter kon, en ik had al wat helper methodes voor jQuery liggen, die een array partitioneren en daar dan gescheiden door setTimeout calls overheen kunnen lopen. Dat maakt het voorkomen van script timeout warnings bij grote datasets ook weer een stuk simpeler.

Dat laatste is echter eigenlijk maar een lelijke 'poor man's threading' en ik wil nog eens kijken naar een echte HTML5 Web Worker implementatie. Dan moet Mozilla alleen wel eens opschieten en zorgen dat Firefox niet crasht zodra een worker postMessage aanroept om resultaat terug te geven aan de main thread en daar in de aan de worker gekoppelde message event handler een breakpoint staat.

[ Voor 3% gewijzigd door R4gnax op 04-09-2012 22:37 ]

[Verwijderd]

Inderdaad Pieturp, dat is ook zo. Ik heb genoeg aan een naam, lat, long, een url en misschien nog een url van een plaatje. In het begin zal ik nog weinig punten hebben en als het erg gaat groeien met markers dan zal ik een oplossing proberen om de markers in gedeelten te laden zoals R4gnax zegt (als dat me gaat lukken ).

Wat me nog opviel, het bestandje markerclusterer.js uit mijn voorbeeld is ongeveer 32,5k en het bestandje markerclusterer_compiled.js is bijna 8k. Maar er is niets compiled aan, er staat gewoon geen commentaar en spaties/returns in.

[R4gnax]

Verwijderd schreef op woensdag 05 september 2012 @ 15:18:
Inderdaad Pieturp, dat is ook zo. Ik heb genoeg aan een naam, lat, long, een url en misschien nog een url van een plaatje. In het begin zal ik nog weinig punten hebben en als het erg gaat groeien met markers dan zal ik een oplossing proberen om de markers in gedeelten te laden zoals R4gnax zegt (als dat me gaat lukken ).

Wat me nog opviel, het bestandje markerclusterer.js uit mijn voorbeeld is ongeveer 32,5k en het bestandje markerclusterer_compiled.js is bijna 8k. Maar er is niets compiled aan, er staat gewoon geen commentaar en spaties/returns in.

Dat is echt wel gecompileerd hoor.

Ten eerste is een compiler eigenlijk niets anders dan een programma dat taal x in taal y om kan zetten. Er is hierbij niets dat zegt dat x en y niet dezelfde taal kunnen zijn.

Ten tweede: als je code met bijv. Google Closure Compiler of UglifyJS compileert wordt er ook echt een abstract syntax tree (AST) gegenereert aan de hand waarvan die code ook via een aantal complexere transformaties geoptimaliseerd wordt.

Zo kan een AST gebruikt worden om te besluiten welke variable namen 'veilig' zijn om af te korten en kan code herschreven worden met een alternatieve korte naam, maar bijvoorbeeld ook om code patronen te herkennen en om te schrijven naar snellere en/of kortere varianten. Zo kan if (a) { b(); } bijvoorbeeld omgezet worden in a && b();.

[Verwijderd]

Oh, aha, ik zie het, oops.