Hi,
Thanks for the support so far.
I've cleaned up the modifications and removed all modifications to
JTS. It appeared they weren't really necessary.
I've added Hints to PostGISDialect.java to be able to switch between
2D and 3D. This could look something like this:
int dims = 2; // default
if (gatt.getUserData().get(Hints.FEATURE_2D) != null) {
dims = 2;
}
else if(gatt.getUserData().get(Hints.COORDINATE_DIMENSION) != null) {
dims = ((Number)
gatt.getUserData().get(Hints.COORDINATE_DIMENSION)).intValue();
}
---> Question: Were to set those hints so it will be picked up by
PostGISDialect.
GML 3.1 seems to work ok now. GML 3.2 gives some problems because the
LocationPropertyType.getProperty in GetPropertyExecuter
never seems to return a child:
child = complex.getProperty(parent, name);
parent = Point
name = AbstractGeometry, LocationString, ... (not sure which one
should fit here)
Any idea on this?
Thanks,
Sjoerd
On Thu, Jan 20, 2011 at 3:13 PM, Jody Garnett <jody.garn...@gmail.com> wrote:
>
>>> - added getCoordDimensions function to geometry and implementors
>>> - modified WKTWriter to be able to write 3d data
>>
>> Are those both strictly necessary? Patching JTS is problematic, we
>> only used stock
>> releases so far.
>> It would be nicer, imho, to keep the knowledge that a certain geometry is 3d
>> as part of the GeometryDescriptor, possibly as an entry in that class
>> metadata
>> map.
>
> Going to echo Andrea here; you will find we have extended WKTReader already
> in GeoTools (in order to parse WKT Curves); if you could take the same
> approach for WKTWriter it would be helpful.
>
> Not sure about getCoordinateDimensions? You will find CoordianteSequence
> already has some of that handled (in order to allow for x,y,z,m data from
> oracle).
>
> Jody
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
