[postgis-users] optimazing intersection

[toni hernández]

hi,
I am really sorry about the mail answering problem. :-((

The thing is that I have lots of multilinestring in the database.
I have to intersect all of these multilinestrings with other linestrings 
that are not in the database but are created on-the-air. So they are in 
the memory.
To be more precesice I have to intersect every multilinestring in the 
database with every linestring created on-the-air.

The result of the intersection raises a multipoint geometry. The problem 
is that for every point in the multipoint geometry I need to know the 
multilinestring (in the database) and the linestring (on-the-air) that 
produce that point when intersecting.

I know its confusing....



Markus Schaber wrote:
> Hi, Toni,
>
> First, please don't reply to an existing message when creating a new
> topic. Your mail program still generates the In-Reply-To: header, and
> the mail programs of the readers will sort it just into the middle of
> the original message (so-called "threaded view"). This will both annoy
> the list members (which you expect to help you, right), and increase the
> likelyhood that your message gets lost or ignored because those people
> that can help you don't read the original discussion because they're not
> interested in that topic.
>
> toni hernández wrote:
>
>   
>> I have to intersect lots of Multilinestrings so the process is very time
>> consuming.
>> I thought that maybe with a tranlation (translate(geom, -400000,-600000)
>> of the geometries (to get smaller numbers) it would increase speed but
>> the truth is that the difference is not relevant.
>>     
>
> I'd expect that, as translating the geometry does not changei its
> complexity (number of vertices etc.)
>
>   
>> Do you have any other suggestions to increase the intersection efficiency?
>>     
>
> You did not tell us what exactly you want to do.
>
> Do you have to intersect them pair-wise, or all together (to get the
> common piece for all of them)?
>
> In the latter case, you could sort them by number of vertices, and begin
> with the smallest ones.
>
> In the former case, maybe a bbox-overlap check could sort out those
> pairs that don't even come close.
>
> If you need more specific help, please give us more details.
>
> HTH,
> Markus
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>