[postgis-devel] Re: LW_GEOM questions

David Blasby dblasby at refractions.net
Wed Apr 14 10:11:48 PDT 2004

Ralph Mason wrote:
> Hi David,
> I have a reasonable amount of the WKT parser done and have a couple 
> questions.
> 1. In your powerpoint slide you show a MULTIPOINT to have the ability to 
> have each point with different SRID and a type byte - this doesn't make 
> much sense to me, there is no way to specify a srid for each point in a 
> multipoint.  I think a multipoint would be 
> <type>[<srid>]<numpoints><numpoints points>
> 2. If there is a GEOMETRYCOLLECTION is the parser to allow an attachment 
> of a SRID to each geometry in the collection?  The current one does but 
> seems to throw them away - if so what is the scope of the SRID eg  
> GEOMETRYCOLLECTION(SIRD=2;POINT(1 1,2 2), POINT(3 3,4 4)) what is the 
> srid of the second point 2 or -1? 
> 3. Assuming the above is -1  for the second point in the case of  
> SRID=1;GEOMETRYCOLLECTION(SIRD=2;POINT(1 1,2 2), POINT(3 3,4 4))  the 
> second point would have a SIRD of 1, would you expect that the parser 
> tag it as such in the structure (eg the point has a SIRD member and flag)?
> 4. If there is to be multiple SRID support in a geometry what is the 
> canonical form of that?
> Maybe some of these should go to the group.


Each geometry should have either 0 or 1 SRID (0 means the SRID=-1). 
This SRID should be connected to the "root" geometry - the 
sub-geometries shouldnt have an SRID attached to them.  The ppt 
presentation does say that you could put an SRID in any of the sub-types 
- you should read that as "its logically possible to have an SRID here, 
but YOU SHOULD NEVER DO IT".  The reason its logically allowed is 
because each sub-component of a MULTI* is actually a LWGEOM in 
serialized form.

1.  <type>[<srid>]<numpoints><numpoints points>
    All the MULTI* (and geometry collection) types are all defined 
exactly the same way - I dont want to have a special case for MULTIPOINTS.
    You would only attach the SRID to the MULTIPOINT - not to each 
individual point inside.

its components.


4. SRID's of sub-components should be removed, so the cannonical form 
will be "SRID=#;<WKB>"


ps.  I have indexing working right now.  I'm finding that it takes about 
400ms to do 1000 sub-queries using LWGEOM, and the standard postgis 
geometries only takes 100ms.  Thats about 0.3ms per index-search slower. 
  I think this is being causes because the bounding box of the search 
lwgeom geometry has to be calculated (but its already avaiable in the 
postgis geometry).

Both index size and table size is significantly smaller in the LWGEOM.

More information about the postgis-devel mailing list