Hi Jamal,

 

 

You can use the GeometryCoercer (Geometry Type: fme_point) to transform Text geometries into Point geometries. Resulting point feature retains text string as attribute called "fme_text_string" or "autocad_text_string", so you can expose it with the AttributeExposer, if necessary.

 

 

Takashi

---

It appears that the FME doesn’t detect the CAD text. Am I correct?

 

 

 

 

 

 

---

Two possible cases.

 

1) The source dataset doesn't contain the Text features.

 

2) You've filtered out feature types other than Line feature by setting"Feature Type to Read" parameter of the reader.

---

Many thanks Takashi for the help,

 

 

Now it appears to work fine. I could catch the texts of the CAD.

 

 

 

 

---

Good to hear you've accomplished the purpose.

 

 

Some tips for brushing up the workspace:

 

1) In some cases, TestFilter could be more efficient than using multiple Testers in parallel. And also, if there always are just 2 feature types (i.e. Text and Line), just one GeometryFilter might filter them properly, instead of 2 Testers and 2 GeometryFilters.

 

2) Text features will be treated as same as point features representing text locations when comparing spatial relationships with other features.

 

3) The AreaBuilder accepts aggregate (multi-part) line features and duplicated lines.

---

My approach in converting parcels from CAD to GIS is

 

 

1. To extract the parcel layer (with “tester” command)

 

2. To explode all the content of the layer (the parcel layer could originally contain lines, polygons, arcs and other data type, i.e. this layer might not be clean: with which tool?)

 

3. To remove the duplicates in the layer (with “matcher” tool)

 

4. To convert all the contents of this layer into lines (which tool can do this?)

 

5. To convert lines to polygon ( with “areabuilder” tool)

 

6. Then the texts are migrated from text layer to polygons (with “spatialfilter” tool)

 

 

Is this the best practice?

 

 

 

 

 

 

---

There are always several ways to do same thing, so I cannot say what is the best practice. Just can provide other options.

 

 

If there could be several layers other than Parcels_Numbers and Parcels_Polygons in the actual source data, I would add reader feature types for Parcels_Numbers and Parcels_Polygons as Individual Feature Types, rather than adding a Single Merged Feature Type (_ALL_). Then, the Testers will not be essential.

 

 

If the Parcels_Numbers layer can contain features with geometries other than text type, the GeometryFilter_2 is necessary to filter out invalid geometries. But the SpatialFilter treats text geometries as same as point geometries representing text locations when comparing spatial relationships, so the GeometryCoercer_2 and the GeometryFilter_3 are not essential.

 

 

If the Parcels_Polygons layer can contain features with different geometry types e.g. line, polygon, arc, ellipse etc., the GeometryFilter may be necessary to filter out unpreferable geometries. But the Intersector can intersect lines, arcs, polygons, ellipses, and aggregate features, and also the AreaBuilder accepts duplicated features. So the Deaggregator, the Matcher, and the GeometryCoercer may not be essential.

 

 

Of course all should be decided depending on the actual data conditions and the purpose of the workspace. Therefore, only the person who can know all the conditions - i.e. only you can decide the final design.

 

 

Good luck!

---

Thank you very much Takashi for the very useful comment.

 

 

Best

 

 

Jamal

---