On September 23rd 2011, we have released Spatial Workshop 2010 V3.4.
For a complete description of the changes in this release, see the WhatsNew2010V3.4 document.
Frank Pistorius
Spatial Workshop 2010 V3.4 Released
Spatial Workshop 2010 V3.1 Released
On March 3rd 2011, we have released Spatial Workshop 2010 V3.1. This release is primarily a patch release, with very little functional changes.
For a complete description of the changes in this release, see the WhatsNew2010V3.1 document.
Patrick van Dijk
Spatial Workshop – Business Collections using Geometry from Lookups
When setting up a business collection, it is possible to use geometry from lookups as well as aggregate lookups. Below is a situation where a Province business collection is defined using a Province source collection with an aggregate lookup to a Station collection. The two source collections are joined using a geometric relationship, in this case joining all stations that interact with the province.
The resulting geometry of the Province business collection is built up from the gathered locations of all related stations.
The resulting geometry of the Province business collection is built up from the gathered locations of all related stations.
Province business collection
Browsing this Province collection results in the next output. Each province will have a geometry that is a MultiPoint that has been built up by gathering all locations of the stations that belong to that province.
Result List
After having set up a simple style for the geometry,
Simple style
rendering will produce the following Map. All provinces are drawn using the geometry from the stations interacting with those provinces.
Rendering using simple style
Both source collections that built up the business collection, provincie and station, come from the same Oracle database. This is done deliberately for this example, since all logic for retrieving source information can be seen in one Sql statement. The Sql generated for this particular rendering action, is similar to the Sql shown below (all dependent on database):
SELECT T1.geom FROM (SELECT * FROM citygis.station WHERE SDO_FILTER(geom, :param1, 'querytype=window') = 'TRUE') T1 INNER JOIN citygis.provincie T2 ON SDO_RELATE(T2.geom, T1.geom, 'MASK=ANYINTERACT') = 'TRUE'
Given the fact that, at first glance, we only need the stations to render, this looks like a too complex request. Even though rendering the station geometry itself doesn’t require the province that a geometry belongs to (e.g. there is no style dependent on it), the generated Sql still includes the relation as was set up between the two collections.
The reason for this is simple: we actually are rendering provinces (business objects) by means of the stations inside provinces. This means that only those stations that actually belong to such a province are allowed to be rendered . If the province join/restriction wasn’t generated as part of the query, even stations that are not within a province would be rendered. This would be wrong given the definition of the Business Collection.
But, what if we know that every Station element always belongs to a Province?
There are situations that we know that every lookup record actually belongs to a record in the main collection of the business collection. If we could provide this extra knowledge, the system could ease the request to the database, allowing for improved performance. This information can be specified in the Station’s table properties.
Meta data
After having provided this extra information, the system now knows that the extra check (only those stations relating to a province) can be omitted. The generated Sql will reflect this, improving performance upon rendering:
SELECT T1.geom FROM citygis.station T1 WHERE SDO_FILTER(T1.geom, :param1, 'querytype=window') = 'TRUE')
This is a query that is easier to solve for the target database, since there is no necessity to check whether each station actually interacts with a province.
What if we are drawing using a style dependent on Province attributes?
In case the rendering style is dependent on an attribute of the main collection (or any other collection the business collection is built up from), the situation of course could change back to the previous one. So, let’s create a style that is dependent on the name of the province that we are rendering. This can be achieved via the Style Designer, as shown below.
Lookup style
Rendering using the attribute dependent style, will produce a nice map colored by province.
Rendering using lookup style
Every province is rendered using the locations from the stations that interact with it, colored using the indicated look-up. In this case, the style needs to be determined for each station to be rendered. This is reflected in the generated Sql, that might look similar to below (again, all dependent on the target database):
SELECT T1.geom, T2.provincie FROM (SELECT * FROM citygis.station WHERE SDO_FILTER(geom, :param1, 'querytype=window') = 'TRUE') T1 INNER JOIN citygis.provincie T2 ON SDO_RELATE(T2.geom, T1.geom, 'MASK=ANYINTERACT') = 'TRUE'
In this case the extra information provided in the meta data is neglected and this of course reduces performance again to be similar to the first situation. A mix is of course possible, allowing to use attribute dependent styles at large scales and plain styles at small scales.
So, in case you are setting up a business collection that has a geometry field built up using fields from lookup or aggregate lookup collections, check whether these settings apply to your sitation; in cases it does, rendering performance can be improved.
Cheers,
Frank Pistorius
Spatial Workshop 2010 V3 Released
On December 9th, we have released Spatial Workshop 2010 V3, which contains a lot of new and exciting features. Some of the new features are:
- New feature sources: AutoCAD DWG, ESRI ArcPersonal GeoDatabase and ESRI ArcSDE
- Oracle feature source now supports (source level) joins
- VMDS feature source improved client side caching
- WMS feature source now supports authentication
- Support for compound expressions in the expression language as well as new expression functions (see Changes to Expressions)
- Data modelling enhancements, supporting easier creation of fields from source collections
- Business Collection Interfaces, supporting loosely coupled entity models to be set up (Business Edition only)
- Export to Oracle (Business Edition only)
For a complete description of the new features as well as other changes in this release, see the WhatsNew2010V3.0 document.
Patrick van Dijk
Spatial Workshop 2010 V3 – Changes to Expressions
Since their introduction in the 2010 V1 release, expressions have been an important part of Spatial Workshop. They are the mechanism to query the collections and – more importantly – are the building blocks that allows a business model to be expressed in terms of underlying source models. Since the introduction of the expressions, the supported set of functions has been increased with each version of Spatial Workshop.
In Spatial Workshop 2010 V3 some more features have been introduced to the language. Compound expressions are now allowed that allow breaking up expressions in logical parts using variables and yield a resulting value using return expressions. Besides this change to the expression language itself, some new functions and methods have been introduced as well. In this post, compound expressions and some of the new functions will be shown.
Compound Expressions
In cases where constructing a single expression is tedious because of recurring logic, compound expressions can be of use. Using stepwise construction of your logic using variables and a final return statement that assigns the result to the compound expression, the construction of this value can be made easier to understand.
A simple expression
Name = "Amsterdam" OR Name.ToLower().StartsWith("b")
Building it up using a compound expression
{
var isAmsterdam = Name == "Amsterdam";
var startsWithB = Name.ToLower().StartsWith("b");
return isAmsterdam OR startsWithB;
}
Note the various parts that build up the compound expression.
- the brackets identifying the statement as compound
- the variables
- the return statement that must be the last statement in the compound expression
Upon evaluation, the compound expression will be resolved completely; in this case it will internally end up in the exact same format as if you had written the simple variant. Though a very basic example, it illustrates the fact that it now is possible to break up your logic into smaller elements and compose the final value of the expression using those elements.
Note that compound expressions introduce no other possibilities except the introduction of one or more variables and to combine those in building up the resulting value. There is no possibility to introduce flow in the process of calculating the value of the expression.
Combine Function
The combine function introduces the possibility to combine geometry coming from different sources into one. This allows these different geometries to be treated as one logical geometry at the business object level. Consider the situation where multiple geometric fields are available at source level, but with only one of those fields filled out for each record in the source (e.g. route and underground route). Combining these fields into one logical field at the business object level offers the user a simpler model to work with.
Combine(MyMainTable.Coverage, Gather(MyAggregateTable.Coverage))
As shown here, the elements can be built up using different logic. In this case, one element is created using a set function on an aggregate source table.
- Only elements of similar type are allowed to be combined (e.g. curve and multiCurve is fine, whereas curve and point is not).
Any reference to this logical field will internally use the combination of indicated fields (better: expressions).
IfConvert Function
The expression language already contained the LookupConvert as well as RangeConvert functions that are specialised conversion functions. The IfConvert() function is the more generic variant that allows predicate based creation of lookup values.
IfConvert( City.Size < 10000, “Small”,
City.Size < 50000, “Medium”,
City.Size >= 50000, “Large”)
This converts the indicated sizes into corresponding descriptive values. The resulting type is enumerated, providing easy pick and choose behavior to the end user. This behavior could have been achieved with the RangeConvert() function as well.
Though there are more changes with respect to the expression language in Spatial Workshop 2010 V3, these are the ones that stick out the most.
Have fun using these new bits.
Frank Pistorius
Welcome
Welcome to this Blog from Spatial Eye.
In this blog we will be focusing on providing information on the products created by Spatial Eye. This will range from background information on features found in existing releases to information on upcoming releases.
So, in case you’re using one of the products from Spatial Eye, or are otherwise interested, stay tuned!
The Spatial Eye Team
Reacties uitgeschakeld
more...