I am converting a shape file to .dgn, and I am using a type attribute as a cell
name.

I am using the following:


SHAPE_DEF stations                              \
     SHAPE_GEOMETRY       shape_point            \
     TYPE                 char(16)

SHAPE stations                                  \
     TYPE                 %type

IGDS 1                                          \
     igds_type            igds_cell             \
     igds_cell_name                 %type \
    igds_cell_x_scale 410.00 \
    igds_cell_y_scale 410.00 \
   igds_cell_z_scale  410.00

Each Feature Converted gives me the following warning:

The following graphic cell feature should have had a feature type of 0 --
autocompensating

How do I stop this message?


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

The following press release may be of interest to you:

Title: FME(r) Used in GeoTask OGIS Server

Vancouver, BC - July 15, 1998 - Safe Software Inc., a leading GIS
solution provider, announced today that GeoTask AG will be using FME(r)
to provide the spatial data conversion capability for their new GeoTask
OGIS Server utilizing IBM's DB2(r) Universal Database.

"FME is an integral part of our new GeoTask Server," said Dr. Martin
Huber, president at GeoTask AG.  "We chose FME to be the primary
import and export facility for GeoTask Server because of its powerful
configurability and the bridge it provides to the varied GIS formats
and systems our customers use," he added.  "Our use of FME allowed us
to have translation capabilities available for GeoTask within days of
its official release".

"We are excited about GeoTask Server being added to the FME translation
hub", added Dale Lutz, VP Product Development at Safe Software.
"GeoTask provides another powerful spatial data repository for use with
FME in a spatial data warehouse and distribution system".

More About GeoTask Server

GeoTask Server is the first geodata server to follow the OpenGIS(r)
Simple Features Specifications for SQL/ODBC and will be submitted for
conformance testing as soon as the test suites of the OpenGIS Consortium
are up and running. GeoTask Server is integrated into IBM's DB2(r)
Universal Database, the fastest relational database engine currently
available on Windows NT.  With GeoTask Server, database application
developers get access to spatial data management in a standardized way
using SQL, ISO Call Level Interface (CLI), Open Database Connectivity
(ODBC) or the Java Database Connectivity (JDBC). And the link to FME(r)
allows creating a spatially enabled relational database schema on the
fly based on an existing GIS database.

More about FME(r)

FME(r) is spatial data translation software providing interoperability
between many GIS and database systems including Microstation, MapInfo,
AutoCAD, ESRI (ArcInfo, ArcView and SDE), Intergraph MGE and Smallworld.
FME's data processing environment enables users to perform many functions
with their data including translation, transformation, integration,
distribution, manipulation, validation, and reclamation.

About GeoTask AG

GeoTask AG was founded to concentrate research, development and
consulting activities of its founders in the domain of geographic database
management.  As well as GeoTask Server, GeoTask AG offers products and
services for data integration, terrain analysis and GIS methodology.

About Safe Software

Safe Software Inc. was incorporated in 1993 and is dedicated to providing
robust GIS interoperability solutions.  Since incorporation, the company
has successfully executed many projects in translation, processing,
modeling, and distribution of spatial data.


Public Relations Contacts:

Safe Software:
Jeff Hoedeman, P.Eng.
VP Marketing
Tel: 604-501-9985
Fax: 604-501-9965
Email: jeff@...
Web: http://www.safe.com

GeoTask AG
Dr. Martin Huber
President and C.E.O.
Tel: +41 / 79 / 667 47 38
Fax: +41 / 61 / 482 32 19
Email: mhuber@...
Web: http://www.geotask.ch


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi,

A couple of FME subscribers have asked me to announce in this list
each time a new FME beta build goes online.

If you like living on the bleeding edge and you are
an FME subscriber, you are welcome to download and use the latest
2.2 betas at any time.  The latest beta is always available at:

         ftp://ftp.safe.com/fme/fme_beta.exe

Now, please remember these are betas and so some areas of them may
occasionally be less tested than you'd expect.  If you are using
one and you do notice something is amiss, please let us know so we
can be sure to remedy it as quickly as possible.

Now, having said all that, FME 2.2 build 265 is now available
for testing and use.

The draft "what's new" for FME 2.2 is included below, but some of
the major updates in this build include:

         a) Factory's can now be "named" via the new FACTORY_NAME
            clause.  All stats, messages, etc. coming out of the
            factory are prefixed by the name.
         b) The ProximityFactory (whose name may yet change) -- this
            lets you join attributes of features who are "close" to
            each other.  Useful for data mining.
         c) ClippingFactory is quite a bit faster (but unfortunately
            a bit flakey, if you use it and crash it please let us
            know and send us the data, we are working on fixing this
            asap).
         d) SDE3 support continues to improve, see the list below
            for details.
         e) The "TilingFactory" is also new and of interest to
            people with lots of small, attribute-less features.
         f) The usual set of updates for E00 reading and writing.

Enjoy.

Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal@...
                        Surrey, BC, CANADA        phone: (604) 501-9985
                        http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------


What's New in FME 2.2?
======================

The following list enumerates the major differences between FME 2.1 and
FME 2.2:

a) New "Desktop Edition" Formats:

     o Leica IDEX reading and writing
     o PenMetrics FieldNotes GRD32
     o Tydac Spans reading/writing

b) New "Professional Edition" Systems:

     o CCOGIF Writing
     o CCOGIF Reading
     o Live Database Reading
     o GeoTask DB2

c) Existing Format Enhancements

     General
     =======
     o Several formats were enhanced to allow double-byte data to be
       translated (MapInfo TAB/MIF, Shape, GIF, DWG, DXF)

     Phocus
     =======
     o Support Ellipse entities

     Autocad
     =======
     o Handle autocad "local coordinate systems" better (affects autocad
       R14 use of arcs, etc -- guitars now translate correctly!)
     o Handle "hatch" entities
     o Many improvements on the R14 support
     o Support elliptical arcs on reading and writing

     KF85
     ====
     o Substantial improvements to KF85 reading and writing.  More record
       types are now supported.  Coordinate systems are set and read

     GDMS
     ====
     o Can do text + we will add a manual section

     SAIF
     ====
     o Coordinate systems now read and set

     MASIK
     =====
     o Enhanced handling of file extensions to be more flexible.

     Design Files
     ============
     o DMRS linkages are now supported
     o Curves can be stroked
     o 3d Arc rotations handled correctly

     NTX
     ===
     o Enhanced robustness of reading and improved output.  Added complete
       support for Z Values

     E00
     ===
     o Split lines longer than 500 verticies in separate feature to cooperate
       with Arc/Info limitations
     o ??? Polygon coverages output correctly ???

     SDE30
     =====
     o Added ability to read and write tables with no spatial columns
     o Added ability to do joins across tables when querying
     o Misc. fixes pertaining to date and required fields

     MGE
     ===
     o Added ability to handle elements tagged as being multiple "features"

