Not so spherical mercator? SRID 3857?

Hi folks,
Spent some time yesterday getting schooled on all the politics of last year's EPSG 3785 to 3857 swap. I guess they just don't like that sphere (or rather the math). I was wondering first off if anyone had the 11gR2 CS inserts for 3857. I saw a post that Mike Horhammer was working on doing this last spring. How about the Oracle folks? Will 3857 be showing up soon as a stock SRID? Being WGS84 based it probably not that big a deal to set up but I was just hoping someone else had it handy.
Secondly, any idea how this change will work in practice? The EPSG has not only created the new SRID but they definitively retired the old. There is no mention of 3785 in the EPSG database any longer and ideally this number could be recycled to some other purpose at any time. So what happens now to the old Spherical Mercator cs? Someone over there at Oracle took all the trouble to code the new spherical math routines into SDO_CS for 11gR2. This came to my attention via looking at the situation at ESRI. They seem to be just accepting that there are now two Web Mercator coordinate systems. In the 9.3 product 3785 = 102113 and 3857 = 102100. ArcGIS 10 just uses 3785 and 3857. I am not sure what happens if 3785 get recycled to some other purpose at EPSG. Will Oracle also retain 3785 and just add 3857 and thus have the two Web Mercator coordinate systems? It seems like deleting 3785 could create some problems.
Anyhow, interested in any thoughts or suggestions you all have on the matter.
Cheers,
Paul

Good question Paul...
I'm working on putting together an image catalog for spatial -> WMS -> Google Tiles, and realized I needed to use 3785 to make it work better.
Short term, I guess it doesn't really matter as I doubt it will go away so suddenly in software. But... long term - I'm no sure what to think.
Bryan

Similar Messages

New SRID (3857) in 11.2.0.2 (use instead of 3785)

The new srid epsg:3857 in 11.2.0.2 does not require a tfm_plan or the use case use_spherical to correctly line up with google or bing background maps. The doc wasn't updated in time. See the sample results below.
. First geom. In 8307, 2nd in 3785 with no tfm_plan or use case, 3rd 3785 with use_spherical, 4th 3857.
MVDEMO@sdolnx2>select * from v$version ;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
MVDEMO@sdolnx2> select city, location, sdo_cs.transform(location, 3785) loc3785_oldcs,
sdo_cs.transform(location, 'USE_SPHERICAL', 3785) loc3785_usespherical,
sdo_cs.transform(location, 3857) loc3857_newWebMercator from cities where rownum < 4
CITY
LOCATION(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
LOC3785_OLDCS(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINA
LOC3785_USESPHERICAL(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO
LOC3857_NEWWEBMERCATOR(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, S
New York
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-73.943849, 40.6698, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-8231391.6, 4935892.96, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-8231391.6, 4963758.56, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3857, SDO_POINT_TYPE(-8231391.6, 4963758.56, NULL), NULL, NULL)
Los Angeles
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-118.4112, 34.112101, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-13181475, 4019893.75, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-13181475, 4043864.4, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3857, SDO_POINT_TYPE(-13181475, 4043864.4, NULL), NULL, NULL)
Chicago
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-87.684965, 41.83705, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-9761045.7, 5108079.09, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3785, SDO_POINT_TYPE(-9761045.7, 5136601.49, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 3857, SDO_POINT_TYPE(-9761045.7, 5136601.49, NULL), NULL, NULL)

Hello Fidel,
thansk for the completion - with the name of the hidden parameter i was able to find the blog in my RSS feed reader
http://oraclue.com/2010/10/21/oracle-11-2-0-2-patch-set-new-feature-and-change/
http://oradbastuff.blogspot.com/2010/09/11202-11g-release-2-patch-set-2.html
Regards
Stefan

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",
            def:{
                type:OM.layer.VectorLayer.TYPE_PREDEFINED,
                dataSource:"itis-db3-wy",
                theme:"IXN_INSXN_LEGS",
                url: baseURL,
                loadOnDemand:true
        vectorlayer2.setZoomLevelRange(17, 19);
        // add a vectorlayer. conversion from srid 90000006 to 4055 will occur on the server
        //vectorlayer1.setLabelsVisible(true);
        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.addNavigationPanelBar();
        map.setMapCenter(new OM.geometry.Point(-104.81539,41.163299,8307) );
        map.setMapZoomLevel(17);
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

LJ,
     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.

Gpsdrive - trouble installing

Hi all,
I am attempting to install gpsdrive and when I am inserting the map data, I get this error:
Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
NOTICE: table "planet_osm_point" does not exist, skipping
NOTICE: table "planet_osm_point_tmp" does not exist, skipping
SELECT AddGeometryColumn('planet_osm_point', 'way', 900913, 'POINT', 2 );
failed: ERROR: permission denied for relation spatial_ref_sys
CONTEXT: SQL statement "SELECT SRID FROM spatial_ref_sys WHERE SRID = new_srid"
PL/pgSQL function "addgeometrycolumn" line 74 at SQL statement
SQL statement "SELECT AddGeometryColumn('','',$1,$2,$3,$4,$5)"
PL/pgSQL function "addgeometrycolumn" line 4 at SQL statement
Error occurred, cleaning up
I am running this command:
osm2pgsql -s --database "UnitedStates" --username "gis" --password --multi-geometry "/home/walterjwhite/Downloads/united_states.osm.bz2"
Any ideas what I may be missing? It appears to be a permissions issue.
Walter

ahhh. okay perhaps try uninstalling that prior to the Cubase install.
i was involved in a thread recently where someone was having trouble getting Cubase to work if QT for Windows was installed:
http://discussions.apple.com/click.jspa?searchID=-1&messageID=4225855
... ao it may be worth checking if uninstalling QuickTime helps with getting Cubase installed.
(a bit of a long shot here, granted.)

Scale in MapViewer and MapBuilder

Hello everyone,
short question on scale-definitions in MapBuilder compared to MapViewer:
I'm using google coordinates on a tilelayer to convert some local data to 3785
<coordinate_system srid="3857" minX="-2.0037508E7" minY="-2.0037508E7" maxX="2.0037508E7" maxY="2.0037508E7"/>
<tile_image width="256" height="256"/>
<zoom_levels levels="19" min_scale="262144.0" max_scale="1.0" min_tile_width="76.43702697753906" min_tile_height="2.0037508E7">
<zoom_level level="0" name="" description="" scale="1.0" tile_width="2.0037508E7" tile_height="2.0037508E7"/>
<zoom_level level="1" name="" description="" scale="2.0" tile_width="1.0018754E7" tile_height="1.0018754E7"/>
<zoom_level level="2" name="" description="" scale="4.0" tile_width="5009377.0" tile_height="5009377.0"/>
<zoom_level level="3" name="" description="" scale="8.0" tile_width="2504688.5" tile_height="2504688.5"/>
<zoom_level level="4" name="" description="" scale="16.0" tile_width="1252344.25" tile_height="1252344.25"/>
<zoom_level level="5" name="" description="" scale="32.0" tile_width="626172.125" tile_height="626172.125"/>
<zoom_level level="6" name="" description="" scale="64.0" tile_width="313086.0625" tile_height="313086.0625"/>
<zoom_level level="7" name="" description="" scale="128.0" tile_width="156543.03125" tile_height="156543.03125"/>
<zoom_level level="8" name="" description="" scale="256.0" tile_width="78271.515625" tile_height="78271.515625"/>
<zoom_level level="9" name="" description="" scale="512.0" tile_width="39135.7578125" tile_height="39135.7578125"/>
<zoom_level level="10" name="" description="" scale="1024.0" tile_width="19567.87890625" tile_height="19567.87890625"/>
<zoom_level level="11" name="" description="" scale="2048.0" tile_width="9783.939453125" tile_height="9783.939453125"/>
<zoom_level level="12" name="" description="" scale="4096.0" tile_width="4891.9697265625" tile_height="4891.9697265625"/>
<zoom_level level="13" name="" description="" scale="8192.0" tile_width="2445.98486328125" tile_height="2445.98486328125"/>
<zoom_level level="14" name="" description="" scale="16384.0" tile_width="1222.992431640625" tile_height="1222.992431640625"/>
<zoom_level level="15" name="" description="" scale="32768.0" tile_width="611.4962158203125" tile_height="611.4962158203125"/>
<zoom_level level="16" name="" description="" scale="65536.0" tile_width="305.74810791015625" tile_height="305.74810791015625"/>
<zoom_level level="17" name="" description="" scale="131072.0" tile_width="152.87405395507812" tile_height="152.87405395507812"/>
<zoom_level level="18" name="" description="" scale="262144.0" tile_width="76.43702697753906" tile_height="76.43702697753906"/>
</zoom_levels>
on zoomlevel 18 I'm "closest" to the ground, on 1 I can see the whole world (no data there in my theme but theoretically...) - all fine (except black borders between tiles - other problem).
Now I want to improve image quality by choosing pyramid-levels for the zoom-level and tried to figure out a way to set up basemaps in mapbuilder using ratio.
That's where I noticed, that MapBuilder seems to use a different way of calculating scale in comparison to MapViewer. E.g. in my case scale 262144 is zoom-level 18 in MapViewer, but viewing the picture in MapBuilder I have to chose scale 1024 to get the same picture (which is zoom-level 10 in MapViewer).
Did I get anything wrong about this? Or is there anything I can do to sync the scales in order to make working with mapbuilder and mapviewer combined easier?
Also is there a way to see which pyramid-level of the georaster-file is used to calculate a maptile in MapViewer?
Thanks,
NilsO

Hi NilsO,
first about the pyramid level of GeoRaster used. MapViewer/MapBuilder calculates the closest pyramid level for the current map scale (based on map and device windows). You can find this information in the log when the GeoRaster theme images are being generated (you may need to set the logging to finest).
About the tile layer definition, in XML tile layer definition the values of min_scale and max_scale are interpreted differently from MapViewer base map definition. So I think in your case the min_scale should be 1.0 and the max_scale should be 262144 in XML, and the zoom levels would be in reverse order that you have.
How did you generate this tile layer definition?
The visualization scales in MapBuilder/MapViewer and Oracle maps in general should be consistent, although rendering in MapBuilder does not use the zoom levels of Oracle Maps (can be any scale). Please try changing the tile layer definition as mentioned above, to see if you still get the scale differences.
Joao

Help needed to create Quik Time VR movies, step by step

Hello,
thank you for your attenction.
I need to create Quick time vr movies, and I need to know the exact sequance of steeps to do it, and if the starting point I use is correct.
1) I shooted a sequence of photos with my digital camera (for example: www.stebianchi.com/quicktimevrhelp/still-photo.jpg).
2) Then, with photoshop (CS4) I choose: Automate/photomerge and I select all them to joint them in a bigger 360° panoramic one (www.stebianchi.com/quicktimevrhelp/pan.jpg). If, untill here, all is correct, the first question: in photoshop Photomerge layout option, do I have to choose one voice "auto, perspective, cylindrical, spherical, etc..." rather than anoter one of these?
3) from here, I really need your help.
First of all: the great doubt:
My photos can not cover a spherical panorama, they're only a "ring" around a center (and not a spherical texture). To cover all the surface (or almost all, ok...) of my ambient, do I have to use a wider lens on my camera or there is a different solution (for ex a vertical photomerge?).
4) Done this, I think I shuold buy a software like Cubic converter, to set and export the QTVR movie. Right?
Thanks a lot guys,
all the best!
Stefano

You can call your local apple store(find one on the home page of apple.com) and they will give you instructions how to convert DVD to iPod. That is what they told me, but from what I heard, you may need more than Quicktime Pro. Just call and ask them, because if you make a manual of how to do it, it could help me a lot.
(I'm looking for a good DVD converter, already know some, beside the internet download ones)

GeoRaptor 3.0 for SQL Developer 3.0 and 2.1 has now been released

Folks,
I am pleased to announce that, after 5 months of development and testing, a new release of GeoRaptor for SQL Developer 2.1 and 3.0 is now available.
GeoRaptor for SQL Developer 3 is available via the SQL Developer Update centre. GeoRaptor 3 for SQL Developer 2.1 is being made available
via a download fro the GeoRaptor website.
No release notes have been compiled as the principal developer (oops, that's me!) is currently busy doing real work for a change (another 3 weeks), earning a living
and keeping the wolves at bay. More extensive notes (with images) will be compiled when I get back. (Unless anyone is offering! See next.)
We are still looking for people to:
1. Provide translations of the English dialog menus etc.
2. Write more extensive user documentation. If you use a particular part of GeoRaptor a lot and think
you have found out all its functionality and quirks, contact us and offer to write a few pages of
documentation on it. (Open Office or Microsoft Word is fine.) Easiest way to do this is to simply
make screen captures and annotate with text.
3. Conduct beta testing.
Here are the things that are in the new release.
New functionality:
Overhaul of Validation Functionality.
1. User can specify own validation SELECT SQL as long as it returns three required columns. The SQL is thus totally editable.
2. Validation update code now allows user to associate a PL/SQL function with an error number which is applied in the UPDATE SQL.
3. UPDATE SQL can use WHERE clause of validation SELECT SQL (1) to update specific errors.
   NOTE: The generated UPDATE statement can be manually edited. It is NEVER run by GeoRaptor. To run any UPDATE, copy the statement
   to the clipboard and run in an appropriate SQL Worksheet session within SQL Developer.
4. Main validation table allows:
   a. Sorting (click on column header) and
   b. Filtering.
   c. Copying to Clipboard via right mouse click sub menu of:
      - Geometry's SDO_ELEM_INFO array constructor.
      - SDO_GEOMETRY constructor
      - Error + validation string.
   d. Access to Draw/Zoom functions which were previously buttons.
   e. Added a new right mouse click menu "Show Feature's Individual Errors" that gathers up all the errors
      it can process - along with the ring / element that is host to the error (if it can) - and displays
      them in the Attribute/Geometry tabs at the bottom of the Map Window (where "Identify" places its results).
      The power of this will be evident to all those who have wanted a way of stepping through errors in a geometry.
   f. Selected rows can now be deleted (select rows: press <DELETE> key or right mouse click>Delete).
   g. Table now has only one primary key column, and has a separate error column holding the actual error code.
   h. Right mouse click men added to table menu to display description of error in the new column (drawn from Oracle documentation)
   i. Optimisations added to improve performance for large error lists.
5. Functionality now has its own validation layer that is automatically added to the correct view.
   Access to layer properties via button on validation dialog or via normal right mouse click in view/layer tree.
Improved Rendering Options.
1. Linestring colour can now be random or drawn from column in database (as per Fill and Point colouring)
2. Marking of SDO_GEOMETRY objects overhauled.
   - Ability to mark or LABEL vertices/points of all SDO_GEOMETRY types with coordinate identifier and
     option {X,Y} location. Access is via Labelling tab in layer>properties. Thus, coordinate 25 of a linestring
     could be shown as: <25> or {x,y} or <25> {x,y}
   - There is a nice "stacked" option where the coordinate {x,y} can be written one line below the id.
   - For linestrings and polygons the <id> {x,y} label can be oriented to the angle between the vectors or
     edges that come in, and go out of, a vertex. Access is via "Orient" tick box in Labelling tab.
   - Uses Tools>Preferences>GeoRaptor>Visualisation>SDO_ORDINATE_ARRAY bracket around x,y string.
3. Start point of linestring/polygon and all other vertices can be marked with user selectable point marker
   rather than previously fixed markers.
4. Can now set a NULL point marker by selecting "None" for point marker style pulldown menu.
5. Positioning of the arrow for linestring/polygons has extra options:
   * NONE
   * START    - All segments of a line have the arrow positioned at the start
   * MIDDLE   - All segments of a line have the arrow positioning in the middle.
   * END      - All segments of a line have the arrow positioning in the END.
   * END_ONLY - Only the last segment has an arrow and at its end.
ScaleBar.
1. A new graphic ScaleBar option has been added for the map of each view.
   For geographic/geodetic SRIDs distances are currently shown in meters;
   For all SRIDs an attempt is made to "adapt" the scaleBar units depending
   on the zoom level. So, if you zoom right in you might get the distance shown
   as mm, and as you zoom out, cm/m/km as appropriate.
2. As the scaleBar is drawn, a 1:<DEMONINATOR> style MapScale value is written
   to the map's right most status bar element.
3. ScaleBar and MapScale can be turned off/on in View>Properties right mouse
   click menu.
Export Capabilities.
1. The ability to export a selection from a result set table (ie result of
   executing ad-hoc SQL SELECT statement to GML, KML, SHP/TAB (TAB file
   adds TAB file "wrapper" over SHP) has been added.
2. Ability to export table/view/materialised view to GML, KML, SHP/TAB also
   added. If no attributes are selected when exporting to a SHP/TAB file, GeoRaptor
   automatically adds a field that holds a unique row number.
3. When exporting to KML:
   * one can optionally export attributes.
   * Web sensitive characters < > & etc for KML export are replaced with > < & etc.
   * If a column in the SELECTION or table/view/Mview equals "name" then its value is
     written to the KML tag <name> and not to the list of associated attributes.
     - Similarly for "description" -> <description> AND "styleUrl" -> <styleUrl>
4. When exporting to GML one can optionally export attributes in FME or OGR "flavour".
5. Exporting Measured SDO_GEOMETRY objects to SHP not supported until missing functionality
   in GeoTools is corrected (working with GeoTools community to fix).
6. Writing PRJ and MapInfo CoordSys is done by pasting a string into appropriate export dialog box.
   Last value pasted is remembered between sessions which is useful for users who work with a single SRID.
7. Export directory is remembered between sessions in case a user uses a standard export directory.
8. Result sets containing MDSYS.SDO_POINT and/or MDSYS.VERTEX_TYPE can also be written to GML/KML/SHP/TAB.
   Example:
   SELECT a.geom.sdo_point as point
     FROM (SELECT sdo_geometry(2002,null,sdo_point_type(1,2,null),sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)) as geom
             FROM DUAL) a;
   SELECT mdsys.vertex_type(a.x,a.y,a.z,a.w,a.v5,a.v6,a.v7,a.v8,a.v9,a.v10,a.v11,a.id) as vertex
     FROM TABLE(mdsys.sdo_util.getVertices(mdsys.sdo_geometry(2002,null,null,sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)))) a;
9. A dialog appears at the end of each export which details (eg total) what was exported when the exported recordset/table contains more
   than on shape type. For example, if you export only points eg 2001/3001 from a table that also contains multipoints eg 2005/3005 then
   the number of points exported, and multipoints skipped will be displayed.
10. SHP/TAB export is "transactional". If you set the commit interval to 100 then only 100 records are held in memory before writing.
    However, this does not currently apply to the associated DBASE records.
11. SHP/TAB export supports dBase III, dBase III + Memo, dBase IV and dBase IV + Memo.
    Note: Memo allows text columns > 255 characters to be exported. Non-Memo formats do not and any varchar2 columns will be truncated
    to 255 chars. Some GIS packages support MEMO eg Manifold GIS, some do not.
12. Note. GeoRaptor does not ensure that the SRID of SDO_GEOMETRY data exported to KML is in the correct Google Projection.
    Please read the Oracle documentation on how to project your data is this is necessary. An example is:
    SELECT OBJECTID,
           CODIGO as name,
           NOME as description,
           MI_STYLE,
           SDO_CS.TRANSFORM(shape,'USE_SPHERICAL',4055) as shape
      FROM MUB.REGIONAL;
13. NOTE: The SHP exporter uses the Java Topology Suite (JTS) to convert from SDO_GEOMETRY to the ESRI Shape format. JTS does not handle
    circular curves in SDO_GEOMETRY objects you must "stroke" them using sdo_util.arc_densify(). See the Oracle documentation on how
    to use this.
Miscellaneous.
1. Selection View - Measurement has been modified so that the final result only shows those geometry
   types that were actually measured.
2. In Layer Properties the Miscellaneous tab has been removed because the only elements in it were the
   Geometry Output options which have now been replaced by the new GML/KML/etc export capabilities.
3. Shapefile import's user entered tablename now checked for Oracle naming convention compliance.
4. Identify based on SDO_NN has been removed from GeoRaptor given the myriad problems that it seems to create across versions
   and partitioned/non-partitioned tables. Instead SDO_WITHIN_DISTANCE is now used with the actual search distance (see circle
   in map display): everything within that distance is returned.
5. Displaying/Not displaying embedded sdo_point in line/polygon (Jamie Keene), is now controlled by
   a preference.
6. New View Menu options to switch all layers on/off
7. Tools/Preferences/GeoRaptor layout has been improved.
8. If Identify is called on a geometry a new right mouse click menu entry has been added called "Mark" which
   has two sub-menus called ID and ID(X,Y) that will add the labeling to the selected geometry independently of
   what the layer is set to being.
9. Two new methods for rendering an SDO_GEOMETRY object in a table or SQL recordset have been added: a) Show geometry as ICON
   and b) Show geometry as THUMBNAIL. When the latter is chosen, the actual geometry is shown in an image _inside_ the row/column cell it occupies.
   In addition, the existing textual methods for visualisation: WKT, KML, GML etc have been collected together with ICON and THUMBNAIL in a new
   right mouse click menu.
10. Tables/Views/MViews without spatial indexes can now be added to a Spatial View. To stop large tables from killing rendering, a new preference
    has been added "Table Count Limit" (default 1,000) which controls how many geometry records can be displayed. A table without a spatial
    index will have its layer name rendered in Italics and will write a warning message in red to the status bar for each redraw. Adding an index
    which the layer exists will be recognised by GeoRaptor during drawing and switch the layer across to normal rendering.
Some Bug Fixes.
* Error in manage metadata related to getting metadata across all schemas
* Bug with no display of rowid in Identify results fixed;
* Some fixes relating to where clause application in geometry validation.
* Fixes bug with scrollbars on view/layer tree not working.
* Problem with the spatial networks fixed. Actions for spatial networks can now only be done in the
schema of the current user, as it could happen that a user opens the tree for another schema that
has the same network as in the user's schema. Dropping a drops only the network of the current connected user.
* Recordset "find sdo_geometry cell" code has been modified so that it now appears only if a suitable geometry object is
in a recordset. Please note that there is a bug in SQL Developer (2.1 and 3.0) that causes SQL Developer to not
register a change in selection from a single cell to a whole row when one left clicks at the left-most "row number"
column that is not part of the SELECT statements user columns, as a short cut to selecting a whole row. It appears
that this is a SQL Developer bug so nothing can be done about it until it is fixed. To select a whole row, select all
cells in the row.
* Copy to clipboard of SDO_GEOMETRY with M and Z values forgot has extraneous "," at the end.
* Column based colouring of markers fixed
* Bunch of performance improvements.
* Plus (happily) others that I can't remember!If you find any bugs register a bug report at our website.
If you want to help with testing, contact us at our website.
My thanks for help in this release to:
1. John O'Toole
2. Holger Labe
3. Sandro Costa
4. Marco Giana
5. Luc van Linden
6. Pieter Minnaar
7. Warwick Wilson
8. Jody Garnett (GeoTools bug issues)
Finally, when at the Washington User Conference I explained the willingness of the GeoRaptor Team to work
for some sort of integration of our "product" with the new Spatial extension that has just been released in SQL
Developer 3.0. Nothing much has come of that initial contact and I hope more will come of it.
In the end, it is you, the real users who should and will decide the way forward. If you have ideas, wishes etc,
please contact the GeoRaptor team via our SourceForge website, or start a "wishlist" thread on this forum
expressing ideas for future functionality and integration opportunities.
regards
Simon
Edited by: sgreener on Jun 12, 2011 2:15 PM

