Assuming the call out has a frame (balloon, closed polyline or arc) around the text?
( if no frame present you can maybe get away with a neighbourfinder between leaders and text (or textinsertionpoint) depending on conflicting leaders or balloons)
If so separate the leaders form the balloons using for instance a loopdetector (can alos be done using a areabuilder, non areas are thus not closed polylines).
Spatialrelator lines vs balloons. To relate id's.
Spatialrelator begin and endvertex of leaders vs balloons, to detect wich end touches balloons. (if you need it)
Else snip (using Snipper) the leader by percentage 50,50 (gives you the center point)
Spatial relator text (or textinsertionpoint) objects vs balloons to relate id's.
Create csv
Any chance you can supply some sample data?
Any chance you can supply some sample data?
Here is a sample view of a portion of a .dwg file with the callouts (dark blue) and labels (green text).
I've tried various experiments with NearestNeighbor and different coordinates of the leader, but NearestNeighbor seems to be rather random as to what it thinks is its nearest neighbor. I've tried introducing range values, but when I use what should be reasonable values nothing matches.
I've tried various experiments with NearestNeighbor and different coordinates of the leader, but NearestNeighbor seems to be rather random as to what it thinks is its nearest neighbor. I've tried introducing range values, but when I use what should be reasonable values nothing matches.
The neighborfinder or nearest neighbour is the right way to go, would it be possible for you to add some sample data, for example a clip of the data shown?
Hi @michaellampi, if the callout/leading line is a Line geometry having three vertices and the label text is a Text geometry, I think you can transfer the text string (i.e. fme_text_string attribute) of a label text to the closest line using the NeighborFinder with this setting.
- Input Ports: Lines -> Base, Texts -> Candidate
Number of Neighbors to Find: 1
Maximum Distance: <not set>
You can then extract coordinates of any vertex from the line output from the Matched port with the CoordinateExtractor.
Hi @michaellampi, if the callout/leading line is a Line geometry having three vertices and the label text is a Text geometry, I think you can transfer the text string (i.e. fme_text_string attribute) of a label text to the closest line using the NeighborFinder with this setting.
- Input Ports: Lines -> Base, Texts -> Candidate
Number of Neighbors to Find: 1
Maximum Distance: <not set>
You can then extract coordinates of any vertex from the line output from the Matched port with the CoordinateExtractor.
Thank you, Takashi. This is exactly the approach I was taking, but the matching is not working very well. I have tried leaving the range value unspecified, which often matches the wrong vertex with the label, resulting in an incorrect target being selected. I have tried restricting the range to a value that should be within the distance to the anchor point of the text, and then no (or very few) matches are made. I have tried intermediate values, and while more matches are being made, a lot aren't - until I start seeing bad matches again.
Unfortunately, the smallest file I have to upload showing this is 3.9MB in size.
Thank you, Takashi. This is exactly the approach I was taking, but the matching is not working very well. I have tried leaving the range value unspecified, which often matches the wrong vertex with the label, resulting in an incorrect target being selected. I have tried restricting the range to a value that should be within the distance to the anchor point of the text, and then no (or very few) matches are made. I have tried intermediate values, and while more matches are being made, a lot aren't - until I start seeing bad matches again.
I think such wrong matching could appear only if two or more pairs of Text and Line lie very close or overlap each other. Is there such a condition?
I think such wrong matching could appear only if two or more pairs of Text and Line lie very close or overlap each other. Is there such a condition?
I understand; however, while there are a couple of places where this occurs, this is not the situation in most cases.
Thank you, Takashi. This is exactly the approach I was taking, but the matching is not working very well. I have tried leaving the range value unspecified, which often matches the wrong vertex with the label, resulting in an incorrect target being selected. I have tried restricting the range to a value that should be within the distance to the anchor point of the text, and then no (or very few) matches are made. I have tried intermediate values, and while more matches are being made, a lot aren't - until I start seeing bad matches again.
Could you please post a sample dataset? No need to upload whole original data. Convert only label texts and callout/leading lines into FFS format (compressed) and upload that.
Could you please post a sample dataset? No need to upload whole original data. Convert only label texts and callout/leading lines into FFS format (compressed) and upload that.
I don't know how to do that. I tried adding a writer to take the layer output, but it doesn't seem to actually write anything even though some 7K+ items were extracted.
I don't know how to do that. I tried adding a writer to take the layer output, but it doesn't seem to actually write anything even though some 7K+ items were extracted.
Just add an FFS writer to the workspace, create two writer feature types, and write texts and lines into them. You can also specify compression level of the destination FFS file. e.g.
I don't know how to do that. I tried adding a writer to take the layer output, but it doesn't seem to actually write anything even though some 7K+ items were extracted.
alternatively, if possible, you can upload the original data to a web service such as Google Drive etc. and share the link with us.
testlabellineffs.zipThis is really a .ffs file, not a .zip. The uploader doesn't seem to like .ffs extensions.
testlabellineffs.zipThis is really a .ffs file, not a .zip. The uploader doesn't seem to like .ffs extensions.
There were irregular texts as shown in this screenshot (surrounded red rectangles). I think the unexpected matching occurs in these parts.
How do you want to resolve those irregular texts?
There are some interesting things that seem to occur when these drawings are imported into FME. Labels get misplaced somehow, and leaders and text seem to move around as you see here.
Try this smaller set, rather than the larger one. I can also upload a PNG showing how they appear in the drawing.testlabellineffs2.zipgp-deck06-zone5-model.pdf
There are some interesting things that seem to occur when these drawings are imported into FME. Labels get misplaced somehow, and leaders and text seem to move around as you see here.
Try this smaller set, rather than the larger one. I can also upload a PNG showing how they appear in the drawing.testlabellineffs2.zipgp-deck06-zone5-model.pdf
Some lines in the FFS file seems to have been flipped horizontal.
Would the texts and lines be shown correctly if you read them with FME reader and send the texts and lines to FME Data Inspector?
I don't think so. This seems to be how FME interprets the file. I presumed it to be a bug.
I don't think so. This seems to be how FME interprets the file. I presumed it to be a bug.
There could be a potential bug if FME Data Inspector couldn't display the features correctly even though FME read the original dataset directly. If so, contact Safe support.
You see the leaders that are wrong should have their line that is supposed to underline the text is 180 degrees from the associated text? That's what I presume to be an FME bug.
thus taking into account this issue, all you need to do is a neigbourfinder, with leaders as bases.
Unmatched bases need to be rotated 180 around the knee-joint. Then neighbor find those again.
thus taking into account this issue, all you need to do is a neigbourfinder, with leaders as bases.
Unmatched bases need to be rotated 180 around the knee-joint. Then neighbor find those again.
Fonts will change the text size but not the leader orientation.
