Steve,
All the meters have as far as editing the names are concerned, are attributes. You are free to double click a block and adjust the values as you need, and just regen the schedules which should realign things appropriately. For any info about the meter needs to change, you would still just do that in the Source Data dialog, and resize mainlines if performance data has changed.

If you are seeing results that indicate otherwise, let us know and we can look into what is going on, but it should be that simple.

Thanks Jake. That is fine for the schedule, but now our meter ID doesn't match the Source Data Data Dialog. And when we edit equipment, it still identifies it as the old ID. I tried resizing to see it that would update it in the Source Data Dialog box. But it didn't. It seems like this should work like adding a valve. How can we get the Source Data Dialog box to update based on the actual POC (Meter) ID?

For example, our meter 7 is identified as 4 in the Source Data dialog box.

Steve,
Your Source ID is a static numbered list, and technically doesn't need to match, as that is rarely what is entered into the attribute field when placing the source block into the drawing. When you Edit Equipment, click on a meter, and the dialog opens, it should tell you which it is associated to, and yes they might not match.

I see what you are saying and asking for, so I will bring to the development team to discuss what this would take to function more like the valve callout dialog (feel free to shoot any ideas or mockups on how you are thinking this would function), but in short, they are not the same, so I can't make any promises what the final outcome will be. I will keep you posted though.

I can't believe that LandFX thinks that this is acceptable. See image.

Tell me that this is not confusing: Meter Number 2 which is controlled by Controller 2 is listed as POC 5 in the critical analysis. Now please tell me how a plan checker is supposed to know that Meter 2 is POC 5. How illogical.

I hope that LandFX can fix this soon.

Our workaround is to explode the critical analysis table and modify it to match the POC ID (2 in our example). Clunky.

Steve,
We are not saying that is acceptable, but that is what will happen if you decide to change all the superficial info and not the actual data. So I would say exploding things would be the wrong work around, but should be more, take note of what each POC data is, and adjust appropriately in Source Data so it lines up with the changes you decided to do.

We have definitely noted this as a desired function and need to figure out where it lands in the list of upcoming projects, so get those mockups/logic and examples over to us on how you think this works, and that will help expedite things.

Jake,

Are you suggesting that we reinput all of the source data of all of the POC's that occur after the one that is added? If so, that is exactly what we want LandFX to do automatically. To do this, the POC ID can't be fixed. The user needs to be able to edit it in the dialog box. Then if making a change, the software would prompt the user just like the valve dialog box does. "Duplicate or Resequencing?"

Do you have a better suggestion as how we should tie the POC to the Controller. Further...... there is another issue. Why can the POC's only be numerical while the valve ID's can only be alphabetical?

I would like to suggest more flexibly for the designer.

For instance, a designer should be able to have a POC1 and a Controller 1 (C1) and a valve 1-1.
OR POCA relative to a Controller A and a valve A-1 (or A1)

Or is that just too logical? This is something that you could discuss with Jer about. You are closer to Irrigation Design than he is. While he does understand irrigation (and a whole lot of everything else), his strongest skills are elsewhere.

So, how will you suggest that we tie the three elements together. Four when we include the item that started this whole thing. The critical analysis.

Steve,

You may recall that the first version of Land F/X only allowed for POCs 1-9! We couldn’t even conceive of a need beyond that, boy were we mistaken.
We also couldn’t conceive of water sources changing so dramatically. They are so imperative to the entire design, the entire concept of POCs changing willy-nilly never occurred to us. So we never built the functionality to change numbers.
This is highlighting a definite need, and just like moving beyond 1-9, we will certainly improve this.
I too would agree that my strongest skill is not irrigation design, just the same that your strongest skill is not software development.

—J

Ha, ha,,, You are so right on all points. I used to delve into scripts and lsp. But I was never a wizard. And once we started using your dad's program (your code), there was no need for me to do so. I haven't coded since then. You always did it so much better. It was obvious to your dad, as it was to me.

Until this is addressed, how would you suggest that we tie our POC's to our Critical analysis'?
We have Meters and Controllers A through F. (backflow preventers, flow sensors and valves are also identified as A-F. So, on the plan and in the schedule, they are all associated and identified. The only thing that is not associated with these ID's is the critical analysis.
The Critical analysis POC's are not associated. They are a number (not alphabetical since they can't. And valves can't be numeric)
The Critical Analysis POC's are not even in order. So while A=1 a new POC , the original design disallowed the streetscape to be treated with four original POC's. The pressure was too low. We had to weave in two additional POC's. So, when we added a POC, the POC's weren't even in order anymore. Controller B is not POC 6.

Without going on about the discombobulation, how would you suggest that we tie the resulting POC numeric ID's to the Controller/Meter alphabetical ID's?

I was thinking that we place a string of text next to the "POC NUMBER: 01" that reads "METER A". that seems easy enough. Is that what you would do for now?

BTW, Why do the schedules automatically capitalize schedules, but the critical analysis has to be edited manually to turn into CAPS and then reset the columns? And why doesn't it allow one to select the critical analysis to regenerate it like we can the schedules?

Regarding regenerating, we opted to leave the Critical Analysis as raw elements, to make it more obvious and easy to manually edit.

Regarding capitalization, the CA uses capitalization to signify the different sections: PRESSURE AVAILABLE, DESIGN ANALYSIS, etc. If everything was capitalized, this distinction would be lost. We are looking at adding additional underlining and header styles to signify these different sections, which would allow supporting the uppercase setting.

As for the crux of your issue, there's two primary points. First, is if you have to edit the CA to change the POC number to a letter, then it really doesn't matter much, as that manual edit will be necessary no matter if the numbers are in sequence.

But if you just wanted to fix the sequence, here is how I would do it: Since there is only a single placed POC to replace, it's really not a big deal to redo it. I would shoot a screenshot of each POC's info, then delete them all, then recreate them in the correct order. Finally, delete the placed ones and place the new ones.

This has certainly highlighted the need for an ability to edit POCs, as well as reorder them, and even allow alphabetic identifiers instead of just numeric. This has all been logged, and should get addressed next year.

--J

Good points. Rather than redefining 6 of the7 POC's (which would include everything that you said plus resizing the mainline) we'll leave them un-sequenced and just show the meter number in the CA (see image).

e