Quoting Christoph Spoerri <spoerri@duke.edu>:

> Dave,
> 
> I downloaded the (hourly) cvs tar.gz file from your website and checked the
> lwgeom.h file. I have couple questions:
> 
> - should we have a 2d point with a M value (x,y,m) ? Or would this complicate
> things only?

I think this would complicate things - wasting 8 bytes/point shouldnt be too 
bad for folks using (x,y,z,m) points instead of (x,y,m) points.  Its probably 
possible to add in (x,y,m) support, but I'm not going to do it right away.
 
> - how would one determine if a point has a M value? Could we use one of the x
> in the LWGEOM types (xxSDtttt)?

I was going to change it to xDDStttt.  There's already defs in lwgeom.h for 
(x,y,z,m) points (FOURDIMS).  I havent changed lwgeom.h yet - but if you look 
in lwgeom_inout.c (currently WKB reader and writer), you'll see it fully 
supports them.
 
> - the old geometry type are still valid, correct? If so, are they only a
> wrapper for the new type or does the code need to differentiat between the
> two types?

I think lwgeom will superseed the current geometry; but I'm not sure when this 
will happen.  What will probably happen, short term, is we'll have a both type 
(lwgeom and geometry).  This will allow postgis geometry functions to be run 
on lwgeom object.  Once all the postgis geometry functions have been 
implemented in lwgeom, we'll be able to retire it.

> btw. does the lwgeom code already compile and work?

It compiles (good luck running the Makefile for it!), but it isnt tested.  I 
wrote about 2,200 lines of code in about 6 hours so I imagine theres a bunch 
of bugs in it!
I just finished the WKB parser/writer, so I should be able to test it 
relatively soon.

dave