e) Enhanced Processing Facilities

     o IntersectionFactory -- made more robust (again!)

     o CreationFactory -- added option to inject feature as the FINAL feature

     o MatchingFactory -- added option to output only 1 feature from each
                          matched set

     o ArcFactory -- added ability to output nodes

     o ClippingFactory -- added ability to clip to donut polygons and/or
                         aggregates of polygons AND sped up substantially

     o PolygonDissolveFactory -- computes average, sum, weighted average
        on selected fields during dissolve, tracks the features which
        were dissolved together

     o ReportFactory -- Additional directive

     o Reformat/CAT -- Additional field types

     o Split -- Additional Functionality

f) New Processing Facilities

     o OverlayFactory -- ***PROFESSIONAL ONLY*** -- does point/line/polygon
          overlays

     o WarpFactory -- ***PROFESSIONAL ONLY*** -- does rubber sheeting

     o BranchingFactory -- ***PROFESSIONAL ONLY*** -- throw loops into FME!

     o @System -- ***PROFESSIONAL ONLY*** -- call other programs from within FME

     o @File -- ***PROFESSIONAL ONLY*** -- read/write entire fields into
attributes

     o @SDESQL -- ***PROFESSIONAL ONLY*** -- executes SDE SQL commands

     o TilingFactory -- ***PROFESSIONAL ONLY*** -- tiles input features

     o ProximityFactory -- ***PROFESSIONAL ONLY*** -- finds features close
                          to other features

g) Infrastructure
     MULTI_READER
     ============
     o Can now use wildcards to easily read the contents of a whole directory

     o Factory's can all have names which are used when they log their status ...

     o FME Now can run in a server mode

h) User Interface
     o Java GUI available on non-windows platforms -- if you want to test it,
       let us know.



----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi Don,

Well, I did a bit of testing and digging, and, well, the best and most
polite way to describe the problem is to say that our current SDL reader
is, uh, seriously challenged.

We will remedy the situation this week and the next FME beta that goes
online (build 265) will have a fix.  I expect by July 17 it will be
available at:

         ftp://ftp.safe.com/fme/fme265.exe

What is the most interesting about this is that the answer to your
question:

> Has anyone encountered problems converting MapGuide SDL files to shape
> files.

would have to be yes, assuming anyone had ever tried to do this at all.
Which means that no one ever has before you, since we've never heard
of these problems before (and I can assure you they did exist).

Conclusion -- SDL reading is not too much in demand :-)

But hey, we'll fix it anyway.

Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal@...
                        Surrey, BC, CANADA        phone: (604) 501-9985
                        http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

> I have a question concerning donut polygons - can I have a donut polygon
> which consists of an outer ring, a hole, and an island in the hole?  If I
> originally have these as 3 separate polygons, can the
> DonutFactory correctly
> construct this as a single donut?

Well, this is a good question.  And really the answer hinges on your
definition of "correctly".

FME considers a "donut polygon" to be an area feature with an outer boundary
and any number of holes within it.  In particular, the area of the donut
must be contiguous.  This is how the donut factory interprets things.  So if
you send in these three polygons:

  +------------------+
  |        A         |
  |  +-----------+   |
  |  |     B     |   |
  |  |  +----+   |   |
  |  |  |  C |   |   |
  |  |  |    |   |   |
  |  |  +----+   |   |
  |  |           |   |
  |  +-----------+   |
  |                  |
  +------------------+


The donut factory will consider that B is a hole of A, and that C is a hole
of B.  If you tell the donut factory to DROP_HOLES, then you'll get this as
output:

  +------------------+
  |        A         |
  |  +-----------+   |
  |  |           |   |       and +----+
  |  |           |   |           |  C |
  |  |           |   |           |    |
  |  |           |   |           +----+
  |  |           |   |
  |  |           |   |
  |  +-----------+   |
  |                  |
  +------------------+

I suspect that what you want is an output polygon that has A and C together
in it.  This would be considered an aggregate by FME, as effectively it is
two disjoing area features living together inside a single feature.

So how can you get this to happen.  Hmm.

I don't know.  Maybe we need a new factory.  Somehow I was hoping to suggest
you could tag A and C with some number, then use the aggregate factory to
join them into a single feature.  An idea would be to perhaps use the
overlay factory, which would combine all the attributes, but it still
wouldn't give you back the aggregates you wanted.

If you knew that A and C were supposed to be the "same feature" before you
went into the donut factory, then an aggregate would do the trick.

Anyway, I'm a bit stumped as to how one would pull this off in FME with the
information given here.  Is this a major issue?  Should we make/update a
factory to solve it? Inquiring minds want to know.

Dale





----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Has anyone encountered problems converting MapGuide SDL files to shape files.
When I attempt to convert I get the following error message:

Reading Mapping File...
Feature Manipulation Engine Version 2.1 (19980301 - Build 248)
FME Configuration: Reader Keyword is `SDL'
FME Configuration: Writer Keyword is `SHAPE'
FME Configuration: Writer Group Definition Keyword is `SHAPE_DEF'
FME Configuration: Reader type is `SDL'
FME Configuration: Writer type is `SHAPE'
FME Configuration: No destination coordinate system set
FME Configuration: Current working directory is `H:\MapGuideServer\Sdf'
Using SDL Reader Version 1.1 (Sep 12, 1997) to read sdl files from directory
`H:\MapGuideServer\Sdf'
Using Shape Writer Version 2.1 (Jan. 22, 1996) to write shape files to directory
`H:\MapGuideServer\Sdf'
Opened Shape File H:\MapGuideServer\Sdf\sdl_polygon_polygon.shp for output
Opened DBF File H:\MapGuideServer\Sdf\sdl_polygon_polygon.dbf for output
The field type of field `POLYGON_ID' in DBF file
`H:\MapGuideServer\Sdf\sdl_polygon_polygon.dbf' must contain a width and
precision in the ( ) -- `number(255)' is invalid
The field type of field `POLYGON_ID' in DBF file
`H:\MapGuideServer\Sdf\sdl_polygon_polygon.dbf' must contain a width and
precision in the ( ) -- `number(255)' is invalid
Translation FAILED.

Don Desnoyers


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi all,

I have a question concerning donut polygons - can I have a donut polygon
which consists of an outer ring, a hole, and an island in the hole?  If I
originally have these as 3 separate polygons, can the DonutFactory correctly
construct this as a single donut?

