ThinkGeo.com    |     Documentation    |     Premium Support

Oracle Spatial not fully working

#23

Rui, 
  
   You should have the source by now.  Using the event you can do what you need above. 
  
 David

#24

David,  
 i haven’t received the source yet

#25

Rui, 
  
   We sent it to the gmail address you had on file with us.  If you want us to use a different address send it to us at forumsupport@thinkgeo.com 
  
 David

#26

sent an e-mail from the address where i’m able to receive the source, and from which i sent the nda. 
 thank

#27

Rui, 
  
   I send the e-mail but I don’t think you are getting it.  I went ahead and attached the zip file to the ticket.  Sorry for all the delays but we send the stuff last week and didn’t know you did not get it. 
  
 David

#28

Got it!

#29

Rui, 
  
   Excellent, let us know if there is anything we can help you with.  We are still in queue to get the other geometries added to support the non simple feature specification. 
  
 David

#30

Yes, and improve performance.  
 the Oracle’s get_wkb() sometimes is very slow. 
  
 Should not rely on this for two main reasons: 
 1. get_wkb() does not support every geometries 
 2. transforming to WKB is very slow. 
  


#31

Rui, 
  
   So if you do not use get_wkb then what do you use and what will it return?  I assume it must be binary, but what format? 
  
 David

#32

It's not binary format. 



you have a SDO_GEOMETRY that can be parsed.  

Here is a nice documentation on the SDO_GEOMETRY format.  

download.oracle.com/docs/cd/B12037_01/appdev.101/b10826/sdo_objrelschema.htm 



But at the end in performance matter you would have the same result, unless you do the parsing in PL/SQL. You could create a installable Oracle Package with function you could call. This is the approach we are going. 



You could also use SDO_UTIL.REMOVE_DUPLICATE_VERTICES and define the tolerance depending on scale and on a layer property (not all layers should go throw it) 



I had nice results with SDO_UTIL.REMOVE_DUPLICATE_VERTICES. since if you are at a big scale 1:100000 you will need very small detail, and when you star to zoom in, you start to reduce the tolerance (and even remove the call).


When you zoom in the number of points passed by oracle to get_wkb() is small and it will do the transformation fast, because you already applied the spatial filtering.



Intergraph's Geomedia is not doing the get_wkb() and they have a much better performance.



#33

Rui, 
  
   I would image that if it returns text that it has to be slower then returning binary.  Binary should be faster and much more contact.  We will do and test and see.  Any more suggestions or comments are welcome, we can easily support the SDO_Geometry I just thought it would be slower. 
  
 David

#34

The query to Oracle will be much faster for sure. 
  
 select alias.shape from table alias  
 is much faster than 
 select alias.shape.get_wkb() from table alias 
  
 try testing with polygon layer with a lot of points and you’ll see.

#35

Rui, 
  
   We are going to look into that.  The WKT is easier to read and parse also!  Did you end up making some code modifications? 
  
 David

#36

Hello David, yes we managed to fix the problem of not being able to see all geometries. 
 We are still having problems with performance.  
  
 For fixing the problems with the geomtries we implemented a oracle package with a function called clean_geometry wich will clean the Arcs. 
 Then we changed the query for something like : 
  
 string sqlStatement = string.Format(CultureInfo.InvariantCulture, “select OracleGeometryPackage.clean_geometry(’{1}’,’{0}’, {2}.{0}).GET_WKB() from {1} {2} WHERE ROWNUM <= 1”, geometryFieldName, userId + “.” + tableName, tableAliasName); 
  


#37

Rui, 
  
   Another option is for us to support those shapes or do it ourselves on the client side.  It may be faster than on the server since it is a shared resource.  Since we can actually use the text it will be much easier.  I will see if I can get someone on that.  It has been busy here so not many spare resources. 
  
 David

#38

David, Oracle’s get_wkb() is very bad. 
  
 I have here some municipality layer with just 10 to 20 features, each one with maybe 30thousand points, and it takes 10 seconds to do the select alias.shape.get_wkb() from tabl alias…  
 Is just verrrryyyy slow! 
  
 Have you guys tryied the FDO provider (King something)? Did you found anything that make you guys to not follow that approach? 


#39

David, found something new on this matter. 
  
 From Oracle Documentation: 
   
 “The function, SDO_GEOM.RELATE, does not use the 
 spatial index and simply evaluates the two geometries  that are passed to it via the” 
  
 In Google look for: “oracle spatial sdo_geom.relate indexes” 
  
 I’m changing the provider to: 
 WHERE  SDO_RELATE(SHAPE, MDSYS.SDO_GEOMETRY(2003, 3062, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(613650.260871111, 4176933.67650982, 618182.430405949, 4179341.39157518)), ‘MASK=ANYINTERACT’) = ‘TRUE’ 
  
 wich takes advantage from the spatial index.

#40

David please consider the following code. 
 I’ve got major improvement in big datasets.  
  
  if (queryType == queryInside) 
             { 
              // OLD //  condition += "’ AND " + “SDO_GEOM.RELATE(” + geometryFieldName + “,‘ANYINTERACT’,” + sdoGeometry + “,0.005)=‘TRUE’”; 
                 condition += "’ AND " + “SDO_RELATE(” + geometryFieldName + “,” + sdoGeometry + “,‘MASK=ANYINTERACT’)=‘TRUE’”; 
             } 
  
 I also would thank you if you keep me updated on new changes to the Oracle feature source.

#41

One other thing. 
 Why is   “USER_SDO_GEOM_METADATA tableMetaData” needed? Couldn’t figure this out. 
  
 I end with this in the bounding box, but maybe i’m not seeing something: 
  
 SELECT tableName.SHAPE.GET_WKB() as SHAPE,  
        ID  
   FROM SIGOWNER.TABLEA tableName 
  WHERE SDO_RELATE(SHAPE, MDSYS.SDO_GEOMETRY(2003, 3062, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY(615456.524039878, 4178371.25979973, 616589.566423582, 4178973.18856607)), ‘MASK=ANYINTERACT’) = ‘TRUE’ 
  


#42

Any update?