[Geotools-devel] [proposal] feature transformer

[James M. <j.m...@ge...>]

Hi all.

In many ways this follows on from my previous post, but it also touches on 
some other fundamental issues.

At the moment we define our schemas to match a given data set (in fact, in 
most cases the schema is generated automatically by the datasource), but 
what if we have a schema and our datasource does not match it?

For example, we may have a roads schema that specifies a center-line, 
footprint, class (motorway, major or minor road) and a name.

We have an SLD document for that schema and a load of application logic to 
work with it.  Now lets assume we have a Shapefile of roads which has the 
following schema:
genericline, rd_name, date_built

Now, how do we use that file with our road.sld and application 
logic?  Clearly the  'genericline' can be mapped to the 'centerline' and 
'rd_name' can be mapped to 'name', 'date_built' can just be 
ignored.  However, we are missing a footprint and we are missing a class.

Lets assume (as is the case in the uk) that rd_name can take the form M61, 
A492, B6148 where M denots a motorway, A a major road and B a minor 
road.  Using a LikeFilter we could say:

<PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
     <PropertyName>rd_name</PropertyName>
     <Literal>M*</Literal>
   </PropertyIsLike>

And it would pass for everything that was a Motorway, similar filters could 
be writen to pull out all A roads and B roads.

We could also come up with a crude approximation for a footprint using:
<Buffer>
   <PropertyName>genericline</PropertyName>
    <Literal>5</Literal>
  <Buffer>


The above would help us fill in the blanks, but how do we actually specify 
the process?  I propose an xml conversion script something like the following:

<NewProperty>
    <Name></Name><Type></Type>
    <Rule>
       <Filter/>
       <Expression/>
    <Rule/>
    ...
    <Rule>
       <Filter/>
       <Expression/>
    <Rule/>
</NewProperty>

So, a conversion script for the example I gave above would look like:

<NewProperty>
   <Name>center-line</Name><Type>Geometry</Type>
    <Rule>
        <PropertyName>genericline</PropertyName>
     </Rule>
  </NewProperty>
<NewProperty>
    <Name>footprint</name><type>geometry</type>
    <rule>
      <filter>
         <PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
             <PropertyName>rd_name</PropertyName>
             <Literal>M*</Literal>
            </PropertyIsLike>
      </filter>
         <Buffer>
           <PropertyName>genericline</PropertyName><Literal>5</Literal>
          </Buffer>
      </rule>
      <rule>
           <elsefilter/>
              <Buffer>
           <PropertyName>genericline</PropertyName><Literal>2</Literal>
          </Buffer>
      </rule>
</NewProperty>
    <Name>class</name><Type>String</type>
    <rule>
      <filter>
         <PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
             <PropertyName>rd_name</PropertyName>
             <Literal>M*</Literal>
            </PropertyIsLike>
      </filter>
         <Literal>motorway</literal>
      </rule>
      <rule>
      <filter>
         <PropertyIsLike wildCard="*" singleChar="#" escapeChar="!">
             <PropertyName>rd_name</PropertyName>
             <Literal>A*</Literal>
            </PropertyIsLike>
      </filter>
         <Literal>major</literal>
      </rule>
      <rule>
          <elsefilter/>
         <Literal>minor</literal>
      </rule>
</NewProperty>
<NewProperty>
  <Name>name</name><type>string</type>
   <propertyname>rd_name</propertyname>
</NewProperty>

whew....  and that should just about do it.  Note that the width of the 
derived footprint is determined by the road type and that elsefilters can 
be used to catch all remaining cases were necessary.

The resulting FeatureCollection could then be used for display or even 
output in another format, say GML for example...

I hope all of that made sense, and appologies for the crudly formated, hand 
written, xml chunks that are probably not valid.  I should learn how to 
write XSD's by hand as they would be a far more compact way of saying what 
I have written above.

I think we are very close to being able to implement what I have proposed 
in this email provided people think its the right way to do this.

All the best

James


-- 
James Macgill
Center for Computational Geography http://www.ccg.leeds.ac.uk
Spell Checker (c) Creative Spelling inc (aka my dyslexic brain)
http://www.geotools.org a client side java mapping toolkit.