Selasa, 13 September 2011
Introduction
There are many web-services out there which provide small code snippets, to let you track your visitors to your site, and in turn these services track you and your visitors, pouring bits into their own data mine,... but that's a different story.
The tracking relies on look up tables which link IP -domains or more often IP -subnet ranges to locations. This has been working well for almost a decade since the advent of comprehensive lists which link a location to various IP addresses. With the arrival of mobile-internet, and crowdsourcing, and great interest (entailing big $$) the detail of location assignment to IP addresses resulted in a resolution at the street-block level. The general approach is called geotracking or geotargeting.
Recently a geolocation API was standardized, allowing browsers (which translates to IP-addressed computer terminals) to reveal their location on an per-request opt-in basis.
The service is part of the navigator object and accessible via javascript as:
getcurrentposition takes two functions, the first is called to pass along positional information in form of one parameter, and the second is called when an error occurs
navigator.geolocation.getCurrentPosition(fnPos, fnErr)
As such entering the following command on your Javascript-console will initiate geotracking in the browser, with a navigation-bar request turning up:
navigator.geolocation.getCurrentPosition(console.log, console.error)
The passed object for instance called 'pos' has the properties
pos.timestamp
pos.cords.longitude
pos.cord.latidude
Proxy-Painting
The interesting idea is that in principle these ip2location tables can be used in reverse by routing dummy-requests to proxies based on a given location. One could then write all sorts of stuff (Pacman comes to mind) , onto these maps, provided the provided spatial resolution of the service is high enough. A sufficiently populated area which has enough proxies present could be re-purposed into a canvas. Since so far I couldn't find anything similar I would call it a proof of principle.
The high enough resolution limits the kind of services somewhat to http://phpweby.com/service/visitormap/
, except that it does not offer heatmap-coloration, thus rendering the service useless for this purpose.
There are a few requirements though:
#constants
There are a few points to determine first:
#implementation
A 10x10 black and white graphics is read into a matrix and multiplied by the canvas matrix of suitable latidue and longitude points.
Each row is processed by a unique thread. Each element within the thread and thus within each row is translated into an IP address and routed to proxy on the other side. (An additional optimization would be to flag proxies which perform a request at the target even with a HTTP-header set to Keep-Alive: timeout=100, max100 whilst subsequently terminating the connection)
After each thread has looped a given number e.g. 1000, each thread is cancelled. Once all jobs are finished worker process initiation starts again in order to maintain syncrhonicity (for the sake of uniformly colored heatmap-pins on a given worldmap).
There are many web-services out there which provide small code snippets, to let you track your visitors to your site, and in turn these services track you and your visitors, pouring bits into their own data mine,... but that's a different story.
The tracking relies on look up tables which link IP -domains or more often IP -subnet ranges to locations. This has been working well for almost a decade since the advent of comprehensive lists which link a location to various IP addresses. With the arrival of mobile-internet, and crowdsourcing, and great interest (entailing big $$) the detail of location assignment to IP addresses resulted in a resolution at the street-block level. The general approach is called geotracking or geotargeting.
Recently a geolocation API was standardized, allowing browsers (which translates to IP-addressed computer terminals) to reveal their location on an per-request opt-in basis.
The service is part of the navigator object and accessible via javascript as:
navigator.geolocation
getcurrentposition takes two functions, the first is called to pass along positional information in form of one parameter, and the second is called when an error occurs
navigator.geolocation.getCurrentPosition(fnPos, fnErr)
As such entering the following command on your Javascript-console will initiate geotracking in the browser, with a navigation-bar request turning up:
navigator.geolocation.getCurrentPosition(console.log, console.error)
The passed object for instance called 'pos' has the properties
pos.timestamp
pos.cords.longitude
pos.cord.latidude
Proxy-Painting
The interesting idea is that in principle these ip2location tables can be used in reverse by routing dummy-requests to proxies based on a given location. One could then write all sorts of stuff (Pacman comes to mind) , onto these maps, provided the provided spatial resolution of the service is high enough. A sufficiently populated area which has enough proxies present could be re-purposed into a canvas. Since so far I couldn't find anything similar I would call it a proof of principle.The high enough resolution limits the kind of services somewhat to http://phpweby.com/service/visitormap/
, except that it does not offer heatmap-coloration, thus rendering the service useless for this purpose.
There are a few requirements though:
- mediocre site traffic (i.e. not amazon)
- a homogenously IP-address-populated area
- sufficient number of proxies (/zombies?)
- low resolution graphics on the order of 10x10pixels (depending on the visitor-location-map service)
- coloration of 'visitor-pins' on the map based on a heatmap or other metric which is accessible for manipulation
#constants
There are a few points to determine first:
- target: a site with mediocre site-traffic
- offset: an initial well populated location (lat/long) - as so often Las Vegas might be a
goodstart - graphic: a low-res icon or word(s)
- ip2location: a lookup table providing fast translation of a location to an IP-address
- proxy-list: a comprehensive up-to-date list of computer terminals which can be used as proxies
- proxip2location: the resulting list when filtering the ip2location list by the proxy-list
- granularity: the longitude-step and latitude-step which can be found by the following method
The proxyip2location table is translated (from spherical coordinates) into cartesian x (column = longitude), y (rows = latitude) and read into a matrix, thus spanning a world-map.
Now simple image based algorithms can be used, like a 3x3 kernel filter or a 3x3 raster for seeking the greatest density and greatest homogeneity (from a given raster).
The greatest density for instance could be computed by simply seeking for the greatest standard deviation from a 3x3 raster
The greatest homogeneity is the exact opposite, with the least standard deviation from a 3x3 raster
If there too many points in a given raster the raster-size has to be adapted, and additionally each point can be 'probed'. By removing each point and recomputing the homogeneity the point can be probed whether it contributes positively or negatively to the homogeneity within the raster.
Raster positioning is another crucial point, with many ideas to choose from, greatly affecting speed and accuracy.
Taken as a whole, this method allows very easily assigning a middle-ground that fits the actual parameters of the actual location distribution of computer-end-terminals. After all life is about compromise, and so is Pacman. An end result that can be interpreted as a Pacman-on world-tour (through an artistic-lens) is a good start.
#implementation
A 10x10 black and white graphics is read into a matrix and multiplied by the canvas matrix of suitable latidue and longitude points.
Each row is processed by a unique thread. Each element within the thread and thus within each row is translated into an IP address and routed to proxy on the other side. (An additional optimization would be to flag proxies which perform a request at the target even with a HTTP-header set to Keep-Alive: timeout=100, max100 whilst subsequently terminating the connection)
After each thread has looped a given number e.g. 1000, each thread is cancelled. Once all jobs are finished worker process initiation starts again in order to maintain syncrhonicity (for the sake of uniformly colored heatmap-pins on a given worldmap).