Hello, Giovanni.
 
This is an interesting point. I think Oracle Spatial's 3D rectangles are beyond 
the scope of gvSIG's geometry model. gvSIG deals with 3D polygons in the sense 
that each vertex has a Z value, but this geometry:
 
SDO_GEOMETRY(3003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 3), 
SDO_ORDINATE_ARRAY(0,0,0,1,1,1))
 
is a cube with eight vertices. If we read it into gvSIG as a square, which Z 
must be set for each vertex?
 
The Oracle Spatial driver knows that rectangles can be created in Oracle 
Spatial in a special way and it should work for 2D rectangles, and also for 3D 
polygons with 4 vertices, but not with those special 3D rectangles (cuboids).
 
Honestly, I didnt know it was possible to create those cubes in Oracle Spatial, 
so I thought it was not necessary to manage that case.
 
What should we do with those cubes that -in my opinion- cannot be represented 
properly in gvSIG 1.9?
 
Regards,
 
Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)
Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
http://www.prodevelop.es <http://www.prodevelop.es/> 
---

________________________________

De: [email protected] en nombre de G. Allegri
Enviado el: lun 18/01/2010 16:06
Para: Users and Developers mailing list
Asunto: Re: [Gvsig_english] oracle spatial wrong interpretation ofrectangles 
(at least 3d)



Five minutes for my coffe break...
---
I see that OracleSpatialUtils.getFMapGeometryMultipolygon(...) checks
if the data is Circle, otherwise it treats them as regular polygons.
Maybe an "isRectangle" management would solve the issue...
---
Back to work.

giovanni

2010/1/18 G. Allegri <[email protected]>:
> I think there's a bug in the interpretation of 3d rectangles in oracle
> spatial (3d polygons with interpretion code 3). I haven't the time in
> this moment to debug it, but I see that getFMapGeometry returns a
> multipolygon with the wrong set of coordinates, causing the geometry
> to be meaningless (a big triangle going to infinity).
> I don't know if it happens on 2d rectangles too (I suppose yes),
> because in this moment I don't have 2d metadata tables on the
> production db to test.
>
> giovanni
>
_______________________________________________
Gvsig_internacional mailing list
[email protected]
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


<<winmail.dat>>

_______________________________________________
Gvsig_internacional mailing list
[email protected]
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional

Reply via email to