I would personally go with features over markers. Point features (and all features) allow for labeling and can be represented in different shapes and colors like circles, x, square and so forth. Not to mention all the additional intrinsic functionality and flexibility features have over markers such as geographical calculations, transformations, click/highlight/select handlers and on and on.
I hate to be pushy, but it would be beneficial if you used something like GeoServer or MapServer on the back end. You could set a WFS strategy that works on your 5-30 second (or whatever) interval timer and allow it to fetch and render the features automatically. In case you're wondering, it already does this in ajax form. So you don't have to write the code to query the database, parse, convert, etc... on 300 objects on your map. Openlayers will render the latest WFS data on your Geoserver which is pointed to PostGIS. You would save yourself a lot of time and effort reinventing that wheel. Openlayers WFS protocol can be set to query based on your viewport on a temporal filter.
Though features don't perform well when there are a lot of them. 300 might be pushing it. If you see that performance is an issue, you can easily switch to using WMS (only if you have Geoserver or Mapserver). You can also use a cluster strategy to minimize un necessary features on your map.
SELECT ST_Astext(geom) FROM "locations" WHERE ST_Contains( ST_Buffer( St_GeomFromText( 'LINESTRING( 6 52, 6.5 53, 7 54 )', 4326 ), 10000 ), geom )
- ST_Buffer(
geom, radius ) creates a 10km buffer. Im using a linestring as
example. Second argument is in meters when using SRID 4326. Calculations are in the Spatial Reference System of this Geometry.
- ST_Contains(
geomA, geomB ) Returns true if and only if no points of B lie in
the exterior of A, and at least one point of the interior of B lies
in the interior of A.
Don't hesitate to ask me if you need more help!
edit:
SRID 4326 is NOT measuring in meters (see here).
Besides that, it's better (faster) to use ST_DWithin. There is a note in the ST_Buffer documentation:
People often make the mistake of using this function to try to do
radius searches. Creating a buffer to to a radius search is slow and
pointless. Use ST_DWithin instead.
If you would like to measure in meters its better to use geography instead of geometry:
SELECT ST_Astext(geom) FROM "locations" WHERE ST_DWithin( ST_GeographyFromText( 'LINESTRING(48.85523 2.36179,48.85556 2.36205,48.85591 2.36226,48.857 2.36288,48.85806 2.36362,48.85834 2.36382,48.85818 2.36434,48.85817 2.36444,48.85817 2.36448,48.85882 2.3645,48.86 2.36454,48.86144 2.3646,48.86178 2.3646,48.86184 2.36458,48.86187 2.36455,48.86193 2.36446,48.86199 2.36455,48.86205 2.3646,48.8621 2.36464,48.86277 2.36466,48.86367 2.36469,48.86459 2.36583,48.8647 2.36577)' ), geom::geography, 10000 );
It transforms the points to geographic points and the input is a geographic linestring. ST_GeographyFromText() description:
Returns a geography object from the well-known text representation.
SRID 4326 is assumed.
Good luck!
edit2:
If you want to extract the polygon with the buffer area u can use this query:
SELECT ST_Astext(geom) as "point", ST_AsText( ST_Buffer( "linestring", 10000 ) ) as "buffer" FROM "locations", ST_GeographyFromText( 'LINESTRING(48.85523
2.36179,48.85556 2.36205,48.85591 2.36226,48.857 2.36288,48.85806 2.36362,48.85834 2.36382,48.85818 2.36434,48.85817 2.36444,48.85817 2.36448,48.85882 2.3645,48.86 2.36454,48.86144 2.3646,48.86178 2.3646,48.86184 2.36458,48.86187 2.36455,48.86193 2.36446,48.86199 2.36455,48.86205 2.3646,48.8621 2.36464,48.86277 2.36466,48.86367 2.36469,48.86459 2.36583,48.8647 2.36577)' ) as "linestring" WHERE ST_DWithin("linestring", geom::geography, 10000 );
Best Answer
Since you say your markers are stored in a postgresql database, this material will be very useful for you: TSP with pgRouting