Thank you for this.
I have been messing around with this last few days, and i really love the feature to pinpoint the validation errors on map.
I has always been so annoying to try pinpoint these errors using some other GIS software while doing your sql.
I have stumbled to few bugs:
1. In "Validate geometry column" dialog checking option "Use DimInfo" actually still uses value entered in tolerance text box.
I found this because in my language settings , is the decimal operators
2. In "Validate geometry column" dialog textboxs showing sql, doesn't always show everything from long lines of text (clipping text from right)
3. In "Validate geometry column" dialog the "Create Update SQL" has few bugs:
- if you have selected multiple rows from results and check the "Use Selected Geometries" the generated IN-clause in SQL with have same rowid (rowid for first selected result) for all entries
Also the other generated IN clause in WHERE-clause is missing separator if you select more than one corrective function
4. "Validate geometry column" dialog stays annoyingly top most when using "Create Update SQL" dialog

Imminent Release of new GeoRaptor Version

Folks,
I am pleased to announce, after 4 months of development and testing, that a new release of GeoRaptor should be released hopefully before
the 2011 Oracle Spatial User Conference in Washington DC this Thursday 19th.
The release manager will make that release but firstly we have to work out how to handle support for SQL Developer 2.1 (which a lot of you
use) and 3.0 (which has recently been released). The reason for this is that the SQL Developer team changed some API calls such that
we have to make separate compilations. We are not sure how to support these within the SQL Developer extensions distribution framework.
It may be that we support download of the 3.0 version via the Oracle extension publication mechanism and the 2.1 version via direct download
from our Sourceforge website. We will inform you when this has been resolved.
No release notes have been compiled as the principal developer (oops, that's me!) will be leaving Australia tomorrow to attend the DC User Conference.
More extensive notes (with images) will be compiled when I get back.
We are still looking for people to:
1. Provide translations of the English dialog menus etc.
2. Write more extensive user documentation. If you use a particular part of GeoRaptor a lot and think you have found out all its functionality and quirks, contact
us and offer to write a few pages of documentation on it. (Open Office or Microsoft Word is fine.)
Here are the things that are in the next release.
New functionality:
Overhaul of Validation Functionality.
1. User can specify own validation SELECT SQL as long as it returns three required columns. The SQL is thus totally editable.
2. Validation update code now allows user to associate a PL/SQL function with an error number which is applied in the UPDATE SQL.
3. UPDATE SQL can use WHERE clause of validation SELECT SQL (1) to update specific errors.
   NOTE: The generated UPDATE statement can be manually edited. It is NEVER run by GeoRaptor. To run any UPDATE, copy the statement
   to the clipboard and run in an appropriate SQL Worksheet session within SQL Developer.
4. Main validation table allows:
   a. Sorting (click on column header) and
   b. Filtering.
   c. Copying to Clipboard via right mouse click sub menu of:
      - Geometry's SDO_ELEM_INFO array constructor.
      - SDO_GEOMETRY constructor
      - Error + validation string.
   d. Access to Draw/Zoom functions which were previously buttons.
   e. Added a new right mouse click menu "Show Feature's Individual Errors" that gathers up all the errors
      it can process - along with the ring / element that is host to the error (if it can) - and displays
      them in the Attribute/Geometry tabs at the bottom of the Map Window (where "Identify" places its results).
      The power of this will be evident to all those who have wanted a way of stepping through errors in a geometry.
   f. Selected rows can now be deleted (select rows: press <DELETE> key or right mouse click>Delete).
   g. Table now has only one primary key column, and has a separate error column holding the actual error code.
   h. Right mouse click men added to table menu to display description of error in the new column (drawn from Oracle documentation)
   i. Optimisations added to improve performance for large error lists.
5. Functionality now has its own validation layer that is automatically added to the correct view.
   Access to layer properties via button on validation dialog or via normal right mouse click in view/layer tree.
Improved Rendering Options.
1. Linestring colour can now be random or drawn from column in database (as per Fill and Point colouring)
2. Marking of SDO_GEOMETRY objects overhauled.
   - Ability to mark or LABEL vertices/points of all SDO_GEOMETRY types with coordinate identifier and
     option {X,Y} location. Access is via Labelling tab in layer>properties. Thus, coordinate 25 of a linestring
     could be shown as: <25> or {x,y} or <25> {x,y}
   - There is a nice "stacked" option where the coordinate {x,y} can be written one line below the id.
   - For linestrings and polygons the <id> {x,y} label can be oriented to the angle between the vectors or
     edges that come in, and go out of, a vertex. Access is via "Orient" tick box in Labelling tab.
   - Uses Tools>Preferences>GeoRaptor>Visualisation>SDO_ORDINATE_ARRAY bracket around x,y string.
3. Start point of linestring/polygon and all other vertices can be marked with user selectable point marker
   rather than previously fixed markers.
4. Can now set a NULL point marker by selecting "None" for point marker style pulldown menu.
5. Positioning of the arrow for linestring/polygons has extra options:
   * NONE
   * START    - All segments of a line have the arrow positioned at the start
   * MIDDLE   - All segments of a line have the arrow positioning in the middle.
   * END      - All segments of a line have the arrow positioning in the END.
   * END_ONLY - Only the last segment has an arrow and at its end.
ScaleBar.
1. A new graphic ScaleBar option has been added for the map of each view.
   For geographic/geodetic SRIDs distances are currently shown in meters;
   For all SRIDs an attempt is made to "adapt" the scaleBar units depending
   on the zoom level. So, if you zoom right in you might get the distance shown
   as mm, and as you zoom out, cm/m/km as appropriate.
2. As the scaleBar is drawn, a 1:<DEMONINATOR> style MapScale value is written
   to the map's left most element in the status bar.
3. ScaleBar and MapScale can be turned off/on in View>Properties right mouse
   click menu.
Export Capabilities.
1. The ability to export a selection from a result set table (ie result of
   executing ad-hoc SQL SELECT statement to GML, KML, SHP/TAB (TAB file
   adds TAB file "wrapper" over SHP) has been added.
2. Ability to export table/view/materialised view to GML, KML, SHP/TAB also
   added. If no attributes are selected when exporting to a SHP/TAB file, GeoRaptor
   automatically adds a field that holds a unique row number.
3. When exporting to KML:
   * one can optionally export attributes.
   * Web sensitive characters < > & etc for KML export are replaced with > < & etc.
   * If a column in the SELECTION or table/view/Mview equals "name" then its value is
     written to the KML tag <name> and not to the list of associated attributes.
     - Similarly for "description" -> <description> AND "styleUrl" -> <styleUrl>
4. When exporting to GML one can optionally export attributes in FME or OGR "flavour".
5. Exporting Measured SDO_GEOMETRY objects to SHP not supported until missing functionality
   in GeoTools is corrected (working with GeoTools community to fix).
6. Writing PRJ and MapInfo CoordSys is done by pasting a string into appropriate export dialog box.
   Last value pasted is remembered between sessions which is useful for users who work with a single SRID.
7. Export directory is remembered between sessions in case a user uses a standard export directory.
8. Result sets containing MDSYS.SDO_POINT and/or MDSYS.VERTEX_TYPE can also be written to GML/KML/SHP/TAB.
   Example:
   SELECT a.geom.sdo_point as point
     FROM (SELECT sdo_geometry(2002,null,sdo_point_type(1,2,null),sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)) as geom
             FROM DUAL) a;
   SELECT mdsys.vertex_type(a.x,a.y,a.z,a.w,a.v5,a.v6,a.v7,a.v8,a.v9,a.v10,a.v11,a.id) as vertex
     FROM TABLE(mdsys.sdo_util.getVertices(mdsys.sdo_geometry(2002,null,null,sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,1,2,2)))) a;