(BTW Dale, I sent an e-mail concerning some other issues with DonutFactory
to support@....  Has anyone had a chance to look at this?)

Thanks

Chris Musial
cmusial@...



----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Its come up a few times that FME's @Generalize() function will
destroy polygon topology when it is run on individual polygons that
originally completely partition a space.

The issue is that the the @Generalize function works in isolation one
polygon at a time, and the nature of the generalization algorithm is such
that the results it produces depend on WHERE in the feature it starts.
The @Generalize has no way of knowing about any neighbours of the polygon
when it runs.  So what happens is that you get different points removed
on the line segments that were originally shared between adjacent polygons,
and the net result is that some of the resulting polygons may overlap
and also there will be some slivers between adjoining polygons that will
be created.

As Lenin said, "What is to be done"?.  Well, as with pretty much every
problem like this, there is a solution in FME.  But it requires a bit
of work.  Before I explain it, let me give the credit to Leslie Last
of Dotted Eyes in England for passing this along to us some time ago.

To reliably remove points from points but maintain the topology,
you must first determine the set of line pieces that partition your
space.  You generalize these things, and then afterwards reform the
polygons.  Of course, if you do nothing else you will have lost the
attributes along the way.  The solution -- generate centroids with the
attributes before you break up the polygons into their component lines,
and then connect these centroids back to their polygons after they
are reformed.

In FME speak, this roughly means that you need this factory sequence:

         1) PIPComponents factory with @GeneratePoint to make a
            feature with a centroid point for each polygon along
            with its attributes'
         2) ArcFactory with VertexNoded to take in all the polygons
            and output the set of lines (with no duplicates) that
            are needed to partition the space into the polygons.
            Pour the memory into your computer for this step if you have
            a very large dataset -- the ArcFactory likes lots of memory
            if you use it in VertexNoded.
         3) @Generalize should now be run on these component lines,
            either as they emerge from the previous factory (i.e. on
            its output clause), or as they enter the next factory (i.e.
            on its input clause)
         4) PolygonFactory with EndNoded to take in the freshly generalized
            lines and form polygons
         5) DonutFactory to take the polygons from above and nest them
            properly into donuts.  In addition, the DonutFactory will also
            take in the centroids generated in step 1.  The output from
            the donut factory will be generalized polygons with the
            attribution and topology intact.

There is an FME legend in circulation about a customer that used this
technique on a large dataset and a rather underpowered machine and left
the translation go for around 5 days.  It finished successfully.  To our
knowledge, that is the single longest FME run of all time.  Perhaps
we'll have to have a contest about this....the winner to get 128MB of
SDRAM or something...

Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal@...
                        Surrey, BC, CANADA        phone: (604) 501-9985
                        http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi All,

A friend at Bentley forwarded this response to me about
the design file attributes:

********************************************************

User data linkages on design file elements can be any
information the user wants to attach to the element.
This includes ascii text.  I guess the real issues
here are:

1. if you want to attach text string as the user
    data linkages, you still probably want to make all
    the user data links the same size regardless of the
    text string length.

2. once a user data link is attach to an element,
    to be useful you must have a method of interpreting
    (i.e. reading using MDL, Basic, etc.) the link.

********************************************************

Michael Fox also suggested using the @Reformat function that
is new to FME 2.2 in to package up the data correctly, this
could well work in conjunction with the above points.

Dale



----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi,

> I'm trying to translate a SHAPE file which hold roads with the road
> name as an attribute, to a DESIGN file, which will hold this roadname
> in a user data linkage.
>
> Is this possible ? How is it best done?

Mostly I have bad news on this one.  The design file format is not
very flexible at all when it comes to trying to store attributes
right in the design file.  The "linkages" which are available
store only binary data.  One could imagine doing something to
encode the roadname as some integers, but then when you were in
MicroStation you could only see the integers.

I believe that you might use "tags" inside of MicroStation to hold
such user defined attributes -- at the moment we do not support these
in FME and in our experience not many people out there must be using
them, at least, no one has been on our case to add this support.

So what can be done?  I know of only two options (and I'd be
interested if anyone out there knows of others).

1)  Use a "real" attribute linkage, and store the road names in an
     associated DBF file.  The DBF file would have two columns,
     MSLINK (an integer field, which is the key that joins the
     dbase linkage in the design file to the table), and the
     ROADNAME.  YOu'd have to set up your microstation environment
     correctly to hit the DBF file when you select an element,
     then you could see the roadname.  Overall, this would be a bit
     of a pain I'd think.

2)  Use FME to create a text element for each road.  Use the
     "graphic group" field to give each road line and its associated
     text element the same graphic group number (by carefully using
     @Count and Tee factories this would be easily enough done).
     If you put the text on its own level, you can easily turn off
     its display.  If you want to know the name of each road, you
     can put your "graphic group lock" on, turn on the text display,
     and then when you click on a road it will be highlighted along
     with its name.  YOu might even do something cool like make
     the text elements be black in color, then you'd never see them
     until you clicked on the road element and they'd all highlight.

Sorry, but that's about the best I can come up with....anyone else
have any good ideas?

Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal@...
                        Surrey, BC, CANADA        phone: (604) 501-9985
                        http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

I'm trying to translate a SHAPE file which hold roads with the road name as an
attribute, to a DESIGN file, which will hold this roadname in a user data
linkage.

Is this possible ? How is it best done?

Michael Fox


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi Pat,

Yes, using FME the first time can be a bit daunting.  We hope that
the tutorial and solutions guide give enough pointers to get people going,
but I think the answer to your question is not really directly covered
in those documents.

> What I'm trying to do is read in an IGDS file and output a DWG/DXF file,
> with the most straight-through translation possible of all feature types,
> except that the IGDS colors are used to determine the DWG layer. In other
> words, if I have an object on IGDS level 1 with IGDS color 99, I want that
> object output to the DXF file with it's layer attribute determined by the
> number '99', and not '1' (actually, I'd like to have the output layer
> determined by comparing '99' with a LUT).

Okay, as with most things in FME, there are a couple of approaches that
could be used to solve this problem.  If I understand correctly, you
don't really care about the IGDS level number when you are doing
the correlations from IGDS to DXF.  You only want to use the color.

Most likely your mapping file contains lines looking something like:

     IGDS 1 igds_type igds_line igds_color 99

     DXF ROADS


     IGDS 2 igds_type igds_line igds_color 98

     DXF RIVERS

