[Gdal-dev] Breaking long lines/boundaries with OGR function?

[Markus Neteler]

On Mon, Jun 26, 2006 at 11:53:14AM +0300, Ari Jolma wrote:
> On Mon, 26 Jun 2006 10:16:06 +0200 Markus Neteler <neteler at itc.it> wrote:
> 
> > Ari,
> > 
> > of course the pure import is fast, but the reconstruction
> > of topology takes time. Our idea is to deliver the data
> > in a way more suitable to fast topology reconstruction.
> > It's all about topology - I guess that your renderer
> > doesn't built it.
> 
> No, I suspected something like this. Then the bottleneck is in the usage of the
> topology code, which is GEOS in the case of OGR, I believe. Topological
> operations on complicated geometries are more or less inherently slow.

No - GEOS isn't used here. To again better explain: The chain is
(SHAPE example):

SHAPE -> 
  OGR -> OGR_G_GetGeometryRef(), OGR_G_GetPointCount() etc ->
    GRASS level1 (non-top.) -> Vect_build() -> GRASS level2 (topological)

Vect_build() is sometimes slow as indicated below.

> In v.in.ogr you have more or direct access to OGR data and you can easily split
> the data into smaller pieces for your own use.

Right, this was my question.

> Since this splitting is an
> optimization which depends on the need and there is no "logical" way for doing
> it generally, I don't think there is a suitable existing function in OGR for
> doing it. At least I can't think of anything now. Of course I maybe wrong and
> Frank points out something that I can't think now ;)

Maybe there is a function to break lines with given threshold?
Not sure what to look for exactly.

Markus
 
> Ari
> 
> > 
> > Hope this clarifies the idea (I'm no topology expert...),
> > 
> >  Markus
> > 
> > 
> > On Mon, Jun 26, 2006 at 10:53:24AM +0300, Ari Jolma wrote:
> > > Markus,
> > > 
> > > I'm not sure why the import should be effected by the spatial extents
> > etc. In my
> > > code I "import" data from OGR each time I render it and there's no
> > big overhead
> > > because of that. The code is also extremely simple. What would you
> > consider
> > > "complicated"? I've for example looked at ghssh coastline data and
> > they render
> > > reasonably fast.
> > > 
> > > Of course I don't know much about the way GRASS stored vector data or
> > about the
> > > import tool :-)
> > > 
> > > Ari
> > > 
> > > On Mon, 26 Jun 2006 09:11:35 +0200 Markus Neteler <neteler at itc.it> 
> > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > the following issue came up in GRASS:
> > > > v.in.ogr, the OGR based import tool, may take a long time if
> > > > the data contains long complicated polylines.
> > > > 
> > > > >From TODO
> > > > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO
> > > > > ============================
> > > > > v.in.ogr
> > > > > --------
> > > > > It would be useful to split long boundaries to smaller
> > > > > pieces. Otherwise cleaning process can become very slow because
> > > > > bounding box of long boundaries can overlap large part of the map
> > > > (for
> > > > > example outline around all areas) and cleaning process is
> > checking
> > > > > intersection with all boundaries falling in the bounding box.
> > > > > ============================
> > > > 
> > > > Since I don't know OGR well enough, is there any function 
> > > > we could make use of to achieve splitting of long lines before
> > > > handing data over to (topological) GRASS?
> > > > 
> > > > I found 
> > > > http://ogr.maptools.org/drv_dgn.html
> > > > "Polygons and line strings with too many vertices will be split
> > into
> > > >  a group of elmements prefixed with a Complex Shape Header or
> > Complex
> > > >  Chain Header element as appropriate."
> > > > 
> > > > Something seems to be there (or nearby).
> > > > 
> > > > thanks for a hint
> > > > 
> > > >  Markus
> > > > _______________________________________________
> > > > Gdal-dev mailing list
> > > > Gdal-dev at lists.maptools.org
> > > > http://lists.maptools.org/mailman/listinfo/gdal-dev
> > > > 
> > > 
> > > -- 
> > > Prof. Ari Jolma
> > > Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
> > > Teknillinen Korkeakoulu / Helsinki University of Technology
> > > POBox 1200, 02015 TKK, Finland
> > > Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
> > 
> > -- 
> > Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
> > ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
> > MPBA - Predictive Models for Biol. & Environ. Data Analysis
> > Via Sommarive, 18        -       38050 Povo (Trento), Italy
> > 
> 
> -- 
> Prof. Ari Jolma
> Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
> Teknillinen Korkeakoulu / Helsinki University of Technology
> POBox 1200, 02015 TKK, Finland
> Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
> 

-- 
Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy