VALIDATE GEOMETRY

Hello,
I have a table that contains boundary of governorates,
I am using VALIDATE_GEOMETRY_WITH_CONTEXT to check that each geometry is in valid format or not,
i need to check each geometry if there is any intersect, overlap, CoveredBy,Touch...... with its neighbor geometry
when i am trying using function from the SDO_GEOM package such as WITHIN_DISTANCE to get neighbor geometry and SDO_INTERSECTION , SDO_RELATE It takes long time
Is there any function gets what i need and takes less time ?
should i use topology ?
Thanks in advance,
Abacy

Hi Abacy,
If you can show us your queries, we will have a better idea.
That said, you may try operator: sdo_within_distance. For example,
in http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_complex_queries.htm#CIHIAIDD
SELECT /*+ ORDERED */ c.city
FROM geod_interstates i, geod_cities c
WHERE i.highway = 'I170'
AND sdo_within_distance (
c.location, i.geom,
'distance=15 unit=mile') = 'TRUE';
sdo_within_distance uses a spatial index, so that it is faster than function SDO_GEOM.WITHIN_DISTANCE.
Furthermore, if possible, use 11.2.0.3. If not, get patch 12400749 on 11.2.0.2.
Thanks,
Ying

Similar Messages

Validate Layer verses Validate Geometry

Can someone explain the difference between validating a layer and validating a geometry?
Can a layer be valid with faulty geometry?
Thanks

Hi Bruce,
Both validate geometries.
Validate_layer outputs the results to a table, and is a batch operation. Depending on the version, you can set a commit_interval where the table will contain only the invalid geometries and a marker every commit_interval to let you know how the validation is proceeding.
Validate_geometry is meant to be a geometry-at-a-time kind of operation, because if you run it against a large table the results will scroll off your screen.
hope this helps,
dan

Validate geometry can't check polygon with puncture?

Hi,
I have polygon with puncture as follow:
POLYGON ((100.378750779898 -0.310282546668259, 100.378772459506 -0.310271543916926, 100.378838852504 -0.310235840196097, 100.378845732154 -0.310224416657996, 100.378844002915 -0.31020930373441, 100.37871739762 -0.309977750136478, 100.378616547328 -0.310045414011517, 100.378548060368 -0.309924611880424, 100.378750779898 -0.310282546668259))
According to OGC simple feature it is invalid geometry because it has a puncture. ArcGIS SDE can't render this geoemetry. However, sdo_geometry.validate_geoemetry says it is a valid geometry. Why sdo doesn't consider this as an invalid geoemrty?

Hi,
It'd be useful if you provided a bit more information with your post:
- your name (user3907494 ?)
- the version of Oracle
- the tolerance that you validated at
Note that the geometry doesn't actually seem to be self intersecting - there seems to be an 8mm gap at the point where you might think it self intersects.
I validated the geometry on 10.2.0.5 and 11.2.0.2 and got different results.
Invalid on 10.2.0.5:
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for 64-bit Windows: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
5 rows selected.
SQL> select sdo_geom.validate_geometry_with_context(
2    sdo_geometry(2003, 8307, null, sdo_elem_info_array(1,1003,1),
3    sdo_ordinate_array(
4    100.378750779898, -0.310282546668259,
5    100.378772459506, -0.310271543916926,
6    100.378838852504, -0.310235840196097,
7    100.378845732154, -0.310224416657996,
8    100.378844002915, -0.31020930373441,
9    100.37871739762, -0.309977750136478,
10    100.378616547328, -0.310045414011517,
11    100.378548060368, -0.309924611880424,
12    100.378750779898, -0.310282546668259
13    )), 0.00005) as result
14 from dual;
RESULT
13349 [Element <1>] [Ring <1>][Edge <8>][Edge <6>]Valid on 11.2.0.2
SQL> 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
5 rows selected.
SQL> select sdo_geom.validate_geometry_with_context(
2    sdo_geometry(2003, 8307, null, sdo_elem_info_array(1,1003,1),
3    sdo_ordinate_array(
4    100.378750779898, -0.310282546668259,
5    100.378772459506, -0.310271543916926,
6    100.378838852504, -0.310235840196097,
7    100.378845732154, -0.310224416657996,
8    100.378844002915, -0.31020930373441,
9    100.37871739762, -0.309977750136478,
10    100.378616547328, -0.310045414011517,
11    100.378548060368, -0.309924611880424,
12    100.378750779898, -0.310282546668259
13    )), 0.00005) as result
14 from dual;
RESULT
TRUEI'm not too sure why this happens. Maybe someone else can comment?
Regards,
John