From your description, however, you don't want the level # (1 for example)
to be used when the decision is made to match/not match an input pattern.
Basically, any line that's color 99 should be a ROAD.  You can use the
"wildcard" feature type to accomplish this -- the * matches anything when
it is used in place of the feature type in a correlation line:


     IGDS * igds_type igds_line igds_color 99

     DXF ROADS autocad_type autocad_line


     IGDS * igds_type igds_line igds_color 98

     DXF RIVERS autocad_type autocad_line


This should give you the results you desire.

Another way to do this is via a using FME's @Lookup or @Relate functions,
but that is a bit more advanced.  The advantage of using either of those
is that the mapping file is smaller -- basically you make a lookup
table mapping colors to layer names, then you use it rather than listing
all the possible matches as correlation lines:

    e.g.

         Lookup colorToLayerLut \
             99  ROADS          \
             98  RIVERS

         FACTORY_DEF IGDS SamplingFactory \
            SAMPLE_RATE 1                 \
            INPUT FEATURE_TYPE * layerName @Lookup(colorToLayerLut,&igds_color)

         IGDS * igds_type igds_line layerName %layer

         DXF * autocad_type autocad_line @FeatureType(%layer)

You should read the manual pages for the @Lookup and @FeatureType
to fully understand this.   With @Lookup, you might also want to set
a default mapping, so that if a color you haven't listed is encountered
FME will stay happy.  YOu do this by defining your LUT like this:

         Lookup colorToLayerLut \
             99  ROADS          \
             98  RIVERS         \
             ""  DEFAULT

Dale

----------------------------------------------------------------------
Dale Lutz              Safe Software Inc.                 dal@...
                        Surrey, BC, CANADA        phone: (604) 501-9985
                        http://www.safe.com         fax: (604) 501-9965
----------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

I'm trying to use FME for the first time, I'm having a tough time getting
past first base, and I was hoping that someone might take pity on me and
talk me through what seems like a very simple problem.

What I'm trying to do is read in an IGDS file and output a DWG/DXF file,
with the most straight-through translation possible of all feature types,
except that the IGDS colors are used to determine the DWG layer. In other
words, if I have an object on IGDS level 1 with IGDS color 99, I want that
object output to the DXF file with it's layer attribute determined by the
number '99', and not '1' (actually, I'd like to have the output layer
determined by comparing '99' with a LUT).

It seems that a transfer specification requires that the output DWG layer
match the input IGDS level. Am I right about that? Do I have to use a
Feature Factory to do this? If so, any particular one?

I must be missing something pretty basic. Any help would be appreciated.

Thanks, Pat Dunlavey


            P A T  D U NL A V E Y  C A R T O G R A P H I C S
                     Cartography and Photogrammetry
               40 Oblong Road, Williamstown, MA 01267 USA
                 Phone: 413-458-9273; Fax: 413-458-9812
                     <mailto:pdcarto@...>
                   <http://www.berkshire.net/~pdcarto>



----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

A question that has come up a few times is this:

    "How do I prompt a user for a min/max corner point, and then
    clip my input data to it?"

FME 2.2 beta has a "CreationFactory" that, when combined with the
ClippingFactory, makes this relatively straight forward.

In the example below, assume that the _MINX, _MINY, _MAXX, and _MAXY
macros have been defined already, either on the FME's command line or
via the use of GUI statements (see section 25 of the FME users/solutions
guide for a walkthrough of setting macros based on user input).

The CreationFactory is used to build a feature from this input, which is
the passed to the ClippingFactory.  Taken together, these factories
end up clipping all the data to the range specified by the user.

     FACTORY_DEF * CreationFactory     \
         2D_GEOMETRY $(_MINX) $(_MINY) \
                     $(_MINX) $(_MAXY) \
                     $(_MAXX) $(_MAXY) \
                     $(_MAXX) $(_MINY) \
                     $(_MINX) $(_MINY) \
         OUTPUT FEATURE_TYPE input_data_clipper  @Log(clipper)

     FACTORY_DEF * ClippingFactory                     \
         INPUT CLIPPEE FEATURE_TYPE *                  \
         INPUT CLIPPER FEATURE_TYPE input_data_clipper \
         OUTPUT CLIPPED_INSIDE  FEATURE_TYPE *         \
         OUTPUT INSIDE          FEATURE_TYPE *

The @Log in this example is unnecessary, but can be useful to see the
clipping feature just to make sure things are working as you'd expect.

Note that if any coordinate system conversions, scalings or rotations
are to be done in the mapping file, care must be taken to ensure that
the creation/clipping factories are done in the spot where the feature
coordinates are in the same units as the _MIN/_MAX{X,Y} macros.

Thanks to Minoo Mehrayin for passing this along to me.

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

So when can we (Oracle) push your stuff?

==============================================================================

Michael J. Fisher 			     	    Oracle Corporation
Director, Spatial Products/Data Server Division 	      One
Oracle Drive
603 897-3268 Office 			   Nashua, New Hampshire 03062
603 345-4710 Mobile 	        	 mjfisher@...
==============================================================================

Oracle employees should refer to  http://aria.us.oracle.com/~sis/  for
current
information  regarding the Spatial Cartridge and  all  other  related
matters

Customers  and  partner  refer to
http://www.oracle.com/st/cartridges/spatial

Okay, this is preaching to the converted again I know, but in case you
have any doubts, check out:

         http://www.gisworld.com/print/gw/0698/698sdata.htm

There you'll find the online version of a review of Spatial Data Translators
in the current (June) GIS World magazine.   Anyone want to guess which
one comes out on top?

This is what we live for....

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

This well commented example shows how below "pseudo-SQL" statement:

       SELECT index25.shape,specmap.*
       FROM index25, specmap
       WHERE specmap.map25name = index25.SHEET_NAME;

can be handled using FME's ReferenceFactory and multi-reader.
The example is well commented, and should be a useful template for anyone
wanting to use either the MULTI_READER or ReferenceFactory for this
kind of thing.

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


# This mapping file takes a DBF file (specmap.dbf) and a
# shape file (index25.*), and implements this "SQL" statement:

#      SELECT index25.shape,specmap.*
#      FROM index25, specmap
#      WHERE specmap.map25name = index25.SHEET_NAME;

# Now, isn't that nice syntax.  The mapping file isn't quite so
# elegant I'm afraid.

# So only the geometry is carried over from index25, and copied onto each
# row in specmap that has a matching sheet name.
# The results are output to the "joined" shape file, which ends up
# having all the attributes from the specmap table and the geometry,
# copied accordingly, from the index25 table.