9. A dialog appears at the end of each export which details (eg total) what was exported when the exported recordset/table contains more
   than on shape type. For example, if you export only points eg 2001/3001 from a table that also contains multipoints eg 2005/3005 then
   the number of points exported, and multipoints skipped will be displayed.
10. SHP/TAB export is "transactional". If you set the commit interval to 100 then only 100 records are held in memory before writing.
    However, this does not currently apply to the associated DBASE records.
11. SHP/TAB export supports dBase III, dBase III + Memo, dBase IV and dBase IV + Memo.
    Note: Memo allows text columns > 255 characters to be exported. Non-Memo formats do not and any varchar2 columns will be truncated
    to 255 chars. Some GIS packages support MEMO eg Manifold GIS, some do not.
12. Note. GeoRaptor does not ensure that the SRID of SDO_GEOMETRY data exported to KML is in the correct Google Projection.
    Please read the Oracle documentation on how to project your data is this is necessary. An example is:
    SELECT OBJECTID,
           CODIGO as name,
           NOME as description,
           MI_STYLE,
           SDO_CS.TRANSFORM(shape,'USE_SPHERICAL',4055) as shape
      FROM MUB.REGIONAL;
13. NOTE: The SHP exporter uses the Java Topology Suite (JTS) to convert from SDO_GEOMETRY to the ESRI Shape format. JTS does not handle
    circular curves in SDO_GEOMETRY objects you must "stroke" them using sdo_util.arc_densify(). See the Oracle documentation on how
    to use this.
Miscellaneous.
1. Selection View - Measurement has been modified so that the final result only shows those geometry
   types that were actually measured.
2. In Layer Properties the Miscellaneous tab has been removed because the only elements in it were the
   Geometry Output options which have now been replaced by the new GML/KML/etc export capabilities.
3. Shapefile import's user entered tablename now checked for Oracle naming convention compliance.
4. Identify based on SDO_NN has been removed from GeoRaptor given the myriad problems that it seems to create across versions
   and partitioned/non-partitioned tables. Instead SDO_WITHIN_DISTANCE is now used with the actual search distance (see circle
   in map display): everything within that distance is returned.
5. Displaying/Not displaying embedded sdo_point in line/polygon (Jamie Keene), is now controlled by
   a preference.
6. New View Menu options to switch all layers on/off
7. Tools/Preferences/GeoRaptor layout has been improved.
8. If Identify is called on a geometry a new right mouse click menu entry has been added called "Mark" which
   has two sub-menus called ID and ID(X,Y) that will add the labeling to the selected geometry independently of
   what the layer is set to being.
Some Bug Fixes.
* Error in manage metadata related to getting metadata across all schemas
* Bug with no display of rowid in Identify results fixed;
* Some fixes relating to where clause application in geometry validation.
* Fixes bug with scrollbars on view/layer tree not working.
* Problem with the spatial networks fixed. Actions for spatial networks can now only be done in the
schema of the current user, as it could happen that a user opens the tree for another schema that
has the same network as in the user's schema. Dropping a drops only the network of the current connected user.
* Recordset "find sdo_geometry cell" code has been modified so that it now appears only if a suitable geometry object is
in a recordset. Please note that there is a bug in SQL Developer (2.1 and 3.0) that causes SQL Developer to not
register a change in selection from a single cell to a whole row when one left clicks at the left-most "row number"
column that is not part of the SELECT statements user columns, as a short cut to selecting a whole row. It appears
that this is a SQL Developer bug so nothing can be done about it until it is fixed. To select a whole row, select all
cells in the row.
* Copy to clipboard of SDO_GEOMETRY with M and Z values forgot has extraneous "," at the end.
* Column based colouring of markers fixed
* Bunch of performance improvements.
* Plus (happily) others that I can't remember!If you find any bugs register a bug report at our website.
If you want to help with testing, contact us at our website.
regards
Simon

Hi buddy,
> Yes, it is: Intel site not Toshiba, I'm sorry!
No problem but not its clear what we talk about ;)
> why Toshiba don't pretest latest driver and I must install it on my own risk? The last update is from 1,5 years ago...
I think because Tecra A10 is older model and there is already a successor on the market, Tecra A11.
Well, dont worry about this. Usually the Intel drivers also work. I have tested this on my Satellite U400 and its running with Intel display driver. No problems so installation is worth a try.
Please send some feedback after Intel display driver installation, its really interesting! :)

Oracle spatial 11g - 3D-Geometry and KML-Export

