Short evaluation of neighbor detection using topojson
This will be only a quick and (maybe) dirty evaluation of the neighbor detection that I’ve implemented: http://wwwpub.zih.tu-dresden.de/~rklammer/html/vorlagen/RKMapping_neighbor_finding.html
After that, I found out, that there is also a function for neighbor detection included to topojson.js … but … it seemed to be a bit slower than my version … this has to be analysed!
Pretty simple…just do this for each feature:
- loop through the geometry of a feature
- extract all arcs (at least only there id’s)
- analyse the members of each arc (arc has to have the info about its members included for that)
- 1 member = no neighbor – 2 members = a neighbor
Analysing the performance
The analysis will be a little bit dirty, as I will not calculate an arithmetic mean of many test results. This is possible, as I am more interested in the relative time differences, between datasets of different feature amount, than in their absolute values! As you can see (and test by yourself) in the interactive test scenario, I used:
- clipped –> 2946 features
- full –> 11626 features
- states (full) –> 16 features
- counties (full) –> 402 features
Now…lets have a look at the table!
Basically, my own function seems to be faster than the topojson function. But I need the ArcCollection for being able to detect the members of each arc…so I have to include the processing time of that too. That is why the table contains a column for the getArcs() as well for the getArcsOfNeigbors() functions.
Processing, only 16 german states, took all together 0,06s which is compared to 0,008s way more processing time. That means topojson is ca. 85% faster than my function.
This seemingly advantage is also detectable for the processing of 402 county features. There we have 0,285s (total) against 0,185s, what is only ca. 35% faster then my function.
I said seemingly, because the next two datasets show the difference in performance between both functions. The processing of the ArcCollection still takes way more time than following neighbor detection, but all in all it takes 0,204s while topojson.js takes 1,005s. Now my function is ca. 80% faster.
This first indication is manifested by the last, hughest dateset (11626 features). Here, topojson.js takes long 18,513s while my function takes only ca. 1s. That is a ledge of ca. 95%…WOW!
But that seems to be a little bit strange. Topojson’s processing time is rising uproportionally and I do not have a clue why. The processing time of my function, in contrast, grows proportionally…at least the getArcsOfNeighbors() function, which processes super fast!
Finally, let’s have alook at the growth:
Number of features:
- 2512% (16 – 402)
- 733% (402 – 2946)
- 383% (2946 – 11626)
Processing time – topojson.neighbor():
- 2313% (0,008 – 0,185)
- 543% (0,185 – 1,005)
- 1842% (1,005 – 18,513)
Processing time – getArcs() + getArcsOfNeighbors():
- 475% (0,06 – 0,285)
- – 29% (0,285 – 0,204)
- 490% (0,204 – 1,000)
There you can also see the unnormal growth of processing time, for the topojson function. It is not associated with the growth of number of features…a growth of 1842% is almost five times the feature growth (383%)!
On the other hand my implementation does has also have an unproportional growth. At least the getArcs() function processes 2946 municipality features faster then 402 county features. It is a fact but not as drastic as this exemplary values indicate…average mean for 10 test processings:
- Counties (full): 0,157s
- Municipalities (clipped): 0,148s
That is strange and I have to investigate on that more deeply…