# This is done using the FME's MULTI_READER to read in data from two
# different sources, SHAPE and DBF, and then the FME's "reference factory"
# is used to make the join between them and copy across the geometry from
# index25 to specmap. The attributes from "index25" could also be copied
# over, but this would require another reference factory.

# Finally, an FME "DissolveFactory" could be used to merge the specmap
# polygons if there were some attribute on these that should be used as
# the dissolve key.

# ============================================================================
# Setup the multi-reader -- one shape file and one DBF file

READER_TYPE MULTI_READER

# First the shape file

MULTI_READER_TYPE{0} SHAPE
MULTI_READER_KEYWORD{0} SHAPE_IN

# Assumes that the input files are in the same directory as this mapping file

SHAPE_IN_DATASET "$(FME_CF_DIR)"

SHAPE_IN_DEF index25                   \
     SHAPE_GEOMETRY       shape_polygon \
     AREA                 number(15,3)  \
     PERIMETER            number(15,3)  \
     INDEX_               number(11,0)  \
     INDEX_ID             number(11,0)  \
     TILE_NAME            char(32)      \
     LOCATION             char(128)     \
     SHEET_NAME           char(25)      \
     ADMIN_BOUN           char(1)       \
     SLOPE_CLAS           char(1)       \
     MANAGEMENT           char(1)       \
     X_COORD              number(15,3)  \
     Y_COORD              number(15,3)  \
     BOXES                char(1)       \
     ANMPITYPE            char(1)       \
     AFBSLOPE             char(1)       \
     MDC                  char(1)       \
     DEVSLOPE             char(1)       \
     PROVCOUPE            char(1)       \
     CONTOUR              char(1)       \
     DRAINAGE             char(1)       \
     SOILS                char(1)       \
     ANMDRAIN             char(1)       \
     PITYPE94             char(1)       \
     PITYPE96             char(1)       \
     NEWPHOTOG            char(4)       \
     PICHANGES9           char(1)       \
     PITYPE97             char(1)       \
     ROAD                 char(1)       \
     FTLAND               char(1)       \
     TEMPDRAIN            char(1)       \
     CR                   char(1)       \
     NUMBER               number(4,0)   \
     ABB_NAME             char(7)

# And the DBF File

MULTI_READER_TYPE{1} TABLE
MULTI_READER_KEYWORD{1} TABLE_IN
TABLE_IN_DATASET "$(FME_CF_DIR)"

TABLE_IN_DEF specmap DBF specmap.dbf \
     COMMNAME             char(70)    \
     SCINAME              char(70)    \
     MAP100NAME           char(25)    \
     MAP25NAME            char(25)    \
     DISTRICT             char(25)    \
     TENURE               char(25)    \
     GRIDREF              char(7)     \
     LOCATION             char(100)   \
     SITEID               char(25)    \
     OBSDATE              char(10)    \
     SOURCE               char(254)   \
     NOTES                char(50)    \
     SPECIESID            char(12)

# ============================================================================
# Now we've set up our reading, lets use the reference factory to do the
# join for us.  The "referencer" features are the "specmap" ones -- each
# of these should be pointing to a "referencee" feature, the "index25" ones.
# We tell the reference factory we want to transfer across the geometry
# from the index25 into the specmap.  When we leave the factory, we log
# any specmap features that did not have a match in the index25 file -- these
# will end up being output with a shape geometry type of "NONE" when they go
# to the "joined" output file since they will have no geometry.
# Effectively, this is what implements the SQL statement we show at the top
# of the file
# Also note that we don't bother to output any of the "referencees", as we
# don't care about them after this factory (they are not output).
# We use @Count to give us a nice report in the logfile of all the map25 names
# that end up not being found in the index25 file.

FACTORY_DEF * ReferenceFactory           \
    INPUT REFERENCER FEATURE_TYPE specmap \
    INPUT REFERENCEE FEATURE_TYPE index25 \
    REFERENCER_FIELDS MAP25NAME           \
    REFERENCEE_FIELDS SHEET_NAME          \
    REFERENCE_INFO GEOMETRY               \
    OUTPUT COMPLETE FEATURE_TYPE *        \
    OUTPUT INCOMPLETE FEATURE_TYPE * @Count("MAP25NAME `&MAP25NAME' not found in
index25 file") \
               @Log("No geometry found for this specmap entry")


# ============================================================================
# Now create an output shape file feature from the results of the reference
# factory with this transfer specification.

MULTI_READER specmap                 \
     COMMNAME             %commname   \
     SCINAME              %sciname    \
     MAP100NAME           %map100name \
     MAP25NAME            %map25name  \
     DISTRICT             %district   \
     TENURE               %tenure     \
     GRIDREF              %gridref    \
     LOCATION             %location   \
     SITEID               %siteid     \
     OBSDATE              %obsdate    \
     SOURCE               %source     \
     NOTES                %notes      \
     SPECIESID            %speciesid

SHAPE_OUT joined                     \
     COMMNAME             %commname   \
     SCINAME              %sciname    \
     MAP100NAME           %map100name \
     MAP25NAME            %map25name  \
     DISTRICT             %district   \
     TENURE               %tenure     \
     GRIDREF              %gridref    \
     LOCATION             %location   \
     SITEID               %siteid     \
     OBSDATE              %obsdate    \
     SOURCE               %source     \
     NOTES                %notes      \
     SPECIESID            %speciesid

# ============================================================================
# Lastly define the output format and file -- notice that we just keep the
# attributes from the "specmap" file.

WRITER_TYPE SHAPE
WRITER_KEYWORD SHAPE_OUT

SHAPE_OUT_DATASET "$(FME_CF_DIR)/out"

SHAPE_OUT_DEF joined                   \
     SHAPE_GEOMETRY       shape_polygon \
     COMMNAME             char(70)      \
     SCINAME              char(70)      \
     MAP100NAME           char(25)      \
     MAP25NAME            char(25)      \
     DISTRICT             char(25)      \
     TENURE               char(25)      \
     GRIDREF              char(7)       \
     LOCATION             char(100)     \
     SITEID               char(25)      \
     OBSDATE              char(10)      \
     SOURCE               char(254)     \
     NOTES                char(50)      \
     SPECIESID            char(12)



----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Okay, this is preaching to the converted again I know, but in case you
have any doubts, check out:

         http://www.gisworld.com/print/gw/0698/698sdata.htm

There you'll find the online version of a review of Spatial Data Translators
in the current (June) GIS World magazine.   Anyone want to guess which
one comes out on top?

This is what we live for....

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi Ward,

Congratulations!  You found a problem that was in the in the FME 2.1
release and slipped through on us.  I notice from our logs it was fixed
about 2 weeks after the 2.1 got out. In any case, you're the first one
to notice it, so I guess that tells me how many people are using FME to do
automated translation to MapGuide SDL.....

The good news is that a) FME 2.2 fixes this and b) it is VERY easy to
fix it yourself.

