Accurate Sheet Legends Using Data Tags

[ericjhberg]

Alright VW Friends, we need some help troubleshooting a particular workflow that has become problematic.

 

The challenge...

How do you create a legend that is specific to the items being identified by Data Tags within a given viewport using Records and Data Tags?

 

Because this is a technical question, I'm going to have to get into the weeds a little with our particular challenge.

 

We have grown particularly fond of using specific custom record formats, coupled with data tags, to more easily manage callouts/keynotes in a drawing. It is very easy to create "Master" legends that summarize specific information in a variety of ways for all "similar" objects across a drawing/file using isolation techniques like class, record format, layer, etc.

 

The difficulty lies in using the same record information to query a subset of those objects that appear in specific viewports, and exclude those that do not appear.

 

In the landscape architecture world, it is not uncommon to have projects where improvements span multiple sheets and/or viewports. These are typically separated by match lines.

 

In the image below, we have a simplified scenario where improvements are divided into (4) different viewports...

 

Notice that there are (7) objects in the drawing, each attached with the same record format and identified using the fields ID# and DESCRIPTION. The large circle, which is actually clipped into two objects by the serpentine "sidewalk", exists in all (4) of the viewports. In the attachments to this post are exports of each sheet layer as an individual image where it is possible to see that data tags, placed in the annotations of each viewport, can easily identify the objects by their ID#. I've also attached the VW file used to create this example.

 

QUESTION: Now...how do you populate each of the unique worksheets with the items identified by the data tags (or even those that are clearly visible in the viewport)?

 

The goal, given this example, is to provide legends (worksheets) that should include items as follows:

• Sheet 1
  • P-1
  • P-2
  • P-3
• Sheet 2
  • P-1
  • P-2
  • P-3
• Sheet 3
  • P-1
  • P-2
  • P-4
• Sheet 4
  • P-1
  • P-3
  • P-4

 

You will also notice that the legends (actually worksheets in VW) do not correctly indicate the objects that are visible...or even those that have Data Tags. Sheet 3 doesn't include any...this is because our methodology, up until now, has been to use the Location...is within criteria in each unique worksheet to query the objects that fall within shapes that represent each viewport (gray dashed squares). For example,

• Schedule - Sheet 1, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 01
• Schedule - Sheet 2, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 02
• Schedule - Sheet 3, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 03
• Schedule - Sheet 4, is querying ALL objects with 1) Record attached, and 2) Location is within Shape 04

 

The problem arises because the Location...is within criteria only successfully queries objects where the Center Point falls within the identified Object. This is why Sheet 3 doesn't return anything but should include P-1, P-2, and P-4. There are technically two P-1s in this viewport because the large circle is being clipped by the serpentine path, but both of their respective center points fall outside of the Shape 03. Similarly the center of P-2, the serpentine sidewalk, is in Shape 02; and the center of P-4, the rectangular deck is in Shape 04.

 

We have various workarounds to try and remedy this situation using this "Location Based" workflow, but they are needlessly complicated and result in errors that are difficult to track down and timely to troubleshoot. They are not worth mentioning and the goal of this post is to try and find another, better way.

 

It seams to me that a solution might already exist, but as someone who knows VW quite well, I have struggled for a long time to figure out what it could be.

 

A solution that does work, but we want to avoid at ALL costs is...clipping the objects by their specific viewports so that each object is firmly located "within" each specific viewport. This is a terrible method because it destroys all sense of greater geometry, creates more opportunity for error, and does not facilitate easy revisions if geometries require editing.

 

I could think of two solutions, but both are NOT CURRENT functionality within VW that I am aware of:

1. Query Data Tags and Report Their Linkage - The problem with our workflow is that it is querying the objects...not the data tags. It is possible to place the correct data tags on each sheet, regardless of where the object's center is, and it is possible to build a query/report of specific data tags on a given sheet layer. What IS NOT possible is to link the query of a data tag to the data of the object it is tagging.
2. Intersection Criteria - If, instead of the only location based criteria being available being either "Is Within" or "Is Not Within", potentially adding an "Intersects With" option could mitigate the issue of an objects center point driving the query results. This is functionality common to many GIS software programs and it is one that I think could benefit a lot of use cases...

 