Hi,
I'm currently working with an Oracle Spatial 11g - database and there with 2d- and 3d-geometries. With this Version you can extrude 2d's to 3d's and calculate their volumes. This works fine.
The problem is to save the extruded areas as 3d-geometries in a specific table. Enclosed you will find the SQL-Code of the current workflow:
*1. Create tables for the 2d- and 3d-geometries (incl. metadata and spatial index)*
-- table for 3d-geometry
CREATE
TABLE ta_geb(
geom MDSYS.SDO_GEOMETRY
,area NUMBER(12,3)
-- metadata 2D
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES
     'ta_geb',
     'geom',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X',4439900.00, 4440020.00, 0.005),
MDSYS.SDO_DIM_ELEMENT('Y', 5664050.00, 5664130.00, 0.005)
31468
-- spatial index 2D
CREATE
INDEX ta_geb_index ON ta_geb(geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
-- table for 3d-geometry
CREATE
TABLE ta_3dgeb(
geom3d MDSYS.SDO_GEOMETRY
-- metadata 3D
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES
     'ta_3dgeb',
     'geom3d',
MDSYS.SDO_DIM_ARRAY
(     MDSYS.SDO_DIM_ELEMENT('X',4439900.00, 4440020.00, 0.005),
     MDSYS.SDO_DIM_ELEMENT('Y', 5664050.00, 5664130.00, 0.005),
     MDSYS.SDO_DIM_ELEMENT('Z', 0, 200, 0.005)
31468
-- spatial index
CREATE
INDEX ta_3dgeb_index ON ta_3dgeb(geom3d) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('SDO_INDX_DIMS=3');
*2. insert 2d-geomtry*
INSERT
INTO
ta_geb
VALUES
MDSYS.SDO_GEOMETRY(
2003
,31468
,NULL
,MDSYS.SDO_ELEM_INFO_ARRAY(
1
,1003
,1
,MDSYS.SDO_ORDINATE_ARRAY(
     4439975.91,5664077.07,
          4439967.98,5664072.06,
          4439975.33,5664060.42,
          4439983.26,5664065.43,
          4439975.91,5664077.07
,null --area
*3. calculate volume of the extruded area*
SELECT SDO_GEOM.SDO_VOLUME(SDO_UTIL.EXTRUDE(
     GEOM,
     SDO_NUMBER_ARRAY(0),
     SDO_NUMBER_ARRAY(10),
     'false', --validation
     0.005),0.005)
from ta_geb;
This works fine so far. Now I wanna insert the extruded geometry (now 3D) in the table ta_3dgeb. All my attempts were in vain...
*4. insert extruded geomtry*
INSERT
INTO
ta_3dgeb
select
SDO_UTIL.EXTRUDE(
          GEOM,
          SDO_NUMBER_ARRAY(0),
          SDO_NUMBER_ARRAY(10),
          'false', --validation
          0.005)
from ta_geb;
I got the following error message after executing this Code:
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
ORA-06512: in "MDSYS.SDO_INDEX_METHOD_10I", line 709
ORA-06512: in "MDSYS.SDO_INDEX_METHOD_10I", line 225
Then I tried to change something on the metadata and spatial indices, wihtout success. Does anyone has advices to solve the problem??
Afterwards I would like to export the 3d-geometry in a KML file to visualize it in Google Earth. Therefore oracle provides a tool. But I didn't managed it to export the geometry. Any hints for the KML export or are there any other tools alternatively??
Thanks for any suggestions!
Regards

Extrude does not automatically populate the SRID for the resulting geometry as there may not be a 3D equivalent of the 2D SRID defined
in the DB.
So the extruded geometry comes out without the SRID. In your case, since you are creating an index on the ta_3dgeb table
before inserting the extruded data, it is causing this failure.
So drop the index on the ta_3dgeb table and do the inserts into it.
Then you can manually update the geometries with the SRID if there is a corresponding 3D SRID for 31468.
Otherwise, you can use 31468.
siva

I cant start netasst after I installed oracle-8.1.7.01 for linux(redhat 7.2))

I can run netca normal
I found some problem in the last two rows of th netasst,who can help me.
below is th netasst scripts in my machine:
#!/bin/sh
# $Header: netasst.sbs 10-jul-00.14:40:53 mclose Exp $
# Copyright (c) Oracle Corporation 1997, 1998, 1999, 2000. All Rights Reserved.
# NAME
# netasst - Shell script to run Net Assistant
# DESCRIPTION
# Runs the Net Assistant Java Application. This file comes in two
# forms its original, with a .sbs extension, and its final, without
# a .sbs extension. The .sbs version is source for the final
# version which the Oracle Universal Installer creates by
# doing variable substitution at install time.
# MODIFIED (MM/DD/YY)
# mclose 07/10/00 - Change location of ewtcompat
# mclose 11/19/99 - Update to ewtcompat 3.3.6
# mclose 10/13/99 - 816 install variable changes
# mclose 09/22/99 - Remove JRE -native flag (990089)
# mclose 09/17/99 - add nls message jar
# rgiardin 07/22/99 - update dependency versions
# rgiardin 07/14/99 - remove extraneous header info.
# rgiardin 07/14/99 - add config jar dependency
# mclose 06/24/99 - fixed bug 882986
# mclose 01/14/99 - Update to ewt 3.1.10.
# mclose 12/30/98 - Add check for DISPLAY
# rgiardin 12/16/98 - stop changing to %TOOLS dir before running asst
# rgiardin 12/07/98 - update ewt version to 3_1_9
# rgiardin 11/20/98 - update ewt ver to 3.1.8.1
# rgiardin 11/18/98 - update ewt version to 318 and remove reference to e
# mclose 11/13/98 - Change substitution variable names
# rgiardin 11/11/98 - add ewtcompat variable for sed replacement
# mclose 11/03/98 - Change for sbs to shell script processing
# mclose 10/28/98 - added missing HotJavaBean.jar
# mclose 09/02/98 - Update for 8.1.4
# mclose 07/01/98 - Set 8.1.3 location for maf,ewtcompat,ewtdev
# mclose 06/04/98 - add $ORACLE_HOME/lib to LD_LIBRARY_PATH
# mclose 06/04/98 - Fix possible classpath problem
# mclose 06/02/98 - fix Net Assistant schell script for 8.1
# skanjila 10/15/97 - Append current LD_LIBRARY_PATH
# skanjila 06/05/97 - Add i18n.jar in classpath
# skanjila 05/28/97 - Creation
case $ORACLE_HOME in
"") echo "****ORACLE_HOME environment variable not set!"
echo " ORACLE_HOME should be set to the main"
echo " directory that contains Oracle products."
echo " Set and export ORACLE_HOME, then re-run."
exit 1;;
esac
case $DISPLAY in
"") echo "****DISPLAY environment variable not set!"
echo " Net8 Assistant is a GUI tool which"
echo " requires that DISPLAY specify a location"
echo " where GUI tools can display."
echo " Set and export DISPLAY, then re-run."
exit 1;;
esac
# Unset any existing JAVA_HOME variable to ensure that only
# the JRE we want to use is used.
unset JAVA_HOME
# External Directory Variables set by the Installer
JREDIR=/usr/app/oracle/product/8.1.7.0/JRE
JLIBDIR=/usr/app/oracle/product/8.1.7.0/jlib
# External File Variables set by the Installer
SHAREJAR=$JLIBDIR/share-1_0_8.jar
SWINGJAR=$JLIBDIR/swingall-1_1_1.jar
EWTJAR=$JLIBDIR/ewt-3_3_6.jar
EWTOTHER=$JLIBDIR/ewtcompat-opt-3_3_6.zip
HELPJAR=$JLIBDIR/help-3_1_8.jar:$JLIBDIR/ice-4_06_6.jar
NETCFGJAR=$JLIBDIR/netcfg.jar
MAFJAR=$ORACLE_HOME/network/jlib/sysmanmaf.jar
# Net Assistant Directory Variables
NETJLIBDIR=$ORACLE_HOME/network/jlib
NETTOOLSDIR=$ORACLE_HOME/network/tools
# Net Assistant File Variables
NETASSTJAR=$NETJLIBDIR/netasstm.jar:$NETJLIBDIR/netasst.jar
# JRE Executable and Class File Variables
JRE=$JREDIR/bin/jre
JREJAR=$JREDIR/lib/rt.jar:$JREDIR/lib/i18n.jar
# Set Classpath for Net Assistant
CLASSPATH=$NETASSTJAR:$MAFJAR:$EWTJAR:$HELPJAR:$SHAREJAR:$JREJAR:$EWTOTHER:$NETCFGJAR:$SWINGJAR:$NETTOOLSDIR
# Set the shared library path for JNI shared libraries
# A few platforms use an environment variable other than LD_LIBRARY_PATH
SET_DEFAULT=YES
PLATFORM=`uname`
case $PLATFORM in "HP-UX")
SET_DEFAULT=NO
SHLIB_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/network/lib:$SHLIB_PATH
export SHLIB_PATH
esac
case $SET_DEFAULT in "YES")
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/network/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
esac
# Run Net Assistant
$JRE -classpath $CLASSPATH oracle.net.asst.container.NetApplication oracle.net.asst.container.NetApplication
exit $status

I don't understand:
My spatial data does not use projection (the SRIDs are 262148).
What is 262148? It is an SRID that isn't in the 8.1.7.4 database.
If the SRID isn't an issue, you might want to make sure the coordinate
system bounds of the geometries match if your data is coming from two
different tables and they both have quadtree indexes built on them.
If the coordinate system bounds don't match, then you can see this kind of problem.
Hope this helps,
Dan

Sdo_util.simplify - Error? Bug? Totally stumped !

Hi folks,
I have a confusing problem/error with using sdo_util.simplify. I am using Oracle 11G R2 with Spatial Option.
I have loaded just over 2000 UK postown polygons - based on an OS source. These loaded fine and have been working perfectly well with spatial sql.
The source data specifies the projection as British National Grid GCS_OSGB_1936 and the SRID within the Oracle metadata was correctly (i believe) determined (by calculate mbr) and set to 7405 - OSGB36 / British National Grid
I can view the polygons perfectly fine in SqlDeveloper/GeoRaptor and if export them to KML and view them in Google Earth they position and display exactly as I would expect.
All other spatial functions I have tried on the polygons work fine.
The problem comes when I try and use sdo_util.simplify to reduce the number of co-ordinates used on the polygons :
select sdo_util.simplify(poly_hi,100,0.005)
from posttown_boundaries;
ORA-13199: the given geometry cannot be rectified
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_UTIL", line 716
ORA-06512: at "MDSYS.SDO_UTIL", line 770
ORA-06512: at line 1
13199. 00000 - "%s"
*Cause:    This is an internal error.
*Action:   Contact Oracle Support Services.
I've tried various threshold and tolerance values ( the only threshold value that works is 0 which returns the same geometry.
I have successfully used the sdo_util.simpify functions on the other spatial objects in the database so I don't believe it to be a database setup issue.
When I run a validate geometry on the table for the geometry column I get the ORA-13029: Invalid SRID in the SDO_GEOMETRY object.
However, as explained above the SRID was selected and checked using calculate MBR and it matches exactly what I would have expected given the source data and i have not found any other issues with the SRID.
The error can be reproduced without any of the source tables by just taking one small polygon definition as follows:
select sdo_util.simplify(
MDSYS.SDO_GEOMETRY(
2003,7405,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
MDSYS.SDO_ORDINATE_ARRAY(407207.997315803,287087.001455892,
406802.999914517,286916.000404434,
406677.996543163,286831.004734191,
406518.001132497,286741.000497636,
406863.996876543,286566.000590838,
407284.000289033,286672.000248752,
407207.997315803,287087.001455892))
,5,0.005)
FROM dual;
ORA-13199: the given geometry cannot be rectified
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_UTIL", line 716
ORA-06512: at "MDSYS.SDO_UTIL", line 770
ORA-06512: at line 1
13199. 00000 - "%s"
*Cause:    This is an internal error.
*Action:   Contact Oracle Support Services.
Am totally stumped with this!
Can anyone offer any thoughts or guidance?
Many thanks in advance.
Mike.

Hi Mike,
Usually someone jumps in early with the "geometry ain't valid" answer so I am late to the party. When I attempt to validate your 7405 geometry using 11gR2, I receive back error 13029.
SELECT
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
   MDSYS.SDO_GEOMETRY(
      2003,
      7405,
      NULL,
      MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
      MDSYS.SDO_ORDINATE_ARRAY(
         407207.997315803,287087.001455892,
         406802.999914517,286916.000404434,
         406677.996543163,286831.004734191,
         406518.001132497,286741.000497636,
         406863.996876543,286566.000590838,
         407284.000289033,286672.000248752,
         407207.997315803,287087.001455892
   0.005
FROM
dualThe error indicates that SRID 7405 "is invalid" which is not really all that informative. As you note above 7405 exists in MDSYS but its marked as a COMPOUND CRS which to keep it simple is a 3D CRS.
(see http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_cs_concepts.htm#autoId18)
Thus "invalid" in this context means the SRID is invalid for the geometry you are putting it upon.
So if we just add a Z to your geometry everything works hunky-dory
SELECT
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
   MDSYS.SDO_GEOMETRY(
      3003,
      7405,
      NULL,
      MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
      MDSYS.SDO_ORDINATE_ARRAY(
         407207.997315803,287087.001455892,0,
         406802.999914517,286916.000404434,0,
         406677.996543163,286831.004734191,0,
         406518.001132497,286741.000497636,0,
         406863.996876543,286566.000590838,0,
         407284.000289033,286672.000248752,0,
         407207.997315803,287087.001455892,0
   0.005
FROM
dualAnd your SIMPLIFY task also then works fine
SELECT
SDO_UTIL.SIMPLIFY(
   MDSYS.SDO_GEOMETRY(
      3003,
      7405,
      NULL,
      MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
      MDSYS.SDO_ORDINATE_ARRAY(
         407207.997315803,287087.001455892,0,
         406802.999914517,286916.000404434,0,
         406677.996543163,286831.004734191,0,
         406518.001132497,286741.000497636,0,
         406863.996876543,286566.000590838,0,
         407284.000289033,286672.000248752,0,
         407207.997315803,287087.001455892,0
   5,
   0.005
FROM
dualSo long-winded way to reiterate what Ivan said - you are using the wrong SRID. 10g was more forgiving than 11g when mixing and matching 3D and 2D SRIDs with data. 11g is more picky but not always that great at explaining the pickiness. I would bet if you had got back an error such as "2D coordinates not valid with 3D SRID" you would never have needed to post the question. I would suggest putting in an enhancement request to Support for some better error messages.
Cheers,
Paul
Edited by: Paul Dziemiela on Nov 6, 2011 10:58 AM

There are problems with quadtree indexing in Oracle 8.1.7.4 for Linux

I have patched my 8.1.7 database on Linux to 8.1.7.4.
All my spatial data were indexed using quadtree indexing mechanizm.
After the patch is proceeded, I'v rebuilt all spatial indexes (because all they became invalid).
When I use window query type, the spatial query does not give right results!
There are no errors, but not all geometries following in the query rectangle are selected.
My spatial data does not use projection (the SRDIDs are 262148).
If there is layer with other srid - there are no transformation between projections query rectngle and layer geometries (the query rectangle is with SRID = null).
When I change indexing mechanizm to R-tree - there are no problems.
What is the problem?

I don't understand:
My spatial data does not use projection (the SRIDs are 262148).
What is 262148? It is an SRID that isn't in the 8.1.7.4 database.
If the SRID isn't an issue, you might want to make sure the coordinate
system bounds of the geometries match if your data is coming from two
different tables and they both have quadtree indexes built on them.
If the coordinate system bounds don't match, then you can see this kind of problem.
Hope this helps,
Dan

Spatial query error, while trying to retrieve information in an specific radio

Could you please help me to solve this problem, im trying to get information in an specific radio and throws me this error.
SQL> select name, mi_prinx, geoloc from PUE_INT WHERE MDSYS.SDO_WITHIN_DISTANCE(GEOLOC, MDSYS.SDO_GEOMETRY( 1, NULL, MDSYS.SDO_POINT_TYPE(0,
0, NULL), MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1), MDSYS.SDO_ORDINATE_ARRAY(-98.19, 19.015)),'distance=.5
') = 'TRUE';
select clasificacion1, nombre, calle, numero, delmun, estado, telefono, mi_prinx, geoloc from PUE_IN
ERROR at line 1:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13208: internal error while evaluating [window SRID does not match layer
SRID] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 84
ORA-06512: at line 1
Thank you so much!

Hi, thanks for answer but i still have a problem.
I already get de SRID that geoloc field has, so i'm not using NULL in SRID. I try both options you have given to me but i still have an exception:
SQL> select geoloc from (select geoloc from pue_int) WHERE MDSYS.SDO_WITHIN_DISTANCE(GEOLOC, MDSYS.S
DO_GEOMETRY(2001, 8192, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1), MDSYS.SDO_ORDINATE_ARRAY(-98.19, 19.0
15)),'distance=.5') = 'TRUE';
select geoloc from (select geoloc from pue_int) WHERE MDSYS.SDO_WITHIN_DISTANCE(GEOLOC, MDSYS.SDO_GE
ERROR at line 1:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13052: unsupported geometric type for geometry WINDOW_OBJECT.
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 84
ORA-06512: at line 1
Thank you for helping me!
Hi,
The most likely scenario here is that geoloc has the sdo_srid field filled in, and this data does not:
MDSYS.SDO_GEOMETRY( 1, NULL, <----- note this NULL is the SDO_SRID
Additionally, I would code this geometry in one of two ways:
MDSYS.SDO_GEOMETRY( 2001, SOME_NUMBER_FOR_SDO_SRID, NULL
, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
MDSYS.SDO_ORDINATE_ARRAY(-98.19, 19.015))
note 2001 is a two dimensional point, and also that I NULLed out the MDSYS.SDO_POINT_TYPE
or, preferably:
MDSYS.SDO_GEOMETRY( 2001,SOME_NUMBER_FOR_SDO_SRID,
MDSYS.SDO_POINT_TYPE(-98.19,19.015,NULL) , NULL, NULL)
again using 2001 for a two dimensional point, and this time I nulled out SDO_ELEM_INFO and SDO_ORDINATES.

Loading spatial data by sql *loader

hi there
i have a load_kat_opcina.ctl file from which i should load spatial data into my 10g db table.
load_data.ctl file is as shown below:
LOAD DATA
INFILE *
REPLACE
CONTINUEIF NEXT(1:1) = '#'
INTO TABLE KAT_OPCINA
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(KO_MBR          NULLIF KO_MBR=BLANKS,
KO_SIFRA          NULLIF KO_SIFRA=BLANKS,
KO_NAZIV          NULLIF KO_NAZIV=BLANKS,
KO_ID          NULLIF KO_ID=BLANKS,
ID          NULLIF ID=BLANKS,
is_null1 FILLER CHAR,
POVRSINA     COLUMN OBJECT NULLIF is_null1='E'
(     sdo_gtype INTEGER EXTERNAL,
     sdo_srid INTEGER EXTERNAL NULLIF POVRSINA.sdo_srid=BLANKS,
     SDO_POINT COLUMN OBJECT NULLIF is_null1='C'
          ( X INTEGER EXTERNAL,
          Y INTEGER EXTERNAL,
          Z INTEGER EXTERNAL NULLIF POVRSINA.SDO_POINT.Z=BLANKS),
     SDO_ELEM_INFO VARRAY terminated by ';' NULLIF is_null1='P'
     (SDO_ORDINATES INTEGER EXTERNAL),
     SDO_ORDINATES VARRAY terminated by ':' NULLIF is_null1='P'
     (SDO_ORDINATES INTEGER EXTERNAL)
BEGINDATA
0|426|MARKU[EVEC|314717|6789094|
0|3131|VURNOVEC|16605787|6789097|
#C|2003|||||1|1005|3|1|2|1|169|......|5589490440|5082192250:
0|3034|\UR\EKOVEC|16225011|6789100|
0|35|^EHI|12297784|6789190|
#C|2003|||||1|1005|2|1|2|1|239|....|5574944600|5064714553:
0|221|ODRANSKI OBRE@|12441649|6789193|
0|353|TRPUCI|14071974|6789199|
i have deleted most of data here due to space savings.
i call sql *loader from winxp command prompt as follows:
SQLLDR CONTROL=C:\temp\load_kat_opcina.ctl, USERID=username/pswrd@sid, LOG=logfile.log,BAD==baz.bad, DISCARD=DISCARD=toss.dsc
after executing command, table 'kat_opcina' is not filled with data from this .ctl file.
the following is the content of the log file:
SQL*Loader: Release 10.2.0.1.0 - Production on Sri Svi 31 14:20:28 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Control File: C:\TEMP\load_kat_opcina.ctl
Data File: C:\TEMP\load_kat_opcina.ctl
Bad File: C:\TEMP\baz.bad
Discard File: C:\TEMP\toss.dsc
(Allow all discards)
Number to load: ALL
Number to skip: 0
Errors allowed: 50
Bind array: 64 rows, maximum of 256000 bytes
Continuation: 1:1 = 0X23(character '#'), in next physical record
Path used: Conventional
Table KAT_OPCINA, loaded from every logical record.
Insert option in effect for this table: REPLACE
TRAILING NULLCOLS option in effect
Column Name Position Len Term Encl Datatype
KO_MBR FIRST * | O(") CHARACTER
NULL if KO_MBR = BLANKS
KO_SIFRA NEXT * | O(") CHARACTER
NULL if KO_SIFRA = BLANKS
KO_NAZIV NEXT * | O(") CHARACTER
NULL if KO_NAZIV = BLANKS
KO_ID NEXT * | O(") CHARACTER
NULL if KO_ID = BLANKS
ID NEXT * | O(") CHARACTER
NULL if ID = BLANKS
IS_NULL1 NEXT * | O(") CHARACTER
(FILLER FIELD)
POVRSINA DERIVED * COLUMN OBJECT
NULL if IS_NULL1 = 0X45(character 'E')
*** Fields in POVRSINA
SDO_GTYPE NEXT * | O(") CHARACTER
SDO_SRID NEXT * | O(") CHARACTER
NULL if POVRSINA.SDO_SRID = BLANKS
SDO_POINT DERIVED * COLUMN OBJECT
NULL if IS_NULL1 = 0X43(character 'C')
*** Fields in POVRSINA.SDO_POINT
X NEXT * | O(") CHARACTER
Y NEXT * | O(") CHARACTER
Z NEXT * | O(") CHARACTER
NULL if POVRSINA.SDO_POINT.Z = BLANKS
*** End of fields in POVRSINA.SDO_POINT
SDO_ELEM_INFO DERIVED * ; VARRAY
NULL if IS_NULL1 = 0X50(character 'P')
*** Fields in POVRSINA.SDO_ELEM_INFO
SDO_ORDINATES FIRST * | O(") CHARACTER
*** End of fields in POVRSINA.SDO_ELEM_INFO
SDO_ORDINATES DERIVED * : VARRAY
NULL if IS_NULL1 = 0X50(character 'P')
*** Fields in POVRSINA.SDO_ORDINATES
SDO_ORDINATES FIRST * | O(") CHARACTER
*** End of fields in POVRSINA.SDO_ORDINATES
*** End of fields in POVRSINA
Record 1: Rejected - Error on table KAT_OPCINA.
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 623
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 227
Record 2: Rejected - Error on table KAT_OPCINA.
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 623
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 227
Record 33: Rejected - Error on table KAT_OPCINA.
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 623
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 227
SQL*Loader-510: Physical record in data file (C:\TEMP\load_kat_opcina.ctl) is longer than the maximum(65536)
SQL*Loader-2026: the load was aborted because SQL Loader cannot continue.
Specify SKIP=33 when continuing the load.
Table KAT_OPCINA:
0 Rows successfully loaded.
33 Rows not loaded due to data errors.
0 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.
Space allocated for bind array: 215168 bytes(64 rows)
Read buffer bytes: 1048576
Total logical records skipped: 0
Total logical records read: 33
Total logical records rejected: 33
Total logical records discarded: 0
Run began on Sri Svi 31 14:20:28 2006
Run ended on Sri Svi 31 14:20:32 2006
Elapsed time was: 00:00:04.51
CPU time was: 00:00:00.26
error messages are all the same for record numbers: 3-32.
so, i'd like to know what am i doing wrong that table cannot be filled with data using sql *loader.
also, would like to know if there's another way of loading data into table from .ctl file (using maybe some other tool)
appreciate any help
thanks

Hi,
You receive:
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
Have you created spatial index for table PORVSINA? I guess that yes, and you have created it with non NULL SRID value? So, ORA-13365 means that you are trying to insert spatial data with SRID that is not the same as SRID defined in spatial index.
Check index SRID and your data SRID, they must be the same. Or, you can disable spatial index.
Andrejus

Help, spatial, reverb, chorus features reset themselves at star

I have an Ensoiq audio PCI (model CT480) soundcard, everytime the computer boots, the spatial, reverb, and chorus checkboxes are checked even though i unchecked them, this only happens when the computer starts, I have reformatted and installed windows 98 SE 2 times, i have removed and installed the VxD drivers (file version 4.2.0.206 as it says in the "driver file" details on System Properties), and i've tried removing Legacy and Joystick support (i have Allow LPT Interrupt Sharing checkbox checked) but it still resets itself, my soundcard is in IRQ 0 only the soundcard (Legacy or Joystick are not enabled) is enabled, i have the BIOS setting of PNP OS to YES and I really don't know what else to do, any help would be extremely appreciated, thanks in advance

Thanks for the additional information.
I guess your scale probably relates to your photo on a paper.
The way that you try to calculate the resolution for item (5), seems more to identify the map resolution on screen (96 dpi seems related to screen), and not to identify the resolution of your digital image. And also, I think it doesn't seem correct, as some other conversions between cm and inches and also degrees (unit of your data) may be needed. This may be a little bit more tricky, and I think you don't need this. Actually what you want is to compute the resolution of the original digital image.
As you have the MBR of you planar image and the size of the image, I would calculate the resolution using those values.
a) Your MBR is: -27,-40,27,40
b) Your image size is 504x596
c) the resolutions would be:
resx = 54/504 = 0.10714
resy = 80/596 = 0.13428
d) using the import image option in MapBuilder you can enter:
Top left x = -27
Top left Y = 40
resx = 0.10714
resy = 0.13428
About the SRID, the information is on mdsys.cs_srs (next version of MapBuilder will show the list values). As you may not know the correct SRID, use the default 8307.
The center point in MapViewer's map request will be the center of your map on screen. The size defines the map height.

Not so spherical mercator? SRID 3857?

Similar Messages

Maybe you are looking for