Got into the FME installation directory, and find the "metafile" subdirectory.
If you have an editor other than notepad, you can just switch these
lines from:

     FORMAT_NAME SDL
     SOURCE_READER SDL

to:

     SOURCE_READER SDL
     FORMAT_NAME SDL

Or you can save yourself the bother by just FTPing:

         ftp://ftp.safe.com/fme/sdl.fmf

and replacing your copy with the one you download.

Hope this helps, and sorry about this.

Dale


"Message received from 'Kilby, Ward EM:EX' as follows:"
>
> Using version 2.1 and trying to convert a shape file to SDL format.
>
> I get the error message
>
> unable to generate mapping file for source data set "b:\kdjfkd\kdfkjd\"
> " ...check that format is correct ...etc.
>
>
> If I change the output format from SDL to say shape everything works well.
> Same problems with E00.
>
> Any ideas on what I am doing wrong?
> thanks
> ___________________________________________________________
>
> Ward Kilby
> Manager - Mineral Potential / GIS
> Geological Survey Branch - Mineral Development Office
> 300 - 865 Hornby Street
> Vancouver, BC
> V6Z 2G3
> Ph: 604.660.2693    Fax:  604.775.0313
> WEB: http://www.ei.gov.bc.ca/geology
>
>
> ----
> Read this list on the Web at http://www.FindMail.com/list/fme/
> To unsubscribe, email to fme-unsubscribe@...
> To subscribe, email to fme-subscribe@...
> --
> Start a FREE E-Mail List at http://makelist.com !
>
>

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Using version 2.1 and trying to convert a shape file to SDL format.

I get the error message

unable to generate mapping file for source data set "b:\kdjfkd\kdfkjd\"
" ...check that format is correct ...etc.


If I change the output format from SDL to say shape everything works well.
Same problems with E00.

Any ideas on what I am doing wrong?
thanks
___________________________________________________________

Ward Kilby
Manager - Mineral Potential / GIS
Geological Survey Branch - Mineral Development Office
300 - 865 Hornby Street
Vancouver, BC
V6Z 2G3
Ph: 604.660.2693    Fax:  604.775.0313
WEB: http://www.ei.gov.bc.ca/geology


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi,

The "fme" program returns a -1 if an error occured during translation,
and a 0 if all went okay.

So its probably best to test for 0 in your scripts, as I believe -1
could be represented differently by the different shells.

Dale

> I start your program from a batch file - does the program set exit codes
> to indicate its running status.
>
> For example:
>
> exit code = 0  Indicate that FME executed the command successfully
> exit code = 1     Indicates a error
>
> If FME set exit codes I can use it with the command
>
>
>
> If errorlevel 1 goto FAILURE
>
>
> FAILURE:
>     echo An error has occurred >> C:\temp\error.log
>
>
>


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi all,

We've had a couple inquiries from a some FME users who want to do
overlay-like operations with FME.  Since there's some interest in this
capability, and because I happen to think it's quite cool, I thought
I'd post a quick note describing the powerful new OverlayFactory.
It's in the FME 2.2 betas, but really you should get build 260 from
ftp://ftp.safe.com/fme/fme_beta.exe for the latest and greatest
version. (Build 260 will be uploaded later this week).

The FME's OverlayFactory is only available in the FME Professional or
Server Edition,it will be part of the release version of FME 2.2.

What can the OverlayFactory do?  Well, quite a bit.  We're looking for
testers so if you think it might have an application for it, feel free
to give it a spin.

I've attached two items below -- first is the draft FME manual entry
for the OverlayFactory. This should give you some idea of its
capabilities.

The second attachment is a mapping file that uses the OverlayFactory as
part of a design file to design file translation.  The input design file
has linework which forms tree boundaries, contour lines, and DEM points.
The mapping file forms polygons from the tree boundaries, and then uses
two overlay factories -- the first one overlays the contour lines with
the tree areas, and the second one overlays the DEM points with the
tree areas.  Any line segments or points inside the tree areas are
flagged as such, and have their display properties changed on output.

Have fun!

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------

=========================================================================
OverlayFactory description:
=========================================================================

The OverlayFactory can do polygon-on-polygon, point-on-polygon, and
line-on- polygon overlay.

The syntax for the factory is:

         FACTORY_DEF * OverlayFactory                                        \
             INPUT (POLYGON|POINT|LINE) FEATURE_TYPE * [<attr> <value>]+ ... \
             [LIST_NAME  attrlist{}]                                         \
             [OVERLAP_COUNT_ATTRIBUTE <countAttrName>]                       \
             OUTPUT (POLYGON|POINT|LINE) FEATURE_TYPE * [<attr> <value>]+ ...

There are three modes of the overlay factory.  The mode of the factory
is determined by what combination of input tags are present.

Mode 1: Only POLYGONs are input
===============================
In this mode, the polygons are analyzed and new polygons are formed for
each area which results when the original polygons are overlayed on top
of each other.  The resulting polygons have all their attributes merged,
as well has having an attribute list indexed at 0 which each of the
attributes from each of their original features.

In this mode, only the OUTPUT POLYGON tag is used -- if the others
are specified they will cause an error during factory creation.

Mode 2: Only POLYGONs and POINTs are input
==========================================
In this mode, each input point is tested against each input polygon.
If the polygon contains the point, the attributes of the point are merged
with the polygon and added to its list, and the attributes of the polygon
are merged with the point and added to its list.

In this mode, the OUTPUT POLYGON and OUTPUT POINT tags are available to be used.

Mode 3: Only POLYGONs and LINEs are input
=========================================
In this mode, each line is segmented at the polygon boundaries.  Then each
resulting line is checked against all the original polygons.  If the
polygon contains the resultant line, the attributes of the line are merged
with the polygon and added to the polygon's list, and the attributes of
the polygon are merged with the line and added to line's list.

In this mode, the OUTPUT POLYGON and OUTPUT LINE tags are available to be used.


=========================================================================
Example Mapping File
=========================================================================

# ============================================================================
#
# This mapping file was created to do a DGN -> DGN overlay.
# It forms polygons from linework that represents tree boundaries, then
# flags all the point features and contour lines that were inside these
# polygons.
#
# Modification History:
#
#     Name              Date     Description
#     ================= ======== =============================================
#     Dale Lutz         19980605 Original Release
#
# ============================================================================

# ============================================================================

