Hi @lifalin2016, I believe that translation from any XML is possible with the XML reader and/or XML transformers, but I cannot think of a concrete way to resolve your headaches unless understanding the schema of the actual XML documents. Can you attach minimal data enough to understand the schema and requirement?

Hello Takashi,

Of course. I've been away from the office, and couldn't respond until today.

Here's an example of a polyline (Ledning=Pipe) with internal nodes (tag "KnudePaaLedningItems") in XML #1. Starting and ending node names are given as attributes on the "Ledning" tag:

<Ledning Knude1="TE00111" Knude2="SM00035" Loebenr="1">
  <Kaldenavn>TE00111-SM00035</Kaldenavn>
  <KategoriKode>1</KategoriKode> <!-- Distributionsledning -->
  <Netberegning>J</Netberegning>
  <StatusKode>2</StatusKode> <!-- I brug -->
  <DatoEtableret>1972-01-01T00:00:00</DatoEtableret>
  <BeliggenhedKode>2</BeliggenhedKode> <!-- Fortov (fliser/belægning) -->
  <OprindXY>TEGNING</OprindXY>
  <Varenummer>PVC/90P10</Varenummer>
  <NoteItems />
  <KnudePaaLedningItems>
    <Knudenavn>AB00317</Knudenavn>
    <Knudenavn>AB00318</Knudenavn>
    <Knudenavn>AB00319</Knudenavn>
    <Knudenavn>AB00320</Knudenavn>
  </KnudePaaLedningItems>
  <LabelItems/>
  <DokumentItems />
</Ledning>

Here's an example of a named node in XML #2:

<Knude Knudenavn="AB00317">
  <XKoord>605805.87</XKoord>
  <YKoord>6100875.46</YKoord>
  <StatusKode>2</StatusKode>
  <NoteItems />
  <LabelItems />
  <DokumentItems />
</Knude>

I've tried to isolate the necessary steps into three parts:

1. Create a dummy feature with all named nodes in a list from XML #2
2. Transfer the XY list content to the named nodes list in XML #1
3. Use the stored XY to create intermediate nodes.

I do fear that this (especially step 1) may be extremely slow, as there are about 50,000 named nodes.

So any advice as how to tackle this is appriciated.

Cheers

Hi @lifalin2016, my idea is:

1. XML reader: Read the XML with Feature Paths (Elements to Match: Ledning, Knude).
2. XMLUpdater: On the 'Ledning' feature, update the 'xml_fragment' to insert the start and end node names as the first and last <Knudenavn> elements under <KnudePaaLedningItems>.
3. XMLFlattener: Flatten the fragment and expose 'KnudePaaLedningItems.Knudenavn{}' list, which contains node names including start and end nodes.
4. ListExploder: Explode the feature on the list.
5. FeatureMerger: Merge the 'Knude' feature to 'Ledning' feature using node name as join key.
6. VertexCreator and PointConnector: Create points and then connect them to form a line.

Assuming that the Ledning/@Loebenr is the unique identifier, the workflow looks like this.

The XML Updater performs updating the xml fragment with this setting. See also the attached workspace example: xml2none.fmwt (FME 2016.1)

oh, you can also create points before merging and merge the geometry to the 'Ledning' feature (FeatureMerger/Feature Merge Type: Geometry).

Thanks Takashi,

The XML manipulation is rather ingenious, but as it turned out, the PointConnector was what hit home for me. It also turned out that the embedded named nodes collection didn't contain the intermediate nodes, it was another embedded collection with XY :-)

I ended up dividing the "pipe" workflow into three paths, one for the start point, one for the end point, and one for the intermediate points, using ListExploder the same way you proposed. And finally merging the points from all three paths into a single sorted list.

So I'm getting valid line feature results now. Thanks again :-)

Cheers