FLO-2DKaren
commented
4 weeks ago I added this to the June Milestone but if we can't make it. that's OK.
Open FLO-2DKaren opened 4 weeks ago
FLO-2DKaren
commented
4 weeks ago I added this to the June Milestone but if we can't make it. that's OK.
rpachaly
commented
3 weeks ago I'll be working on this.
rpachaly
commented
3 weeks ago Let´s try to break this into small tasks.
@FLO-2DKaren add more if you can, it will be easier for me to fix this way.
FLO-2DKaren
commented
3 weeks ago Do you want to break this into separate issues? I can do that.
rpachaly
commented
3 weeks ago No, we can keep in this one. Just break them into small tasks here.
rpachaly
commented
2 weeks ago What are your thoughts on this? @FLO-2DKaren @FLO-2DNoemi
FLO-2DKaren
commented
2 weeks ago Hi Robson,
Both of those ideas sound great. I have some example standards we can take a look at for a few different counties.
FLO-2DNoemi
commented
2 weeks ago Hi Robson and Karen,
I like both ideas: implementing defaults and standards for the storm drain system. Here’s how I see it: defaults are the values assigned to features when the user hasn't specified an explicit value. Most defaults should be set to 0, such as for invert elevations, or to common choices like a circular shape for the pipe. We should be careful to add defaults that fix the empty data field issue but with values that are wrong, for example adding a default (min elevation ) to the invert elevations instead of allowing a zero value.
Standards should be stored in modifiable tables that can be selected and once the user selects a particular standard table then values are used to fill in the tables. We should also allow users to enter their own standard values.
Does that make sense to you?
Noemi
On Wed, Jun 12, 2024 at 10:53 AM Karen @.***> wrote:
Hi Robson,
Both of those ideas sound great. I have some example standards we can take a look at for a few different counties.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2163249294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3XTK2CHVBWEBDTTXRLZHBOHVAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI2DSMRZGQ . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
2 weeks ago Perfectly! That makes sense. I'll try to implement it and bring up a prototype.
FLO-2DNoemi
commented
2 weeks ago Sounds good!
On Wed, Jun 12, 2024 at 12:59 PM Robson Pachaly @.***> wrote:
Perfectly! That makes sense. I'll try to implement it and bring up a prototype.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2163512375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3VOY2KDIWRXO2G7IT3ZHB5ANAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGUYTEMZXGU . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
2 weeks ago Take a look, I really liked it! :)
FLO-2DKaren
commented
2 weeks ago Hi Robson,
Dude this rocks.
If I set a filter so that I was only looking at type2 inlets, it should also apply to your dialog box. Can you make that happen?
When you rotate through the items, should the map pan to the item? I have doubts because I wouldn't want to lose my place.
Does your window dock with FLO-2D panel? I'm sure it does because it's already in that space. If we add tools to it, we'll want it to dock with FLO-2D because I assume it will get bigger.
One think I feel is smart about EPASWMM GUI is that it labels features that your mouse hovers over. So instead of 3 clicks, you only use 1 click to open the dialog for the desired object. If the Dialog box is open, we might adapt the FLO-2D Info tool to a single point system with a label of the pointed feature. I think that is a lot of behind the scenes code but it would be worth it in the long run.
Can we use the same dialog box frame for all features but load a different object into the frame depending on what feature is clicked.
rpachaly
commented
2 weeks ago If I set a filter so that I was only looking at type2 inlets, it should also apply to your dialog box. Can you make that happen?
This can be done, but where would I set this filter? On the top of the dialog maybe?
I usually set the filter by right clicking the layer. I wouldn't bother trying to do it on your form since the layer filter is so good.
When you rotate through the items, should the map pan to the item? I have doubts because I wouldn't want to lose my place.
I can add the "eye" to activate the map panning if the user would like to pan along moving through the junctions. I like the panning because the code is not so intelligent, it does not follow the line but the first node retrieved by the SQL query. That's why I think it is important to have the red rubber and the panning.
I don't think this is easy but it would be pretty cool to only advance through the stuff that is on screen. I don't think its worth trying to code that. Sound buggy.
Does your window dock with FLO-2D panel? I'm sure it does because it's already in that space. If we add tools to it, we'll want it to dock with FLO-2D because I assume it will get bigger.
Yeah, I can do that.
One thing I feel is smart about EPASWMM GUI is that it labels features that your mouse hovers over. So instead of 3 clicks, you only use 1 click to open the dialog for the desired object. If the Dialog box is open, we might adapt the FLO-2D Info tool to a single point system with a label of the pointed feature. I think that is a lot of behind the scenes code but it would be worth it in the long run.
It can be done. I'll find a solution to reduce the number of clicks.
Can we use the same dialog box frame for all features but load a different object into the frame depending on what feature is clicked.
Yes, that is my idea.
Before implementing all these, I'll try to adjust the dialog when adding new features. This is important and it looks a little complicated.
I think this is important too. I think our FLO-2D panel does something like this. It calls widgets from different ui code.
FLO-2DNoemi
commented
2 weeks ago Robson,
This is good. I agree with Karen's comments. Reducing the number of clicks to make the process less tedious is a good idea.
Noemi
On Thu, Jun 13, 2024 at 9:33 AM Robson Pachaly @.***> wrote:
If I set a filter so that I was only looking at type2 inlets, it should also apply to your dialog box. Can you make that happen?
This can be done, but where would I set this filter? On the top of the dialog maybe?
When you rotate through the items, should the map pan to the item? I have doubts because I wouldn't want to lose my place.
I can add the "eye" to activate the map panning if the user would like to pan along moving through the junctions. I like the panning because the code is not so intelligent, it does not follow the line but the first node retrieved by the SQL query. That's why I think it is important to have the red rubber and the panning.
Does your window dock with FLO-2D panel? I'm sure it does because it's already in that space. If we add tools to it, we'll want it to dock with FLO-2D because I assume it will get bigger.
Yeah, I can do that.
One think I feel is smart about EPASWMM GUI is that it labels features that your mouse hovers over. So instead of 3 clicks, you only use 1 click to open the dialog for the desired object. If the Dialog box is open, we might adapt the FLO-2D Info tool to a single point system with a label of the pointed feature. I think that is a lot of behind the scenes code but it would be worth it in the long run.
It can be done. I'll find a solution to reduce the number of clicks.
Can we use the same dialog box frame for all features but load a different object into the frame depending on what feature is clicked.
Yes, that is my idea.
Before implementing all these, I'll try to adjust the dialog when adding new features. This is important and it looks a little complicated.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2165690585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3QTVL5QCBG6647FM3TZHGNRZAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGY4TANJYGU . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
1 week ago Check this out and let me know if I can proceed with this change.
FLO-2DKaren
commented
1 week ago Notes on video
If node is a junction limit the form to junction fields.
If I isn’t first letter of inlet name field show error.
Go ahead and separate outfalls. It may mean we have to modify auto port for projects with storm drain.
FLO-2DKaren
commented
1 week ago That editor is really nice.
FLO-2DNoemi
commented
1 week ago I like the editor, it is really nice. I do not see any issue separating outfalls from other types of nodes like inlets and junctions.
It would also be nice if we could convert features on the fly, for example for nodes, an inlet or junction converts to a storage unit and vice versa. For conduits can be a conduit converted to a weir. Some of the attributes will need to be maintained when the feature is converted. Maybe this is too complicated for implementation in this release but we should add it for the next release.
Noemi
On Thu, Jun 20, 2024 at 12:38 PM Karen @.***> wrote:
That editor is really nice.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2181399282, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3RGN4XDTRYAGBYK4A3ZIMVVBAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBRGM4TSMRYGI . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
1 week ago Hi Noemi,
I like this conversion tool. We can make it very similar to what SWMM has.
rpachaly
commented
1 week ago Hi all,
Please, take a look into this video. I'm thinking about removing the "Components" from the Storm Drain Editor.
FLO-2DKaren
commented
6 days ago Excellent video. This is going to be very good. Here are my thoughts.
[x] I agree that the Attribute Table Editor is much more user friendly, robust, and less likely to cause bugs than the storm drain dialog boxes. Let's go ahead and remove them.
[x] Sometimes when you sort an attribute table, it exports to a dat file in the same order as it is sorted. Let's be careful of this. If our users start using Attribute tables to review or modify data more often, we may see issues related to this.
[x] Can you add a zoom to feature button to your editors? I don't always like the automatic zoom to method because sometimes you want to see the old feature as you are working on the new feature. You don't want the map to pan or zoom away from your current spot.
[ ] The Storm Drain Inlet/Junction layer has several Rendered fields that I think are excellent but they do not belong in that table. How hard would it be to move those to another table. We should talk about the importance of those fields in a meeting.
[x] You have separated outfalls from the node layer which is good but that will change import, export, and geopackage port methods. We'll need to extensively test before we can release this version. So let's take our time with this and get it right.
[x] Let's explore the Find Object tool with EPA SWMM GUI. I get a lot of use out of that tool but it's annoying.
FLO-2DNoemi
commented
6 days ago This is very good and helpful.
I am sending you my comments below in blue:
1.
I agree that the Attribute Table Editor is much more user friendly, robust, and less likely to cause bugs than the storm drain dialog boxes. Let's go ahead and remove them. I agree we can get rid of the storm drain dialog boxes table, and keep data in the attribute table, this will simplify things a lot. 2.
Sometimes when you sort an attribute table, it exports to a dat file in the same order as it is sorted. Let's be careful of this. If our users start using Attribute tables to review or modify data more often, we may see issues related to this. Not sure if Karen is referring to the SD DAT files but my comment is related to that data. SD features data is exported to different DAT files (SWMMFLO.DAT, SWMMOUTF.DAT, SWMM.INP, etc). We need to be careful because once we convert features or make changes on the fly, all the SD data needs to be reexported to different data files. We could see discrepancies between the different data files and INP if we do not export all the updated SD data. For example: when you convert an inlet to a junction, the feature has to be removed from the SWMMFLO.dat file. 3.
Can you add a zoom to feature button to your editors? I don't always like the automatic zoom to method because sometimes you want to see the old feature as you are working on the new feature. You don't want the map to pan or zoom away from your current spot. This is a good idea. 4.
The Storm Drain Inlet/Junction layer has several Rendered fields that I think are excellent but they do not belong in that table. How hard would it be to move those to another table. We should talk about the importance of those fields in a meeting. Karen, I am not sure I understand your comment, let's meet on Friday so we can discuss this. 5.
You have separated outfalls from the node layer which is good but that will change import, export, and geopackage port methods. We'll need to extensively test before we can release this version. So let's take our time with this and get it right. Agree. 6.
Let's explore the Find Object tool with EPA SWMM GUI. I get a lot of use out of that tool but it's annoying. I agree with Karen, I use the Find Object all the time too, especially for Project Review, and it is useful, we also have other ways to find features from the attribute table.
Noemi Sent from my iPhone
On Jun 26, 2024, at 9:28 AM, Karen @.***> wrote:
Excellent video. This is going to be very good. Here are my thoughts.
1.
I agree that the Attribute Table Editor is much more user friendly, robust, and less likely to cause bugs than the storm drain dialog boxes. Let's go ahead and remove them. 2.
Sometimes when you sort an attribute table, it exports to a dat file in the same order as it is sorted. Let's be careful of this. If our users start using Attribute tables to review or modify data more often, we may see issues related to this. 3.
Can you add a zoom to feature button to your editors? I don't always like the automatic zoom to method because sometimes you want to see the old feature as you are working on the new feature. You don't want the map to pan or zoom away from your current spot. 4.
The Storm Drain Inlet/Junction layer has several Rendered fields that I think are excellent but they do not belong in that table. How hard would it be to move those to another table. We should talk about the importance of those fields in a meeting. 5.
You have separated outfalls from the node layer which is good but that will change import, export, and geopackage port methods. We'll need to extensively test before we can release this version. So let's take our time with this and get it right. 6.
Let's explore the Find Object tool with EPA SWMM GUI. I get a lot of use out of that tool but it's annoying.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2191996570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3XF5G2UOFTFRPCIXH3ZJLMZPAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJRHE4TMNJXGA . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
4 days ago Hi all,
I'm implementing what you've suggested. During my testing here, I came up with and idea which I don't know if it worth implementing or not.
It is an auto-assign max depth/invert elevation for the junctions. It will work like this: If the user has Invert Elevation set and Max Depth = 0, the Max Depth = Grid Elevation - Invert Elevation. If the user has Invert Elevation = 0 and Max Depth set, the Invert Elevation = Grid Elevation - Max Depth. What are your thoughts?
FLO-2DNoemi
commented
4 days ago Hi Robson,
We had a feature in GDS that calculated the MAX Depth as Interpolated Grid Elevation minus Invert Elevation. This is worth it.
Calculating the Invert Elevation can be helpful if the user is missing only a few IEs. However, if the project is missing all the IE data, using Grid Elevation minus Max Depth to calculate the IE will result in problematic pipe slopes. Specifically, the system will end up with adverse or very flat slopes, causing the SD to not function as expected.
Noemi
On Fri, Jun 28, 2024 at 7:44 AM Robson Pachaly @.***> wrote:
Hi all,
I'm implementing what you've suggested. During my testing here, I came up with and idea which I don't know if it worth implementing or not.
It is an auto-assign max depth/invert elevation for the junctions. It will work like this: If the user has Invert Elevation set and Max Depth = 0, the Max Depth = Grid Elevation - Invert Elevation. If the user has Invert Elevation = 0 and Max Depth set, the Invert Elevation = Grid Elevation - Max Depth. What are your thoughts?
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2196717446, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3U4R2HLABY73PSPJS3ZJVD77AVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJWG4YTONBUGY . You are receiving this because you were mentioned.Message ID: @.***>
FLO-2DKaren
commented
4 days ago @rpachaly
So it will be the opposite. Like Noemi said. You typically know the invert elevation but the max depth is calculated by subtracting the invert from the grid elevation.
For Type 1, 2, 3, 5
Max depth = Grid elev - invert elev.
It gets a little tricky with type 4 inlets.
If feature = 1, and type = 4, the max depth = the conduit depth. If feature = 0, and type = 4, the max depth = the grid elevation - invert elevation.
rpachaly
commented
4 days ago Quick question:
When we hit the Schematize Storm Drain button, should it schematize both the junctions and the inlets? The code was allowing for junctions but I think this is not correct.
Only Inlets
Junctions and Inlets
The SWMMFLO.DAT is correct, it contains only inlets when exported.
FLO-2DNoemi
commented
4 days ago The junction data has to be exported only to the SWMM.INP. My understanding is that we need the data in the schematic layers to be able to export it to the INP file.
On Fri, Jun 28, 2024 at 4:30 PM Robson Pachaly @.***> wrote:
Quick question:
When we hit the Schematize Storm Drain button, should it schematize both the junctions and the inlets? The code was allowing for junctions but I think this is not correct.
Only Inlets
image.png (view on web) https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/assets/39889306/5908dd94-87b5-49a4-a331-860998763521
Junctions and Inlets
image.png (view on web) https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/assets/39889306/49bbfa1f-eb44-4e73-bad7-9fa02cf85dde
The SWMMFLO.DAT is correct, it contains only inlets when exported.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2197612190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3R3ZZMCHSWETEUKFK3ZJXBVPAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGYYTEMJZGA . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
4 days ago Got it! Thanks Noemi!
FLO-2DKaren
commented
4 days ago Hi Robson,
I think we had junctions in the schema layer because of how we import inp data. I agree with your assessment that it doesn't really belong in that schema layer but we had it there because of how the data is imported and exported. Maybe we should discuss it with Noemi in a meeting nest week.
rpachaly
commented
3 days ago Well, I got a little confused the first time because the junctions are on the schema data but it is not exported to the SWMMFLO.DAT.
The data that is exported to the SWMM.INP comes from the user data. There should be something showing to the user that the data that is going to be exported to the SWMM.INP is schematized. I don't know if I made myself clear hahah
FLO-2DNoemi
commented
3 days ago Hi Robson,
I think I understood :)
I have several questions: Why does the data exported to the SWMM.INP come from the User layers?. It is my understanding that all the data for all components should be exported from the tables of the schematic layers. We also should maintain consistency. Is there a reason for the INP exporting process being set up like this? Does it make sense to fix it? Can we fix it without making big changes to the layer structure? If the data is directly exported from User layers. How do we read the SWMM.INP data file? Is it a different process than other components?
Sorry for all the questions but I think we should understand the implications of it to make the appropriate changes.
Noemi
On Sat, Jun 29, 2024 at 9:35 AM Robson Pachaly @.***> wrote:
Well, I got a little confused the first time because the junctions are on the schema data but it is not exported to the SWMMFLO.DAT.
The data that is exported to the SWMM.INP comes from the user data. There should be something showing to the user that the data that is going to be exported to the SWMM.INP is schematized. I don't know if I made myself clear hahah
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2198196782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3T2WFTTMAJS7GCCVBTZJ2Z27AVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGE4TMNZYGI . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
3 days ago Why does the data exported to the SWMM.INP come from the User layers? Is there a reason for the INP exporting process being set up like this?
These are good questions, I also don't know why. Maybe because the data is already correctly set on the user layers and it is quicker to export from there?
Does it make sense to fix it?
I think we need to have this data schematized for exporting to SWMM.INP to maintain the consistency. So, I think it makes sense to fix it.
Can we fix it without making big changes to the layer structure?
We will not change the layer structure. We need to basically add 7 layers to the geopackage that will be the schematized swmm layers and copy the user swmm layers to these new schema layers.
How do we read the SWMM.INP data file? Is it a different process than other components?
We import the SWMM.INP into the user_swmm layers and then export it along the other .DAT files (or alone using the Export to INP). I think we should keep the "Import from INP" this way, then the user can see the imported data on the user layers, perform modifications (or not) and then schematize this data for exporting.
FLO-2DNoemi
commented
3 days ago Robson,
I agree we should make the changes to keep consistency in the plugin and make the necessary changes to organize the read and write process of the INP file.
Noemi
On Sat, Jun 29, 2024 at 10:34 AM Robson Pachaly @.***> wrote:
Why does the data exported to the SWMM.INP come from the User layers? Is there a reason for the INP exporting process being set up like this?
These are good questions, I also don't know why. Maybe because the data is already correctly set on the user layers and it is quicker to export from there?
Does it make sense to fix it?
I think we need to have this data schematized for exporting to SWMM.INP to maintain the consistency. So, I think it makes sense to fix it.
Can we fix it without making big changes to the layer structure?
We will not change the layer structure. We need to basically add 7 layers to the geopackage that will be the schematized swmm layers and copy the user swmm layers to these new schema layers.
How do we read the SWMM.INP data file? Is it a different process than other components?
We import the SWMM.INP into the user_swmm layers and then export it along the other .DAT files (or alone using the Export to INP). I think we should keep the "Import from INP" this way, then the user can see the imported data on the user layers, perform modifications (or not) and then schematize this data for exporting.
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2198215585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3WRZTFFBVUPPTRLGRDZJ3AZFAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGIYTKNJYGU . You are receiving this because you were mentioned.Message ID: @.***>
rpachaly
commented
3 days ago Ok! I'll do it. It would be better.
FLO-2DKaren
commented
3 days ago That is a significant change. We didn't make this change because it seemed like too much work.
I'm OK with you rebuilding the system but let's make sure we can add this checklist to our testing process.
If you all can think of anything else, put it here and we'll add this to our testing steps.
rpachaly
commented
1 day ago About this:
Sometimes when you sort an attribute table, it exports to a dat file in the same order as it is sorted. Let's be careful of this. If our users start using Attribute tables to review or modify data more often, we may see issues related to this.
Prior to exporting, it should be sorted based on what? Grid element? fid? Name?
FLO-2DKaren
commented
1 day ago @FLO-2DNoemi Robson wants to sort the inp inlet/junction and outfall groups by name. He will have the swmmflo.dat and swmmoutf.dat in the same order.
What about the Rating Table data? Does that need to be in a certain order?
FLO-2DNoemi
commented
1 day ago No, not at all. The SWMMFLORT does not need to be in the same order.
On Mon, Jul 1, 2024 at 11:54 AM Karen @.***> wrote:
@FLO-2DNoemi https://github.com/FLO-2DNoemi Robson wants to sort the inp inlet/junction and outfall groups by name. He will have the swmmflo.dat and swmmoutf.dat in the same order.
What about the Rating Table data? Does that need to be in a certain order?
— Reply to this email directly, view it on GitHub https://github.com/FLO-2DSoftware/qgis-flo-2d-plugin/issues/1370#issuecomment-2200515579, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE32O3TPWLG6RIIKMSXASDLZKF3RRAVCNFSM6AAAAABIZR2ASOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGUYTKNJXHE . You are receiving this because you were mentioned.Message ID: @.***>
Robson will take the lead on this.
Robson, If we can't fix this by June 30, that's OK. It's kind of a big task.
The problem is that when we import an INP, we have no way to easily modify it because the editors are all connected to the wrong data tables. We need our editors to be connected to User Layers and the schematize button should fill schema data.
I have videos and test projects ready to go in this link.
https://flo-2d.sharefile.com/d-s012b10dd23c743879c5220e6e0bb6c34