GUI TITLE Design File to Design File Overlay

# ============================================================================

READER_TYPE IGDS

WRITER_TYPE IGDS

# ============================================================================
# Set up reader

GUI FILENAME SourceDataset Design_Files(*.dgn)|*.dgn|All_files(*.*)|*.* Original
IGDS Dataset:

READER_KEYWORD IGDS_IN

IGDS_IN_EXPAND_CELLS no

IGDS_IN_DATASET "$(SourceDataset)"

# ============================================================================
# Set up writer

GUI FILENAME DestDataset Design_Files(*.dgn)|*.dgn|All_files(*.*)|*.*
Destination Design File:

WRITER_KEYWORD IGDS_OUT

# We use the input file name as the seed file
IGDS_OUT_SEED_FILE "$(SourceDataset)"

IGDS_OUT_DATASET "$(DestDataset)"

# ==========================================================================
# Okay, now form the polygons from what we were supposed to
# Here were our specs:
#
# Tree polygon  Level = 48  Colour = 114
# Contour Int   Level = 40  Colour = 110
# Contour Ind   Level = 39  Colour = 8
# dem points    Level = 55  Colour = 4

# Before we do anything, remove the symbology and element type attributes

FACTORY_DEF * TeeFactory  \
    INPUT FEATURE_TYPE * \
    OUTPUT FEATURE_TYPE * @RemoveAttributes(igds_symbology,igds_element_type)

# First, tee off the tree boundary lines -- we make a copy we will
# turn into polygons, the originals go out to the output file

FACTORY_DEF * TeeFactory  \
    INPUT FEATURE_TYPE 48 igds_type igds_line igds_color 114 \
    OUTPUT FEATURE_TYPE * \
    OUTPUT FEATURE_TYPE treeBoundaries

# Make polygons from all the boundary lines

FACTORY_DEF * PolygonFactory \
    INPUT FEATURE_TYPE treeBoundaries \
    END_NODED \
    OUTPUT POLYGON FEATURE_TYPE treeRing \
    OUTPUT LINE FEATURE_TYPE 1 igds_type igds_line igds_color 115 igds_weight 6
@Count(unclosedTreeBoundary)

# and carve out the holes too

FACTORY_DEF * DonutFactory \
    DROP_HOLES \
    INPUT FEATURE_TYPE treeRing \
    OUTPUT DONUT FEATURE_TYPE treeArea \
    OUTPUT POLYGON FEATURE_TYPE treeArea

# Now we are ready for the first overlay -- in this one, we do all the
# contour lines against the tree polygons.  As the tree polygons enter the
# factory, we give them an attribute called "inside" with the value yes.
# Any lines that emerge that have this attribute will be known to be inside
# the tree areas, and anything without it, is outside.  We do the
"KeepAttributes"
# only as an efficiency item -- by doing this we clear all the other attributes
# off of the tree polygons and in so doing reduce the work the overlay factory
# must do when it merges attributes -- we can do this because we only care
# about the "inside" attribute.

FACTORY_DEF * OverlayFactory \
    INPUT POLYGON FEATURE_TYPE treeArea @SupplyAttributes(inside,yes)
@KeepAttributes(inside) \
    INPUT LINE FEATURE_TYPE 39 igds_type igds_line igds_color 8 \
    INPUT LINE FEATURE_TYPE 40 igds_type igds_line igds_color 110 \
    OUTPUT POLYGON FEATURE_TYPE treeArea \
    OUTPUT LINE FEATURE_TYPE * @Count("line->&inside <")

# Now adjust the symbology of the contours inside the polygon
# We will just put them into different levels.

FACTORY_DEF * TeeFactory \
   INPUT FEATURE_TYPE 39 inside yes \
   OUTPUT FEATURE_TYPE 5

FACTORY_DEF * TeeFactory \
   INPUT FEATURE_TYPE 40 inside yes \
   OUTPUT FEATURE_TYPE 4

# Now get the points inside the trees, using the overlay factory in
# point - on - polygon mode.
# For now we'll also output the tree polygons on level 2

