# Reader with variable output data type

**URL:** https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971
**Category:** Development
**Created:** [November 13, 2019, 5:04pm UTC](https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971 "2019-11-13T17:04:22Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![cobo](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 13, 2019, 5:04pm UTC](https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971/1 "2019-11-13T17:04:23Z")

</div>

Trying to write a DXF reader that generates output data of a type that depends on the data it was reading from the file.

So far I am having a DXF reader that is ported from the ParaViewGeo project. It reads DXF data files nicely and always generates a “multi block dataset” as an output, with each “layer” of the DXF file producing one “block” in the multi block dataset.

Now I see that customers are regularly confused if they have a DXF that is for example just one single triangulated surface: they read it and wonder why they cannot save it as a vtp, only as vtm. And then I have to explain them that they first need to apply another filter (also from the ParaView Geo project) that extracts single geometry items from a multi block dataset.

In order to make life easier I thought that I could do that last step just automatically in cases where the mbds contains just one single data item (polydata normally) - but that is more difficult than I expected! Because it looks like I need to specify the output data type “latest” in the RequestDataObject() function - which is called before the file is even read.

So far I see three possible “solutions” - if they can be realized:

1. I tried to somehow change the datatype within the RequestData() function, but it looks like that change does not “arrive” where it should - but maybe there is still a way that I am not aware of?

2. Another possibility would be to simply do the actual reading already in the RequestDataObject() function - which would be before the user even presses the Apply button. This would be feasible because there are no option properties to choose anyway; only the user would have to wait a bit longer before he sees the Apply button at all - and afterwards things would be much faster than normal…

3. Simply write two readers: one that generates a polydata item - and if there are more than one layer, just pick the first and emit a warning. And a second reader that works like it does now: read everything available and put it into a multi block dataset.

Realizing solution 3) is easy, but I would actually prefer something like solution 1) - if possible!

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [November 13, 2019, 7:56pm UTC](https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971/2 "2019-11-13T19:56:06Z")

</div>

Why not addding a Merge Blocks with with vtkPolyData output type ?

---

<div class="post-metadata">

### Author: ![cobo](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/c/f17d59/32.png) [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 14, 2019, 7:52am UTC](https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971/3 "2019-11-14T07:52:43Z")

</div>

Thanks, that looks like a good idea: I change the current filter in such a way that it tries to merge as much as possible and generate a vtkPolyData output. And copy & rename the current reader to something like “MultiBlockDXFReader” - to be used only by those who know that they have several “layers” in their DXF and want to keep them separate. (Costs nothing because I already have that one!)

Regarding the variable output data type, I am realizing that it seems to only work if you can tell already during the “preparation” phase, like: make the output data type same as input data type. This I realized already in two filters successfully.

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [November 18, 2019, 9:51am UTC](https://discourse.paraview.org/t/reader-with-variable-output-data-type/2971/4 "2019-11-18T09:51:48Z")

</div>

> [@cobo](#):
>
> Regarding the variable output data type, I am realizing that it seems to only work if you can tell already during the “preparation” phase, like: make the output data type same as input data type. This I realized already in two filters successfully.

Indeed, I believe it is documented in the parameter.