SDO_UTIL.EXTRACT fail when single item in geometry collection

Hi folks,
Didn't we have a discussion a while back on whether geometry collections are valid when they only contain a single item? Darned if I can find it with the OTN search function. I think back then the issue was either a multipolygon or multistring with a single item.
Anyhow this time around I have a 2004 geometry collection that for no particular reason happens to only contain a single point. This collection geometry with one item validates TRUE. Just like with multipolygons and multistrings when I attempt to EXTRACT the result I just get back the input geometry (the 2004 in this case) rather than the component part (the 2001). I think this is because there is a test in the EXTRACT routine that checks if there is but one element and if so then returns the original input assuming the original input was gtype 1,2 or 3. Unlike a multipolygon or multistring where I can just assume the output is a polygon or string respectively, with a geometry collection I am rather stumped to figure it out short of inspecting the SDO_ELEM_INFO array. At that point I am kind of writing my own EXTRACT function. I guess I have to do that.
Anyhow, this would lead one to believe that a geometry collection with only one element is not really valid for Oracle Spatial. Or is this a bug in SDO_UTIL.EXTRACT? I have no recollection if that previous conversation ever decided this question. I might humbly suggest that either SDO_UTIL.EXTRACT should successfully unpack the single item or SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT should report an error for this type of collection.
I looked over metalink and cannot find anything logged on the issue. The results are the same on 10gR2 and 11gR2.
If anyone remembers the previous discussion please post the link.
Cheers,
Paul
SELECT
SDO_UTIL.EXTRACT(
   SDO_GEOMETRY(
      2004,
      8265,
      NULL,
      SDO_ELEM_INFO_ARRAY(
         1,
         1,
         1
      SDO_ORDINATE_ARRAY(
         -100.515216953125005261426849756389856339,
         39.98440002562352191262107226066291332245
   1
FROM
dual

Ok,
Let's make a quick distinction between the SDO_GTYPE (all four digits) and the lower-case "gtype" meaning the last digit - e.g. the "type of geometry" per the Oracle Spatial book.
I submitted the above SDO_UTIL.EXTRACT issue to Oracle support yesterday and as I rather expected the response was that this is "expected behavior". The analyst noted that my what I called a collection per its gtype was not a collection but a point. He made the distinction between the gtype and the "geometry definition". I assume by that he means the elem_info_array. So in fact djonio (user 633187) back in November 2009 under Matt's thread had the best answer. I don't see anyway to credit him. :) Hey djonio if you post a response I will give this answer to you.
So the gtype is in truth a kind of convenience marker or fancy hat "hinting" at the contents of the geometry object, but by no means defining it. A point wearing a 2004 hat is still a point and a valid Oracle Spatial point at that. If you want to "really" know what a geometry is you need to unpack and inspect the elem_info_array. So those of us writing code which is only inspecting the gtype are going down the wrong road particularly when our data might be of suspect quality. As djonio says the gtype is a performance shortcut. In my defense I think lots of folks (e.g. certain software from California) work off the gtype alone. So its not like we can just set the gtypes all to be "9999" and say the heck with it all. :) So incorrect gtypes are bad as they hose the performance shortcut that the gtype allows (and certain software demands) but a bad gtype is NOT an invalid geometry. I am not sure I am entirely sold on that idea as VALIDATE_GEOMETRY certainly looks at the gtype when doing its evaluation. Alas, I suppose its all shades of gray here as validate geometry is just responding to my gtype "hint" to give me the best feedback on my input. Perhaps there is a distinction between "good", "bad" and "imprecise" gtypes.
My next question is if the gtype system is just a fancy hat, then how best to catalog basic geometry types? Both multi-points and point clouds share gtype 5 but the elem_info marks them as being unique data types that really require unique handling (I never use point clouds so feel free to argue that point). So rather than just mumbling "5" over and over to myself, what vocabulary might be used? Is it GML time? Hmm, does GML even have a point cloud datatype? I suppose I just make something up? Does anyone else have a system they are using?
Thanks for reading this rambling, feel free to shoot down everything I say. I clearly need more coffee this morning.
Paul

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

GeoRaptor 3.2.1 Released for SQL Developer 3.x

Spatialites!
After 6 months of development and testing, GeoRaptor 3.2.1 has been released for SQL Developer 3.x (tested on 3.0, 3.1 and 3.2). This release no longer supports SQL Developer 1.x or 2.x releases due to internal changes to the SQL Developer APIs.
GeoRaptor can be downloaded from the GeoRaptor project's sourceforge page: http://sourceforge.net/projects/georaptor and installed via Help>Check for Updates>Install from Local File. Installation via SQL Developer's update mechanism should be available soon.
The release notes for this release are:
* Fixed issues with validate geometry functionality in particular the update dialog box.
* Revamped "About GeoRaptor" form. Includes clickable URLs, links to mailing lists, version number listing, thanks to testers etc.
* Placed "About GeoRaptor" icon on GeoRaptor's map toolbar.
* SQL Developer NLS settings accessed: improvements in the display and entry and numeric data.
-- Tolerances in Spatial Layer properties will display with the NLS decimal separator eg 0,05.
     Some parts of GeoRaptor such as Validation that show and accept numbers have not been changed from when someone else modified the code.
     If you double click on the left MBR/right MBR icon in the map at the bottom, the current centre position will display according to the NLS settings.
     Editing the value to jump the map to that point works even with grouping separators and decimal separators being commas!
* Spatial Layer Draw has been modified to use NLS based decimal formatting.
* New geometry marking/labelling options have been added. In particular you can now label the vertices of a linestring/polygon with the following additional elements:
-- Cumulative length
-- Measure (M)
-- Z value
-- Labelling of vertices with <id>{X,Y} now also honours 3/4D geometries. If geometry has XYY then it will be labelled as {X,Y,Z} etc.
* You can also label each vector/segment of a linestring/polygon with:
-- Length
-- Cumulative Length
-- Bearing (approximate for geodetic/geographic data)
-- Distance (approximate for geodetic/geographic data)
-- Bearing and Distance (approximate for geodetic/geographic data)
* The font properties of the mark text can be changed independently of the feature label. This includes the offset and label position (CC, LL, UR etc).
* New feature labelling options have been provided:
-- First/middle/last vertex,
-- Any supplied sdo_point within a line/polygon's sdo_geometry object, or
-- Calculated by GeoRaptor on the client side using Java Topology Suite.
* Result sets now have the ability to:
-- Copy to clipboard all geometries across many rows and columns.
-- Display one or more (selected) geometries in a popup image window. This functionality is also available in the result set generated by an Identify command.
* New GeoRaptor Preferences:
-- Width and height in pixels of the new popup image window (displaying one or more geometry objects) can be set;
-- Colours of orphan, missing and correct metadata entries for Metadata Manager;
-- Prefixing with MDSYS for all currently supported spatial objects - sdo_geometry, sdo_point, sdo_elem_info, sdo_ordinates, sdo_dim_info - has been made an option.
-- There is now a new property called "Show Number Grouping Separator" in Tools>GeoRaptor>Visualisation.
     If it is ticked a number will be formatted with the thousands separator in Tools>Database>NLS eg 10000.000 will display as 10,000.000.
* Sdo_Geometry display of all spaces in text between elements of the sdo_geometry array have been removed.
   This was done mainly to compact the sdo_geometry strings so that they are as small as possible when displaying or copying to clipboard.
* Help pages added to the following dialogs with more to follow:
-- Metadata Manager,
-- Shapefile Importer and
-- Layer Properties dialogs.
* GeoRaptor menu entries renamed. New "Manage All Metadata" entry added to View>GeoRaptor menu.
* Spatial Index creation dialog now supports additional index parameters and parallel build settings.
* Metadata Manager overhauled:
a. Shows:
     1. Metadata entries which have no underlying oracle object (orphan)
     2. Metadata entries for existing underlying objects (existing case)
     3. Database objects with sdo_geometry for which no metadata entry exists (new)
b. All orphan/existing/missing colours for (a) can be set via Preferences>GeoRaptor>Visualisation
c. All actions for main (bottom) metadata table are in a single right mouse click menu.
     Some entries will only appear if a single row is selection (metadata copy), others (delete and copy to clipboard) will appear for one or more.
d. Can now switch between open connections to modify metadata of other objects in schemas other than the starting object.
e. Buttons revamped.
* Tab/Shapefile export:
a. Export now supports NULL valued columns. Can be exported as an empty string (if DBase override in GeoRaptor Preferences is ticked) or
     as a predefined value eg NULL date => 1900-01-01 (set in new GeoRatptor Import/Export Preferences).
b. Some work attempted on export of NLS strings (still not corrected).
c. Objects with no rows now correctly processed.
* Shapefile Import
-- Bug relating to Linux file names corrected.
* Fixed issue (identified by John O'Toole) with spatial index underlying a view not being used in map display.
* Reinstated sdo_nn as the principal method for Identify (requested by John O'Toole).
* Fixed problem with handling single click zoom in and out in GeoRaptor map etc.
* Fixed problem with rendering lines from database item (identified by Vladimir Pek).The new "About GeoRaptor" should be read by all people installing GeoRaptor.
Please, please consider registering your email address with our private email list so that we can get a feel for the sorts of people downloading and installing GeoRaptor.
Please consider helping us with documentation or the internationalisation via translating properties files from English to your native language.
GeoRaptor is written and maintained by people who use SQL Developer and Spatial every day but we don't pretend we know everything that users want: please let us know via our feature request page at SourceForge.
We don't get paid for what we do so are always looking for additional help.
Here are some of the requests we have had for improvements:
1. MySQL access
2. WMS access;
3. Ability to import shapefile data into an existing table;
4. Ability to processing multiple shapefiles into separate tables (current version can import one or more into a single target table);
5. Ability to export/import layer definitions to give to others;
6. Support for non-English character sets for varchar exports to shapefiles.Some are relatively simply, some require a lot of engineering work. For the latter, we are considering alternative funding methods to the currently completely free development approach.
Thanks to the following for their invaluable assistance:
Holger Labe, Germany
John O'Toole, Ireland
Vladimir Pek, Czech Republic
Pieter Minnaar, Holland
Olaf Iseeger, Germany
Sandro Costa, Brazil;
Marco Giana, Australia.regards
Simon Greener
Principal GeoRaptor Developer
Edited by: Simon Greener on Sep 10, 2012 2:43 PM

Simon,
I will admit, I almost never use SQL Developer. I have been a long time Toad user, but for this tool, I fumbled around a bit and got everything up and running quickly.
That said, I tried the new GeoRaptor tool using this tutorial (which is I think is close enough to get the jist). http://sourceforge.net/apps/mediawiki/georaptor/index.php?title=A_Gentle_Introduction:_Create_Table,_Metadata_Registration,_Indexing_and_Mapping
As I stumble around it, I'll try and leave some feedback, and probably ask some rather stupid questions.
Thanks for the effort,
Bryan

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

SQL Developer Extension, GeoRaptor Release 2.1.1 (Build 3) now available

Cross Post.
See details at: GeoRaptor Release 2.1.1 (Build 3) Available for SQL Developer
regards
Simon Greener

Hi,
The original GeoRaptor had some documentation but it has not been updated.
It is a task on the development list but it has a low priority next to the developments we have planned for the next release. (The main ones being the ability to map the whole, or part, of a SELECT statement executed in a SQL Worksheet - including export to shapefile; the addition of multiple SRID-aware Views to enhance the current single, SRID-unaware view; length/area tools; line and polygon selection tools.)
The attribute and geometry tabs in the pane in the lower half of the spatial view will appear when an "identify" operation is executed and selected data exists.
The split into attribute and geometry tabs was done to better control the visualisation experience of a user. The original Geometry tab displayed a single geometry in a non-standard way and allowed a user to drag select ordinates which could then be mapped. The button should have been removed in build 3 but it wasn't. It will probably do nothing. Perhaps in the next release we might replace the button with an ability to select and individual geometry, highlight it and show its points or even show elements in a multi-element geometry eg show me inner ring 2 in the first outer-ring of a multi-polygon. Don't know. If anyone wants this type of functionality register an enhancement request on the sourceforge GeoRaptor website.
Remember, GeoRaptor is an open source, community driven tool. If you want to help by writing documentation eg a simple one page wiki page on how to validate geometry etc (it doesn't have to be a whole manual), or contribute code, let us know. Or if you simply like the tool or want an enhancement, let us know.
It is hard writing a tool in the vacuum of one's own experience (no matter how considerable that might be) in a land far, far away (I live in Hobart, Tasmania, Australia), to let us know how we are going......
regards
Simon

GeoRaptor Release 2.1.1 (Build 3) Available for SQL Developer

Folks,
On 7th July the GeoRaptor development team released version 2.1.1 Build 3 into the public domain.
It can be downloaded from:
http://sourceforge.net/projects/georaptor
This release has a very large list of functional additions and enhancements. A summary of these can be read at the GeoRaptor wiki:
http://sourceforge.net/apps/mediawiki/georaptor/index.php?title=Main_Page
For example, now you can run VALIDATE_GEOMETRY_WITH_CONTEXT and actually have GeoRaptor take you to the errors that are described in the error string that the Oracle function returns! There may be other tools that do this, but I do not know of them: just this functionality would justify the expense of buying GeoRaptor if you had to pay for it, but you don't!
Please download the release from our central site and recommend it to other users of SQL Developer and Spatial.
Also, if you find bugs (a bug in the handling of null geometries in the validate geometry menu has already been fixed - no patch is available as yet for this) or want to request enhancements please visit the GeoRaptor SourceForge page and enter your bug/enhancement request.
Finally, GeoRaptor is an open source development project. If you want to join and help in any way (not just programming), just let us know.
regards
Simon

Hi,
The original GeoRaptor had some documentation but it has not been updated.
It is a task on the development list but it has a low priority next to the developments we have planned for the next release. (The main ones being the ability to map the whole, or part, of a SELECT statement executed in a SQL Worksheet - including export to shapefile; the addition of multiple SRID-aware Views to enhance the current single, SRID-unaware view; length/area tools; line and polygon selection tools.)
The attribute and geometry tabs in the pane in the lower half of the spatial view will appear when an "identify" operation is executed and selected data exists.
The split into attribute and geometry tabs was done to better control the visualisation experience of a user. The original Geometry tab displayed a single geometry in a non-standard way and allowed a user to drag select ordinates which could then be mapped. The button should have been removed in build 3 but it wasn't. It will probably do nothing. Perhaps in the next release we might replace the button with an ability to select and individual geometry, highlight it and show its points or even show elements in a multi-element geometry eg show me inner ring 2 in the first outer-ring of a multi-polygon. Don't know. If anyone wants this type of functionality register an enhancement request on the sourceforge GeoRaptor website.
Remember, GeoRaptor is an open source, community driven tool. If you want to help by writing documentation eg a simple one page wiki page on how to validate geometry etc (it doesn't have to be a whole manual), or contribute code, let us know. Or if you simply like the tool or want an enhancement, let us know.
It is hard writing a tool in the vacuum of one's own experience (no matter how considerable that might be) in a land far, far away (I live in Hobart, Tasmania, Australia), to let us know how we are going......
regards
Simon

Remove element from multi-surface

Hi there,
I am trying to fix some invalid multi-surface geometries that are derived from a 3D source, many of which have ORA-54514: overlapping areas in multipolygon. I can find out which subset geometry (aka the element in this context) is causing the problem with the VALIDATE_GEOMETRY_WITH_CONTEXT function, and even extract just that element (SDO_UTIL.EXTRACT3D), but how do I remove that element from the geometry (and hopefully fix the problem)? Is there any way to view the position of the element within the geometry in the same manner that the Extract3D function requires (i.e. 0,0,1,1,0,0,7), I can return this for the problem element but not for any of the other subset geometries. Unfortunately I'm using FME to load the geometries and the topology validation here is not as robust as Oracle, which means I need to fix the geometries once they are loaded, but there doesn't seem to be any tools to do this?
Regards
Dan

Hi Dan,
instead of removing the offending element, how about extracting all the correct ones? Should give the same net effect, I think.
Re FME: I find I can usually validate geometry enough that it will at least pass Oracle's Validate, but that's usually only 2D or 2D with a Z-ordinate (2.5D, as some folks call it).
Regards,
Stefan

Registering layers imported to Oracle via shp2sdo: problem with sdelayer

Hi,
I am using Oracle 9.2.0.5 and ArcSDE / ArcGIS 8.3 on a Windows 2003
server. I have been loading shapefiles into Oracle using the SHP2SDO
utility and have encountered a problem I didn't have to start off
with.
This is my methodology:
1. Use SHP2SDO and SQLLDR to load spatial data into tables in Oracle.
2. Execute the SDO_MIGRATE.TO_CURRENT('tablename','geom') function to
migrate dataset to current version of Oracle.
3. Attempt to register the dataset with SDE using sdelayer -0
register.
Doing it in this order results in an error when executing the sdelayer
command, saying "Cannot create layer. Layer already exists.".
If I do it in the other order - i.e. try to register the dataset
before executing the migrate function - I get a much bigger error:
Underlying DBMS error (-51)
Cannot create layer
ORA-29855: error occurred in the execution of ODCIIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial Index: index build failed
ORA-13206: internal error [Tessellate] while creating the spatial
index
ORA-13249: Error in spatial index: [mdpridxtessellate]
ORA-13200: internal error [ROWID:AAAH/1AAOAAA1dYAAC] in spatial
indexing
ORA-13019: coordinates out of bounds
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
(MDSYS.SPATIAL_INDEX)
I am a novice at managing spatial data in Oracle, being more familiar
with SQL Server, so I may be missing something quite basic. Early in
the process of loading data I was able to both migrate and register
the datasets, but now I am not able to...
I understand this may be an ESRI problem rather than an Oracle one, but I am having no luck finding a solution at present. Any suggestions and advice would be gratefully received.
Many thanks
Sharon

Sharon,
Loading data into the ESRI format IS tricky. I'm not sure what projection you are using, but here is the order in which I have successfully loaded data. A very important step is step 3, as without data (at least with WGS84 and 8.3) the boundaries do not get registered correctly. Also, step 4 may no longer be required with the new shp2sdo tool, but it won't hurt anything:
1.CREATE STRUCTURE - Login as GCM
DROP TABLE VEHICLE_PARKING_AREA;
CREATE TABLE VEHICLE_PARKING_AREA (
PARKING_ID      NUMBER(38) NOT NULL PRIMARY KEY,
OBJECTID      NUMBER,
FNODE_      NUMBER,
TNODE_      NUMBER,
LPOLY_      NUMBER,
RPOLY_      NUMBER,
LENGTH      NUMBER,
EOP_      NUMBER,
EOP_ID      NUMBER,
Shape_Leng      NUMBER,
GEOMETRY      MDSYS.SDO_GEOMETRY);
2. CD TO WHERE DATA IS AND UPLOAD DATA VIA DOS BOX USING SQLLDR:
SQLLDR USERID=GCM/GCM CONTROL=VEHICLE_PARKING_AREA.ctl
3. POPULATE SDO_GEOMETRY TABLE:
DELETE FROM USER_SDO_GEOM_METADATA WHERE TABLE_NAME = 'VEHICLE_PARKING_AREA';
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('VEHICLE_PARKING_AREA', 'GEOMETRY',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', -180.000000000, 180.000000000, 0.000000050),
MDSYS.SDO_DIM_ELEMENT('Y', -90.000000000, 90.000000000, 0.000000050)
8307);
COMMIT;
--- AT this point, you can view the data in the Oracle Spatial Index Advisor...
4. FIX GEOMETRY
execute sdo_migrate.to_current('VEHICLE_PARKING_AREA','GEOMETRY');
5. VALIDATE GEOMETRY (SAVE BUFFER - ALL SHOULD Be TRUE!)
If you see something like: 13356 [Element <1>] [Coordinate <1>] instead of TRUE, it has problems!
Fix it, and go on.
SELECT c.PARKING_ID, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.geometry, 0.000000005)
FROM VEHICLE_PARKING_AREA c;
6. CREATE SPATIAL INDEX
DROP INDEX GCM.tvehprk_SPATIAL_IDX;
CREATE INDEX GCM.tvehprk_SPATIAL_IDX ON GCM.VEHICLE_PARKING_AREA(GEOMETRY)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
-- PARAMETERS('SDO_INDX_DIMS=2 INITIAL=1K NEXT=1K PCTINCREASE=0');
7. REGISTER FEATURE WITH SDE:
sdelayer -o register -l VEHICLE_PARKING_AREA,GEOMETRY -e nls+ -c PARKING_ID -C USER -S "ROADS" -u gcm -p gcm@gcm -i sde:oracle9i
8. MODIFY THE SDE SPATIAL REF # TO UTM:
sdelayer -o alter -l VEHICLE_PARKING_AREA,GEOMETRY -G 4326 -u gcm -p gcm@gcm -i sde:oracle9i
OPTIONAL: View min and max values to see if there is invalid range data:
SELECT aa.MINX, bb.MINY, cc.MAXX, dd.MAXY FROM
(SELECT MIN(t.X) MINX
     FROM GCM.VEHICLE_PARKING_AREA c,
     TABLE(SDO_UTIL.GETVERTICES(c.GEOMETRY)) t) aa,
(SELECT MAX(t.X) MAXX
     FROM GCM.VEHICLE_PARKING_AREA c,
     TABLE(SDO_UTIL.GETVERTICES(c.GEOMETRY)) t) cc,
(SELECT MIN(t.Y) MINY
     FROM GCM.VEHICLE_PARKING_AREA c,
     TABLE(SDO_UTIL.GETVERTICES(c.GEOMETRY)) t) bb,
(SELECT MAX(t.Y) MAXY
     FROM GCM.VEHICLE_PARKING_AREA c,
     TABLE(SDO_UTIL.GETVERTICES(c.GEOMETRY)) t) dd;
OBJECTWS of TYPE:
SELECT COUNT(1) "UNKNOWN"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 0;
SELECT COUNT(1) "POINT"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 1;
SELECT COUNT(1) "LINE or CURVE"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 2;
SELECT COUNT(1) "POLYGON"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 3;
SELECT COUNT(1) "COLLECTION"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 4;
SELECT COUNT(1) "MULTIPOINT"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 5;
SELECT COUNT(1) "MULTILINE or MULTICURVE"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 6;
SELECT COUNT(1) "MULTIPOLYGON"
     FROM GCM.VEHICLE_PARKING_AREA M
     WHERE M.GEOMETRY.GET_GTYPE() = 7;

Has EVDRE suppression been fixed in v7.0 SP5 or SP6 ????

Hi all
I need to know whether a problem has been fixed in either SP5 or SP6 of v7.0.
When we tested SP4, we were unable to suppress EVDRE using flags, where the suppression point of view is different to the point of view in the EVDRE
e.g if time is in your suppression but not in either your rows or columns
The problem apparently did not exist in SP3 and only started in SP4.
Unfortunately, if it is still there, then I may as well forget the upgrade testing for v7, as we cannot work with this error in place.
Can anyone confirm whether it has been fixed/patched or if there is a workaround in place?
Thanks
Craig

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

[svn] 612: Updated milestones.html to mention creation of tags/3.0.0.477 ( rather than tags/3.0.0, which has been deleted)

Revision: 612
Author: [email protected]
Date: 2008-02-21 17:34:50 -0800 (Thu, 21 Feb 2008)
Log Message:
Updated milestones.html to mention creation of tags/3.0.0.477 (rather than tags/3.0.0, which has been deleted)
Modified Paths:
flex/sdk/milestones.html

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

Easyloader help

does anyone know Easyloader and how to upload a Oracle 8i Spatial table from a Mapinfo table ?
I tried to upload a table in Oracle8i Spatial starting from a Mapinfo table.
The question is : how the oracle table should be created to match the Mapinfo table ?
Could anyone forward me a Mapinfo table and the related oracle table to be used with Easyloader ?
Thanks
Cheers
Giovanni

Here are some issues I run in too sometimes
when I use Easyloader. I will also discuss
some workarounds. MapInfo does know about these issues and will have a new version of Easyloader that fixes them very soon.
Sometimes Easyloader uploads polygons that
generate the following error when you call mdsys.sdo_geom.validate_geometry.
ORA-13050 unable to construct spatial object
You must correct the 13050 geometries.
The problem occurs because Easyloader is not orienting the polygons correctly (i.e Outer rings counterclockwise and inner rings clockwise).
MapInfo is aware of the problem, and will
have a fix available very soon in a future
release of Easyloader.
Until then, for polygon layers, you can create a shortcut to easyloader.exe and
add a /v to the shortcut.
i.e. easyloader.exe /v
If you run the shortcut, it will upload data
into the Oracle 8.1.6 database, but in the
8.1.5 data format (single digit gtype and element type).
You can then use the Oracle Spatial migration utility SDO_MIGRATE.FROM_815_TO_81x to
correct the rotation of the polygon layer.
Another problem I have encountered with
MapInfo Easyloader is the tollerance
value is not always set small enough.
This may cause validate geometry to
produce the following Oracle errors:
ORA-13349 polygon boundary crosses itself
ORA-13356 adjacent points in a geometry are redundant
The workaround is after you upload your
data, you may have to make your tolerance values smaller in USER_SDO_GEOM_METADATA.
i.e. By default, Easyloader is setting
tolerance to .000005
change the tolerance to something
smaller .00000005
Mapinfo knows about the problem and will address this issue in a future version of Easyloader.
Also, I don't recommend creating the spatial index through Easyloader, or any other data
loading utility.
It is best to use the Spatial Index Advisor to tune and create your spatial indexes.
In Oracle 8.1.6, Oracle recommends a fixed index. The Spatial Index Advisor only allows you to do analysis for a hybrid index. In the performance white paper on OTN, it discusses how to workaround this, and create a fixed index with the advisor.
In Oracle 8.1.7, the spatial index advisor will allow you to tune for a fixed index directly.
Hope this helps. Thanks.
Dan

Oracle 11g, SRID & 3D-geometry

Hi
I migrated a spatial table from an Oracle 10 to an Oracle 11 database
The table contains Multilines with M-values.
I validate the Geometries with "SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT"
In Oracle 10: No Errors.
In Oracle 11g: ORA-54668: 2D SRID cannot be used with a 3D geometry
    Cause: A 2D SRID was used with a 3D geometry.
    Action: Replace the 2D SRID with an appropriate 3D SRID
SRID is 82027 (In the spatial-Metadata-Table and in each SDO-Geometry-Object)
82027 means "GK Zone 3 (DHDN)". It is an projected cartesian system.
What to do?
-> I dont't find any appropriate 3D-System
-> I don't want Oracle to use the M-values for any puproses at all.
    To me it would be fine, if oracle-saptial ignores the M-Value for it's internal calculations (index, length,...)
    M-Values are only interpreted by the appliaction.
Any advise?
Bye, Benedikt

Hi Benedikt,
What is the SDO_GTYPE on your geometries? I am betting that perhaps the second byte on the GTYPE is zero (e.g. 3006) rather than the proper 3 (3306)? I am thinking also that this data may have originated from ArcSDE? ArcSDE has an ancient bug that loads all LRS data with just the zero rather than specifying which dimension has the LRS value. So Oracle Spatial sees 3006 and thinks you have X,Y and Z rather than X,Y and M and thus 11g polices things more thoroughly to make sure your SRID supports 3D actions.
Note that ArcSDE is due to fix this bug (NIM045781) - hmm. Wait a second I THOUGHT they were due to fix this bug in 9.3.1 SP2 but now I see no mention of it! :_|
http://downloads2.esri.com/support/documentation/ao_/9.3.1_SP2_Announcement.pdf
Oh well. So you need to update your SDO_GTYPE by hand using something like:
(table is foo and geometry column is shape)
UPDATE foo a
set a.shape.SDO_GTYPE = TO_NUMBER('33' || SUBSTR(a.shape.SDO_GTYPE,3,2));Hope that helps.
Hope that's the issue.
Cheers,
Paul

VALIDATE GEOMETRY

Similar Messages

Maybe you are looking for