FACTORY_DEF * OverlayFactory \
    INPUT POLYGON FEATURE_TYPE treeArea @KeepAttributes(inside) \
    INPUT POINT FEATURE_TYPE 55 igds_type igds_point igds_color 4 \
    OUTPUT POLYGON FEATURE_TYPE 2 igds_type igds_solid igds_color 2 \
    OUTPUT POINT FEATURE_TYPE * @Count("point->&inside <") @Count("geometry->
&fme_geometry")

# Now adjust the symbology of the points inside the polygon
# For now we are just putting them on level 3, and leaving the color etc. the
# same.

FACTORY_DEF * TeeFactory \
   INPUT FEATURE_TYPE 55 inside yes \
   OUTPUT FEATURE_TYPE 3

# ==========================================================================
# Finally, just one transfer specification to do it all

IGDS_IN  *
IGDS_OUT *


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi all,

> has Safe built a module yet for the (supposedly European Standard)
> GDF ascii format ?  Any knowledge or experiences with it ?

We know of this format and have the specification.  It is complex,
even though it is ASCII.  We will not be building it unless some customer
comes along and gives us a real incentive to do so ......

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Dale-- has Safe built a module yet for the (supposedly European Standard)
GDF ascii format ?  Any knowledge or experiences with it ?

Chuck Ellis
MaconUSA






----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Problem:

Donuts formed by the DonutFactory sometimes have their holes
filled when output as filled solids in, for example, Microstation
IGDS design files.

The situation is caused by the DonutFactory's default
behaviour, which is to output donut polygon holes as polygons
themselves. These are then getting filled in as solid-filled polygons
  (as is often desired for regular, non-donut polygons). Since the
hole-polygons exactly coincide with the holes, the final appearance
is of donut polygons with their holes filled in.

This default behaviour can be changed to give non-filled donut
holest. Just add the DROP_HOLES clause to the DonutFactorys:

FACTORY_DEF IGDS_IN DonutFactory \
  INPUT FEATURE_TYPE Noise97Polygon \
  INPUT FEATURE_TYPE 5 fme_geometry fme_polygon \
  DROP_HOLES \
  OUTPUT  POLYGON FEATURE_TYPE Noise97Polygon \
  OUTPUT  DONUT   FEATURE_TYPE Noise97Donut

This causes hole polygons to be dropped, leaving hole-shaped voids in
  place of the hole polygons. No hole-filling will occur since there
are now truly no hole-polygons to be filled at the holes.
--------------------------------------------------------------------------
Safe Software Support      Safe Software Inc.             support@...
                            Surrey, BC, CANADA        phone: (604) 501-9985
                           http://www.safe.com          fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Dale,

Thanks for your assistance, I'll have a good look at the User Manual
and we'll see were we go from there.  The prompt response was very
much appreciated.

Regards,
Peter

  -------------------------- Peter Barnes-------------------------------
     Senior Software Developer               Ph  (01223) 428453
	 Sysdeco UK Limited                      Fax (01223) 420324
	 Unit 302, Cambridge Science Park        peter@...
	 Milton Road, Cambridge, CB4 4WG


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

An FME customer writes us and asks:

> We have a requirement to do non-interactive (ie. batch
> or on demand) translation between a few formats.

> Most urgent is a translation from MapInfo MID/MIF to
> DGN (Intergraph/Microstation).  Ideally we'd like to
> be able to utilise your translator via DLLs or the
> like - if you have libraries or whatever on (Sun) UNIX
> these are of interest.

Well, FME can help you out.  In its heart, FME is a command line program.
We do not have a shared object/DLL version of FME yet (and won't for
a long time on UNIX, might on windows eventually).  All the FME user
interfaces do is create a command line, and then shoot off FME to do
the work.  So basically how you'd run it is just do a "system" call, or
the equivalent on Windows (using the very friendly CreateProcess call), to
shoot off a command line.  MIF/MID to DGN is no problem with this either.

A typical command line looks something like:

   fme mif2dgn.fme --SourceDataset /usr/mifdata --DestDataset
/usr/dgndata/hello.dgn

To get a better idea of how the FME command line works, please carefully
review section 25 in Part III of the FME User's manual -- "Performing
Command Line Translations".  This walks through two of the most common
scenarios for using the FME from the command line.  The best plan of
attack is to experiement by running FME yourself interactively from
the command line, and then once you get your command lines set up,
move to creating these command lines programmatically and firing them
off from there.

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Hi,

> Is there any way to produce a multi-writer-mapping file for 50+
> mapsheets without coding for hours?

Well, there actually is no FME multi-writer, so I assume you mean the
FME multi-reader.

With the normal usage of the "multi-reader", you need to have this
block of lines (of course, adjusted for whatever reader you want to use):

     MULTI_READER_TYPE{0}    SAIF
     MULTI_READER_KEYWORD{0} SAIF{0}
     SAIF{0}_DATASET c:\saifdata\92i080.zip
     SAIF{0}_IDs PointsAndBreaklines

repeated for each file you want read in your FME session.

As you hint at, this is not a very exciting thing to do. And in fact,
we know of several FME users who have written Visual BASIC programs
(or similar) to actually create this block of multi-reader statements,
rather than hack them in one at a time.

Its been on our todo list for about a year to remedy this.  And I have
good news to FME subscribers.  The latest FME beta (which is always
available to subscribers at ftp://ftp.safe.com/fme/fme_beta.exe), has
an extended multi-reader that lets you just point it at a directory, and
it will try to read all the files (or directories, if appropriate) in
that directory.

Here's a fragment of a mapping file that uses this to read all the design
files in a given directory.  Actually, it will try to read ALL the files
in the directory, so ahead of time you must ensure that the directory
contains only what you want.

Basically you just set the MULTI_READER_DATASET to be the directory
that contains the files, and use the {*}  to set the type.  Then you can
just use the reader type (IGDS) to as the keyword to set anything that
should apply to ALL the readers the multi-reader will use (like in my
example below, where I tell them all to use MASTER_UNITS).

The VERBOSE directive causes the multi-reader to dump to the logfile
a bunch of info about what it is doing (what files it finds in the
directory). This is not necessary but it makes you feel happy that you didn't
type it all in yourself.

     # ----------------------------------------------------------------------
     # Set up the multi reader to read all the design files in the given director

     READER_TYPE MULTI_READER
     MULTI_READER_TYPE{*} IGDS
     MULTI_READER_DATASET  "/usr/bart/maps"
     MULTI_READER_VERBOSE yes

     IGDS_UNITS IGDS_MASTER_UNITS

Features read by this form of the multi-reader have these added attributes
you can use to figure out where they came from (multi_reader_id is meaningless
in this case):

     multi_reader_pathname
     multi_reader_basename
     multi_reader_filename
     multi_reader_extension

For most uses you will not care about these extra attributes.

Hope this helps.

Dale

--------------------------------------------------------------------------
Dale Lutz                Safe Software Inc.                   dal@...
                          Surrey, BC, CANADA          phone: (604) 501-9985
                          http://www.safe.com           fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

Is there any way to produce a multi-writer-mapping file for 50+ mapsheets
without coding for hours?

Jeff Rogers
jrogers@...


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

The mismatch between an FME-generated NAD27 to NAD83
B.C. provincial mapsheet and the province's NAD83 reference grid is
normal and does not constitute an error.

If you imagine the NAD27 input mapsheet in Lat/Long and examine a
corner of it, it would be at (for example) 50,-120 degrees. When this
is converted to NAD83, the corner's coordinates will (correctly) no
longer be at this location: they might be shifted to 51.2,-120.8
degrees instead.

Now lay this NAD-shifted mapsheet down onto a NAD83 Lat/Long grid.
This grid has the corresponding mapsheet corner still at 50,-120
degrees, since this is still the corner's correct location within
NAD83. But the same corner of the overlying mapsheet, now at
51.2,-120.8 degrees due to the NAD shift, will not match the grid's
corner position. There will be an offset between the NAD-shifted
mapsheet and the grid.

Therefore, when you take a NAD27 mapsheet and convert it
to NAD83, the shifted data will not completely fill the
corresponding NAD83 mapsheet.  Some portion will be outside.
This is because the NAD27 sheet actually maps a slightly
different area than its corresponding NAD83 sheet.

--------------------------------------------------------------------------
Safe Software Support      Safe Software Inc.             support@...
                            Surrey, BC, CANADA        phone: (604) 501-9985
                           http://www.safe.com          fax: (604) 501-9965
--------------------------------------------------------------------------


----
Read this list on the Web at http://www.FindMail.com/list/fme/
To unsubscribe, email to fme-unsubscribe@...
To subscribe, email to fme-subscribe@...
--
Start a FREE E-Mail List at http://makelist.com !

The FME mailing list is a forum for FME users to ask questions, receive help,
and generally exchange information on FME.  Questions about FME formats,
processing capabilities, future plans, documentation, mapping (control) files
and coordinate conversion issues are welcomed.

To subscribe, send an empty message to fme-subscribe@...

To unsubscribe, send a message to fme-unsubscribe@...

List Owner: fme-owner@...