GeoRef should be used if present

[apollolm]

In the case of FSP, where all of the GeoJSON is loaded when the page loads, and filters are being applied later, q-cluster shouldn't necessarily do the geodeticToGeoRef(lng,lat,4) operation every time. Once the georef is created once, the property could be stored in the GeoJSON. Subsequent filtering and re-clustering would not have to recalculate it.

Also, if the GeoJSON object already has a GeoREF property, then it should be used instead of calculating it.

I bring this up because the clustering time when filtering is about twice as slow as before. (~3 seconds to filter and recluster about 60,000 points as opposed to about 1 or 1.5 seconds when GeoREF is pre-calculated and used for clustering). Not sure if this is the GeoREF calculation or the GeoJSON parsing that is happening now.

[rgwozdz]

Ah - you have uncovered a bug introduced in the refactor. I didn't notice this in pmt, because the points are coming pre sorted by georef. I know how to handle your issue. Not sure I will store it in the GeoJSON...as far as I know we don't use the GeoJSON once the layer has been instantiated. Still, I know the issue you are talking about and am confident it can be easily resolved. I will add the capability; the key will probably be not reinstantiaing a new layer after each filter, but rather passing an array of "filtered point ids" into q-cluster function.

Incidentally, I think I am ditching GeoRef for GeoHash (http://en.wikipedia.org/wiki/Geohash). Finer resolution (I think) and some interesting possibilities.

---

Rich Gwozdz
Software Developer
Spatial Development International, LLC
2208 NW Market Street, Suite 202
Seattle, WA 98107
http://www.spatialdev.com/
skype: rich.gwozdz
email: [email protected]

phone: +1 206.769.6808

On Feb 28, 2014, at 3:16 PM, Ryan Whitley [email protected] wrote:

In the case of FSP, where all of the GeoJSON is loaded when the page loads, and filters are being applied later, q-cluster shouldn't necessarily do the geodeticToGeoRef(lng,lat,4) operation every time. Once the georef is created once, the property could be stored in the GeoJSON. Subsequent filtering and re-clustering would not have to recalculate it.

Also, if the GeoJSON object already has a GeoREF property, then it should be used instead of calculating it.

I bring this up because the clustering time when filtering is about twice as slow as before. (~3 seconds to filter and recluster about 60,000 points as opposed to about 1 or 1.5 seconds when GeoREF is pre-calculated and used for clustering). Not sure if this is the GeoREF calculation or the GeoJSON parsing that is happening now.

—
Reply to this email directly or view it on GitHub.

[rgwozdz]

Are you sure that the geodeticToGeoref is the source of the delay? Not that it matters, just curious.

The approach I will take to solve your noted issue will probably require each point to have a point ID property. Is that going to be ok?

R

On Feb 28, 2014, at 3:16 PM, Ryan Whitley [email protected] wrote:

In the case of FSP, where all of the GeoJSON is loaded when the page loads, and filters are being applied later, q-cluster shouldn't necessarily do the geodeticToGeoRef(lng,lat,4) operation every time. Once the georef is created once, the property could be stored in the GeoJSON. Subsequent filtering and re-clustering would not have to recalculate it.

Also, if the GeoJSON object already has a GeoREF property, then it should be used instead of calculating it.

I bring this up because the clustering time when filtering is about twice as slow as before. (~3 seconds to filter and recluster about 60,000 points as opposed to about 1 or 1.5 seconds when GeoREF is pre-calculated and used for clustering). Not sure if this is the GeoREF calculation or the GeoJSON parsing that is happening now.

—
Reply to this email directly or view it on GitHub.

[apollolm]

No, I'm not sure. I was just looking for what I thought was a redundant conversion function...

Id should be fine...

Thanks!

On Mar 2, 2014, at 8:38 AM, rgwozdz [email protected] wrote:

Are you sure that the geodeticToGeoref is the source of the delay? Not that it matters, just curious.

The approach I will take to solve your noted issue will probably require each point to have a point ID property. Is that going to be ok?

R

On Feb 28, 2014, at 3:16 PM, Ryan Whitley [email protected] wrote:

In the case of FSP, where all of the GeoJSON is loaded when the page loads, and filters are being applied later, q-cluster shouldn't necessarily do the geodeticToGeoRef(lng,lat,4) operation every time. Once the georef is created once, the property could be stored in the GeoJSON. Subsequent filtering and re-clustering would not have to recalculate it.

Also, if the GeoJSON object already has a GeoREF property, then it should be used instead of calculating it.

I bring this up because the clustering time when filtering is about twice as slow as before. (~3 seconds to filter and recluster about 60,000 points as opposed to about 1 or 1.5 seconds when GeoREF is pre-calculated and used for clustering). Not sure if this is the GeoREF calculation or the GeoJSON parsing that is happening now.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.