2 Replies Latest reply on Sep 11, 2013 10:51 PM by gdildine

    geometry server performance


      I am testing an application using the geometry server available in the latest version of MapViewer.  I am confused as how to effectively use the loadOnDemand parameter for a "predefined" vector theme.

      I am testing on a layer of 75000 intersection points.  I assume that with loadOnDemand set to true, that a spatial filter is applied in order that only those feature within the current map window will be retrieved.  In practice however, the entire 75k of features is queried by the mapviewer server, even when the map window should only be showing a half dozen intersection points.


      The relevant javascript code is presented here:


      vectorlayer2 = new OM.layer.VectorLayer("vectorLayer2",
                      url: baseURL,
              vectorlayer2.setZoomLevelRange(17, 19);
              // add a vectorlayer. conversion from srid 90000006 to 4055 will occur on the server
              map.addLayer(tileLayer1) ;  // google tiles
              map.addLayer(tileLayer2) ;// mapviewer tiles
              map.addLayer(vectorlayer2) ; // mapviewer vectors
              map.addLayer(vectorlayer1) ; // mapviewer vectors
              //var z1 = tileLayer1.getZIndex();
              //var z2 = tileLayer2.getZIndex();       
              map.setMapCenter(new OM.geometry.Point(-104.81539,41.163299,8307) );



      The relevant MapViewer log info  is here


      INFO: [ IXN_INTERSECTIONS ] sql exec time: 222ms, total time loading 23665 features: 33998ms.
      Sep 10, 2013 6:22:05 AM oracle.sdovis.theme.PredGeomThemeProducer loadFeaturesInAdjustedMBR
      INFO: [ IXN_INSXN_LEGS ] sql exec time: 135ms, total time loading 76438 features: 104276ms.


      If this is not correct, could you please provide some guidance on how to retrieve only the geometry within the current map window?  The approach above follows the example in tutorial D22.  Thank you for your assisstance

        • 1. Re: geometry server performance

          Yes loadOnDemand is supposed to fetch only the area that are currently visible (plus some padding around it, which is actually double the width and height of the current map viewing window). Still this should not lead to that many points at zoom level 17.


          Can you please post more log messages around those that you posted?  You will need to set the log level to 'finest', then there should be some additional logs like below:


          oracle.sdovis.theme.PredGeomThemeProducer loadFeaturesInAdjustedMBR

          FINEST: [ THEME_DEMO_CITIES ]:  -107.45247148288973,31.825095057034215,-100.60836501901142,38.669201520912544


          the above will tell us the actual query window that is being used, and we can go from there.




          1 person found this helpful
          • 2. Re: geometry server performance


                 My problem apparently was tied to the projection I utilized.   In preparing to use google maps with mapviewer, I reprojected my data from a custom 'Albers' projection to SRID 4055.   I did this based upon the direction from the Oracle Spatial documentation (reference: 6.12 Google Maps Considerations) in dealing with moving from ellipsoidal coordinates to spherical coordinates being used in Google Maps.   I assumed that it was working correctly because the data was being put in the correct position.  Upon closer inspection (using Firebug), I realized that the coordinates being sent for the bounding window were in a different coordinate system than the source data.   I decided to re-project the coordinates from the source table from SRID 4055 to SRID 3857.  This corrected the problem as the bounding window and the vector geometry layer became in sync (from a projection standpoint).


            As a side note, the code actually work correctly the entire time.  The reason that all of the intersections were returned was that the bounding box of the spherical Mercator project map window by far exceeded the mbr of the intersection layer (in lat/long).


            Finally, it might be worth modifying the documentation in Oracle Spatial to make sure that the ending coordinate system is SRID 3857, and not 4055 (as is currently stated).


            Issue solved.  Thank you so much for your assistance.