When we refer to Business Objects or Spatial Business Objects we refer to the technical concept that data from different feature sources can be combined into new objects within Spatial Workshop. The user has a transparent view of the data he is interested in and does not need to worry about where the data of Spatial Business Object comes from.
With Spatial Workshop Express you can access a wide range of popular data sources, like, ESRI Arc Shape, Microsoft Excel, Microsoft Access, ECW, Google KML, OGC WMS, MrSid and other raster files, etc.
For access to corporate databases like Oracle, Oracle Spatial you will need to by one of the other Spatial Workshop Suites.
For access to the Smallworld VMDS database you need to buy a license. All other adapters come for free with the product.
Multi Maps allow you to create relations between Business Objects in Spatial Workshop and related maps or drawings. You can use Multi Maps in many different ways:
- You can link maps, pictures, drawings, schematics, floor plans, schematics etc. to any data you have available within Spatial Workshop,
- You can link documents to objects, like manuals or technical drawings to equipment, legal documents to spatial infrastructures, detailed drawings of assets, schematics of networks, etc.
- You can build a hierarchy of related maps, through which a user can browse simply by clicking graphical tags,
- Multi Maps also incorporate Smallworld internal worlds.
Yes. Spatial Workshop allows you to export data to popular formats, like Arc Shape, Google MKL and Microsoft Excel. Please ask us for the latest export formats.
Spatial Workshop allows you to access data in a range of feature sources, to combine and reshape this information as you need it.
This means that Spatial Workshop allows you also to translate (import, export) data between different systems very dynamically.
In this way you can i.e. very quickly take data from Oracle, Oracle Spatial, combine and remodel it and export it to Arc Shape or publish it on the Internet via Google Earth.
- You have direct access to data in the Smallworld Versions Managed Data Store (VMDS). Any changes in the Smallworld VMDS will be reflected immediately in Spatial Workshop. No difficult and time consuming Extract, Transfer and Load process is required,
- You can select data from different versions/alternatives in Smallworld VMDS
- When you create a Spatial Workshop project the ACE information like styles, view scales, scale ranges and visibility settings can be imported from Smallworld,
- Multiple Smallworld databases can be accessed from one Spatial Workshop project,
- You can define relations between Smallworld data, files, maps, pictures, schematics, etc.
- Mapped geometry/ multiple geometries can be used within Spatial Workshop,
- Spatial Workshop supports the Smallworld internal world features via the Multi Map mechanism,
- You can add new, derived information, alphanumeric and geometric, to the data available within Smallworld VMDS,
- Topology is not supported at the moment,
- Internal Smallworld raster files are not supported at the moment.
With Spatial Workshop you can access both alphanumeric and spatial information within the Oracle database. Spatial Workshop supports a range of specific features, like:
- Direct and native access to Oracle Spatial data types. No extract, transfer and load of data is required. Changes in the Oracle database are immediately reflected within Spatial Workshop. No adjustments or additions to the standard Oracle Spatial data model are required to access it with Spatial Workshop,
- Basic support of Oracle Workspace Manager is incorporated in Spatial Workshop. We can make this functionality available to customers on request,
- Within Spatial Workshop you can use and extend the styling information available within Oracle,
- You can combine data in Oracle / Oracle Spatial with data from other sources, like Arc Shape, Smallworld, Microsoft Excel, Microsoft Word, Google, KML, OGC WMS services, etc,
- You can add new, derived information to Oracle data.
No. Spatial Workshop uses an advanced geometry model, which allows you to incorporate complex geometrical structures from the data sources that you may use into Spatial Workshop. Spatial Workshop supports geometric structures like holes in holes, multi lines, multi polygons, etc.
When exporting a Collection with multiple geometry fields only the first geometry field of the collection will be exported.
There are known issues with MDAC 2.8 SP1 on Windows XP SP2 machines.
See for example: http://support.microsoft.com/?kbid=899861.
This states:
This issue occurs because Windows XP Service Pack 2 (SP2) installs MDAC 2.8 Service Pack 1 (SP1). MDAC 2.8 with SP1 updates MDAC to version 2.81. You cannot install MDAC 2.8 if the computer is already running MDAC 2.81.
Fix:
Goto your Windows\inf-directory. Then find file mdac.inf, right click it and select install. Follow the instructions further to repair the installation
Spatial Workshop 2010 V2 requires the .NET Framework V3.5 SP1 to be available. If upon installation, this version is not available, it will automatically be installed.
On some systems we’ve noticed that password encryption/decryption does not work. This seems to be an authorization issue on those systems. In most cases this can be fixed by running Spatial Workshop once with elevated permissions and then opening a project with encrypted (Oracle or Sql Server 2008) passwords in it. After that the application can be started without elevated permissions.
From the Application Button select Options.
Select Resources panel and About box.
On the About Box select Install License…
Select the license file and press OK.
This is an indicator that the installed Oracle Client version is pre Oracle 9.2 which doesn’t support some modes which are required by Spatial Workshop (e.g. client side query cache, Oracle Objects support).
A Geometry field in a View will always be tagged with a MultiPolygon, MultiCurve or MultiPoint geometry type, despite the fact that the field on the underlying Table is tagged with ‘layer_gtype=point’ on the spatial index. This is due to the way how Oracle stores the information and Spatial Workshop discovery of geometry type will only take place on the first ‘n’ records of a collection.
USER_SDO_GEOM_METADATA contains information for every geometry field (SRID and maximum bounds). The information is used by Spatial Workshop and should therefore be duplicated for every View.
Yes, since Spatial Workshop 2010 V2, Operating System authentication is supported. To use OS authentication provide a single slash (e.g. ‘/’) in the Username field of the Oracle Feature Source.
Check the location (directory) of Spatial Workshop. Oracle applications in general have issue’s with certain characters in the full path name of the application. The error will occur if Spatial Workshop is installed in:
C:\<programfiles>\Spatial Workshop 2010 V1(3)
There are 2 solutions to the issue:
1) Install Spatial Workshop in a location not containing characters like (, ), +, -, etc.
2) Use a version of the Oracle Software that contains a fix for bug 3807408.
Currently the following patches have been released on Windows:
Windows 32-bit:
9.2.0.7.0 Patch 6: Apply Patch 4928723 or later
10.2.0.1.0 Patch 4: Apply Patch 4923768 or later
10.2.0.2.0 Patch 5: Apply Patch 5383042 or later
10.2.0.3.0: Apply Patch 5337014 or later
When using Vista or Windows 7 in 64 bit mode where Oracle 64 bit Server is installed, make sure there is an installation of Oracle x86 client on the machine. Oracle x86 client can be downloaded from Oracle.
Also make sure that a tnsnames.ora exists either in the Spatial Workshop installation folder or in the Oracle x86 client folder under <client_x86>\network\admin\tnsnames.ora
No, when a geometry column does have a spatial index, Spatial Workshop will use it (e.g. use SDO_FILTER in it’s where clause). When there is no spatial index it will use a full table scan unless there is any other predicate or filter on the table.
Spatial Workshop uses USER_SDO_GEOM_METADATA to determine the SRID (Spatial Reference ID) of the geometry column. If no USER_SDO_GEOM_METADATA exists the first record containing a geometry with a valid SRID will be used to set the Coordinate System for the geoemtry column.
Depending on the settings of the Oracle feature source, Spatial Workshop will determine the geometry type or leave it as is. Spatial Workshop always starts by looking into the ALL_SDO_INDEX_METADATA table to determine the layer_gtype of the geometry column. Of no record exists, depending on the mode:
• Infer Spatial type, a record from the table will be used to determine the geometry type. If there is no data, the geometry will be tagged as AnyGeometry and hence be unusable in Spatial Workshop.
• Create Logical geometry fields, Spatial Workshop will not determine the geometry type based on the contents of the table; it will create 3 logical fields instead.
• Leave as is, the geometry will be tagged as AnyGeometry and hence be unusable in Spatial Workshop.
Use: SELECT SDO_VERSION() FROM DUAL;
When this raises an error, locator nor spatial is installed.
When there is no error, but an empty record is returned, locator is installed
When there is no error and a record with a version number is returned, spatial is installed.
Spatial Workshop uses a similar approach to determine if locator or spatial is installed and will generate different sql based on the result.
This is to inform you that we have found some instances of Oracle 11g Enterprise (and possibly other versions, but not Oracle 10g R2) having wrong values for SDO_UNITS_OF_MEASURE.
The bug (Oracle: 9534127) is related to Coordinate System transformation and specifially to records in table MDSYS.SDO_UNITS_OF_MEASURE
When you perform:
select unit_of_meas_name, target_uom_id, factor_b, factor_c from
mdsys.sdo_units_of_measure where uom_id = 9110;
We get a record
sexagesimal DMS 9101
which is wrong as this tells the unit system that each Parameter of 9110 is treated as radians (e.g. 9101 = radians)
Oracle 10g R2 seems to be ok on this as when you select:
select unit_of_meas_name, target_uom_id, factor_b, factor_c from
mdsys.sdo_units_of_measure where uom_id = 9110;
you get
sexagesimal DMS 9102
when you then select the next step:
select unit_of_meas_name, target_uom_id, factor_b, factor_c from
mdsys.sdo_units_of_measure where uom_id = 9102;
you get:
degree 9101 3,14159265358979 180
So that in the end conversion from 9110 to 9101 does PI/180.0 (that is on Oracle 10g R2, on Oracle 11g it does nothing!).
When will you be affected by this bug in any Spatial Eye software.
The bug will only occur when you have defined a Coordinate System in Oracle Spatial which is not available in our own EPSG database. Spatial Eye always prefers its own EPSG database for coordinate systems, but when an SRID is not found, it will check if a Coordinate System is available in the source database (in this Oracle Spatial).
Patch/fix
An Oracle fix should be available by Q2 2010, according to Oracle this should be fixed in Oracle 11.2.0.2.0.
When environment variable NLS_LANG has not been specified, Spatial Workshop will by default use:
NLS_LANG = WE8MSWIN1252
Since Sql Server 2008 does not have the ability to store meta data on a geometry column (e.g. SRID (Spatial Reference Id) or Geometry Type) Spatial Workshop will check if there happens to be a constraint on the column which checks for the SRID.
A sample contraint could be ([coverage].[STSrid]=28992), where 28992 is the actual Spatial Reference ID, which should exist as SRID in the Spatial Workshop Coordinate System Database.
When such a constraint does not exist Spatial Workshop will automatically select the first geometry from the table and determine its SRID based on the SRID of the geometry.
Since Sql Server 2008 does not have the ability to store meta data on a geometry column (e.g. SRID (Spatial Reference Id) or Geometry Type) Spatial Workshop will check if there happens to be a constraint on the column which checks for the Geometry Type.
A sample constraint could be:
([coverage].[STGeometryType]()=Polygon OR [coverage].[STGeometryType]()=MultiPolygon)
where this allows Polygon and MultiPolygon geometry types to be stored in the column.
Spatial Workshop will tag the geometry field as MultiPolygon. When such a constraint does not exist Spatial Workshop will automatically select the first geometry from the tabel and determine the Geometry Type from it.
Make sure when a SOM (Spatial Object Manager) definition in Smallworld SOC (Spatial Object Controller) uses Environment variables, make sure these can be resolved in Spatial Workshop.
Check the Smallworld Vmds Feature Sources if the Main Gis World is tagged with a proper Coordinate System. You can check this by hovering the mouse above the Vmds Feature Source and checking the Balloon for information.
If not open the Smallworld Vmds Properties dialog, go to the Options Tab and select a Default Coordinate System for your data source.
No, currently it is not possible to specify a different port number for communication with Swmfs.
Using the Add Feature Source Wizard the location of the Ace database is used to replace any %SW_SESSION_ACE_DB_DIR% found in a searchpath for a dataset.
However, when saving the Spatial Workshop project, the environment variable is replaced by its actual location (the ace.ds database is only used to configure your project).
The location for the Ace database, as set in the Add Feature Source Wizard, will be used to create the %SW_SESSION_ACE_DB_DIR% environment variable for your current session only.
Spatial Workshop does support the SimpleArea geometry type from Smallworld. Spatial Workshop 2008 V2.1 introduced the support for Simple Areas with holes as well.
Yes, since the introduction of Spatial Workshop 2010 V1 there is support for Extensible Enumerators.
Yes , using the Add Feature Source Wizard, there is a possibility to import Visibilities and Display Scale definitions from the Ace as well as importing Style Definitions from the Style Database.
Custom Draw Methods, which generally have been written in Magik, can not be imported into Spatial Workshop. However, Spatial Workshop offers rich functionality for defining styles based on Attribute Lookup or Sliced values.
This is a known initialization problem when one or more of your Smallworld Feature Source doesn’t have the geographic world (e.g. world(0,0)) tagged in the Smallworld database, but the Feature Source in Spatial Workshop has been tagged. The problem lies in the order in which Feature Sources are opened.
Workaround: Re-opening the same project file again, should render your data.
Yes, Spatial Workshop does support connecting to a persistent cache datastore. When accessing a Smallworld database, which happens to be a persistent cache database it is sufficient to set the path to the persistent cache database. The persistent cache database itself contains enough information to determine the location of the master database. At this release there is no support for cascased persistent cache, e.g. a persistent cache datastore which references a persistent cache datastore which references the master database. At this release only read access to the persistent cache datastore is supported.
Yes, Spatial Workshop does support UVAs, although not all situation are fully supported.
1) Database has been upgraded for 64 bit UVAs, but there are still customer 32 bit UVAs.
There is no issue in this situation, it was and still is full supported.
2) Database has not been upgraded for 64 bit UVAs, but customer has created one or more 64 bit UVAs
This situation is supported as of version 2010.2.3 of Spatial Workshop.
3) Partly upgraded database for 64 bit UVAs
a. If for instance the dd model has been upgraded for 64 bit UVAs, but some of the tables in rwo.ds have not. This situation is not supported and will not be supported in the near future.
b. If for instance only gdb.ds has been upgraded for 64 bit UVas, but dd.ds and rwo.ds have not. This situation is supported as of version 2010.2.3 of Spatial Workshop.
If however a raster.ds is in place as well, that needs to be upgraded to 64 bit UVAs too.
Spatial Workshop is able to use Smallworld superfiles via the Smallworld Master File Server (swmfs) process. When databases are copied to a local disk you must ensure the presence of the swmfs process.
When a project is created from the settings of a Smallworld Ace & Style database, the order of rendering the geometries is different. The ordering of rendering in Smallworld is always based on Area, Line, Point and Text. While in Spatial Workshop the order of rendering is the order in the Theme Tree (from bottom to top). Also note that any Drawing priorities in the Smallworld Ace will not be included in the Spatial Workshop Theme Tree.
Solution is to re-order the Themes/Geometries in the Map Definitions Theme Tree.