Hi,

If your LineString has many points, I would split it into segments and 
index segments with
a STRtree.
In your scenario 1 and 2, the computer will have to compare each point 
with all
line segments (or all buffer segments). Hard to say which one is faster 
without a try.

If you index the linestring segments with a STRtree (the most efficient 
spatial index of JTS),
you can compare points with segments which envelope are already within 
the distance. I
think you can save time. Did not try though, it would also worth a try.

Michaël


Le 26/08/2013 20:29, Stefan Steiniger a écrit :
> mhm..
> well, you could run a test...
>
> And avoiding 4 million tests does not seem to be possible.
>
> And not sure if this helps, you, but
> - buffering is a fairly costly operation (and you should define also the
> number of points for a quarter circle segment, e.g. the result for
> buffering a point)
> - if you have a fairly simple polygon describing the area limits (or is
> it all linestrings? ... I also did not completely understand what you
> LineString is), then a point-in-polygon test can be very fast
>
> but Martin D. my correct me here.
>
> - there is also the option to do some classification/trajectory
> estimation based on previous data for one car (Kalman-filtering) to see
> if you need to do some testing (maybe you car did not move at all... so
> the location-difference has not changed). But I guess the processing of
> 4 million units is simpler/faster?
>
> - finally splitting your data/fleet to contact only a certain server, as
> form of parallel processing is an option too?
>
> stefan
>
> Am 26.08.13 13:56, schrieb André Salvati:
>> Hi Stephan,
>>
>> thanks for your answer.
>>
>> This would be an useful solution for some batch processing that we do.
>>
>> However, I meant that I'm receiving 4 million positions in realtime from
>> these vehicles (6000) every day, so the app must process one-by-one and
>> generates alerts when some of them cross the boundaries. In this case,
>> you would go with 1), 2) or is there another option?
>>
>>
>>
>>
>> 2013/8/26 Stefan Steiniger <[email protected] <mailto:[email protected]>>
>>
>>      Hi Andre,
>>
>>      if possible, you should use a spatial index, to do some pre-filtering.
>>      JTS comes with a Quadtree and R-Tree (STRtree) implemetation. One is
>>      updatable while the other not (not sure though, which one).
>>      A spatial index allows you to retrieve only those objects from a
>>      dataset, that are fairly close/near by.
>>
>>      Do you have objects that do not move around?, What are your 4 Million
>>      objects?
>>
>>      Also could you not buffer your objects only once and then store them?
>>
>>      best,
>>      stefan
>>
>>      Am 26.08.13 13:21, schrieb André Salvati:
>>       > Hi,
>>       >
>>       > I'm a beginner with JTS and this is my first post here.
>>       >
>>       > We've been working with geofences for a vehicle tracking app and
>>      I would
>>       > like to know what solution could give me a lower CPU consumption.
>>       >
>>       > 1) Calculate and store a Buffered Area (100 meters) from a LineString
>>       > object. Run 4 million times if my vehicle positions are inside or not
>>       > that precalculated with contains() method.
>>       >
>>       > 2) Run 4 million times isWithinDistance() method from LineString for
>>       > each position.
>>       >
>>       > Are there another options?
>>       >
>>       > Thanks.
>>       >
>>       >
>>       >
>>      
>> ------------------------------------------------------------------------------
>>       > Introducing Performance Central, a new site from SourceForge and
>>       > AppDynamics. Performance Central is your source for news, insights,
>>       > analysis and resources for efficient Application Performance
>>      Management.
>>       > Visit us today!
>>       >
>>      
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>       >
>>       >
>>       >
>>       > _______________________________________________
>>       > Jts-topo-suite-user mailing list
>>       > [email protected]
>>      <mailto:[email protected]>
>>       > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>       >
>>
>>      
>> ------------------------------------------------------------------------------
>>      Introducing Performance Central, a new site from SourceForge and
>>      AppDynamics. Performance Central is your source for news, insights,
>>      analysis and resources for efficient Application Performance Management.
>>      Visit us today!
>>      
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>      _______________________________________________
>>      Jts-topo-suite-user mailing list
>>      [email protected]
>>      <mailto:[email protected]>
>>      https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>
>>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user


------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user

Reply via email to