Added pjs-load to try to make it work in ProcessingJS
initial commit of gps_stippen_locatie
created function drawEllipses() where I put ellipse drawing logic

tidied a bit main loop, by putting drawing logic into separate function
added comments about latitude and longitude

and samples of data to be able to understand what's happening there
abstracted drawEllipses only to operate graphical terms

The previous version of drawEllipses(PVector p, int row) was dependent
on the "row number" and the table data structure. In this version
drawEllipses() is abstracted to only operate "graphical" concepts, like:
drawEllipses(PVector p, float alpha, float diameter); This method now
doesn't know anything about data. And thus is decoupled from the data
definition.
added getLongitude() getLatitude() convenience methods

Added to the Table class extra convenience methods, so that it is more
clear to read locationTable.getLongitude(row) than before was
locationTable.getFloat(row, 0) .
avoid polluting memory with unneeded PVector each loop

created methos geoToPixel(float, float) in addition to
geoToPixel(PVector) in order to be able to avoid need to create new
PVector object 16 920 times per second ( 60 frames per second, and 262
times PVector is created when 262 rows are looped through)
changed names of vars to better depict what they really are

float x kinda assumes that we talk about screen coordiates, however what
we get here is actually longitude. So better to name it accordingly. I
still use "_x" in the end, so that it's harder confuse lat and lon
adds precalculation of screen coordinates

So that screen coodinates don't have to be recalculates 16000 times per
second, I have calculated them once during table load stage. They will
be saved in array of PVector's "mScreenCoords[]". Also adjusted
drawEllipses() to be able to be called with floats as parameters (rather
than PVector)
moves geoToPixel() inside of the Table class

because calculation of screen location of the geo-coordinates is now
happening when class Table is loaded, it is better to seal this method
inside of the Table class. Logically it belongs there. But to do that we
need to pass "mapScreenWidth" and "mapScreenHeight" variables to Table
class, as they are used to do geoToPixel() conversion. Alltogether this
reduces cohesion of the elements of the sketch and gives clearer code.
We still have mapGeoXXXX variables to get rid of.
fixes the ProcessingJS bug and tidies up some comments.

the problem was that when running in ProcessingJS instead of
getFloat(int, int) was called getFloat(String, int) and same thing
happened with getString(). So intead of getString(int, int) PJS would
call getString(String, int). This is why in PJS program would run
completely different pieces of code.
The solution is to renate getFloat(String, int) to
getFloatByName(String, int) and to rename getString(String, int) to
getStringByName(String,int);