Calling all helpful users to help figure out the best workflow for this

@Eric Gilbey, PLA @bgoff @rowbear97 @Tony Kostreski @Vlado @Pat Stanford

VW Sheet Legends and Data Tags.vwx

[Vlado]

@ericjhberg this is pretty cool, thank you for the analysis of the problem.

It is definitely a problem we need solved soon.

It looks to me that, as suggested, we need a new feature or two.

Let me consult internally, and I'll contact your.

[trevorgooch]

One thing that may help is to attach a record to the data tag, and use a link field.  Essentially, you can shuttle data from the source object into a record associated with a data tag.  This allows for all sorts of interesting opportunities, like applying a data visualization to a data tag!

[ericjhberg]

59 minutes ago, Vlado said:

@ericjhberg this is pretty cool, thank you for the analysis of the problem.

It is definitely a problem we need solved soon.

It looks to me that, as suggested, we need a new feature or two.

Let me consult internally, and I'll contact your.

 

Thanks @Vlado for your prompt response. I really do think the "Intersects With" criteria could be far more powerful than this specific use case...especially if it could somehow return the AREA of intersection between two objects without having to actually run an intersection command. In the landscape architecture world, this need is most frequent for SHADE calculations where we need to calculate the area of a hardscape that intersects with trees. Currently the only way to do it is to break down tree symbols into base circles, duplicate hardscapes, and run intersection commands that allow for specific AREA queries. This doesn't respond well if anything changes.

Edited October 19, 2023 by ericjhberg

[ericjhberg]

22 minutes ago, trevorgooch said:

One thing that may help is to attach a record to the data tag, and use a link field.  Essentially, you can shuttle data from the source object into a record associated with a data tag.  This allows for all sorts of interesting opportunities, like applying a data visualization to a data tag!

 

I'm intrigued @trevorgooch. We've thought about attaching redundant records to data tags, but without someway of linking them to the original data, it would still be a difficult manual data entry job to keep track and manage...with many opportunities for error.

 

Your way sounds better, but I may need a little tutorial on this functionality to see how effective it could be in this case.

[trevorgooch]

This was a helpful demo to get my head around data linking in data tags.  
 

Best of luck!
 

 

[Nikolay Zhelyazkov]

Hello all,

 

7 hours ago, ericjhberg said:

Query Data Tags and Report Their Linkage - The problem with our workflow is that it is querying the objects...not the data tags. It is possible to place the correct data tags on each sheet, regardless of where the object's center is, and it is possible to build a query/report of specific data tags on a given sheet layer. What IS NOT possible is to link the query of a data tag to the data of the object it is tagging.

- Actually, this is possible if I understand it correctly. If you place data tags on the sheets you want them reported on you can then use DataTagField worksheet formula that will show the same data as the data tag. Note that DataTagField will require the text value of the text object inside of the data tag layout and will return the value of this text object that the data tag displays.

 

Let me know if this helps or if you need an example of its usage.

 

Best Regards,

Nikolay Zhelyazkov

[Nikolay Zhelyazkov]

@ericjhberg Just saw that you have a test file attached. Here is how I modified it using DataTagField to get what you want:

 

1) Changed the worksheet criteria to list data tags on the design layer

2) Changed the columns to read using DataTagField

3) Added one more text object in the data tag that reports on the short description and assigned it to a class that I then set to be invisible (just for data access)

 

Here is the result.VW Sheet Legends and Data Tags - report using tags.vwx

 

Best Regards,

Nikolay Zhelyazkov

[ericjhberg]

7 hours ago, Nikolay Zhelyazkov said:

Just saw that you have a test file attached. Here is how I modified it using DataTagField to get what you want:

@Nikolay Zhelyazkov...this is amazing and 100% solves the problem/question posed. I'm excited to get this into our workflow ASAP.

 

BTW...I had no idea that there is a DATATAGFIELD function available and even then, that it woud use the Field Label to query specific information, but I'm super glad that it does exist. This is one of those buried functionalities that I don't know how users ever figure out its there...other than to post something like this here and get help...so thank you again!

[dtheory]

this is a good one.. should be very useful