Katarina Ollikainen

@Tom W., I'm sorry you're experiencing this and that the changes have had a negative impact on this workflow. The feeding of classes to the JPO is the bug I was talking about in the video - this will be fixed in the next update. I'll talk to the engineers today about the issue you see with the class being ignored and get back to you as soon as we've looked into it.

@HebHeb, the same goes for you - I'll see what we can do. I'm delighted to hear that you all are working with styled objects. This is definitely the most efficient way to work in the long run, even if there are times when unstyled objects are a quick fix.

@Tom W., I do understand your point, and I'm definitely not rejecting the use of classes - we only want to make it easier to work without being dependent of them. I'll discuss with the engineers if we can support your workflow explained here.

@Jonk, @Tom W., @Anders Blomberg, @HebHeb, I have made a recording of the landscape area and hardscape functions here. Please let me know if there are issues I haven't covered - I'm happy to add more info. It would be interesting to know if you all are working primarily with styled objects or unstyled ones - many of the changes in 2024 U4 happened because of feedback from customers working with unstyled objects. This requires different functionalities than if you have set up your library with finished styles. We're trying to create the objects so you can set as many attributes as possible within the style, without the need for class attributes. This doesn't mean that you can't use class attributes—it only means that you don't have to. You shouldn't need to set up a multitude of classes to change the attributes. However, we recognise situations where a class override is very efficient, so you have both alternatives. Hardscape and landscape area.mp4

@Benson Shaw, let me check with the engineers and see where we are with this. I agree - it's not good that you must do a manual conversion. Can I check with you regarding the workaround? You mention importing to a blank non-georeferenced file. Currently, all files have the georeferencing 'turned on' by default. Are you using a script to 'turn it off', or do you mean a file where you haven't specified a coordinate system? I'm only asking so I can compare results and ensure we don't break existing workflows. (This will be addressed so you can have files without the georeferencing system applied, but this change will affect many of the import alternatives, so we must test it thoroughly first).

@Tom W., yes, I've looked at it and I'll post a recording on the hardscape and what to expect later today - we're finalising what we think will the best solution on the collision between the JPO and the base area. Thank you for testing this.

@Anders Blomberg, do you have a file you can share with me so I can see what's happening?

@Tom W., here is the first of the issues you highlighted. It seems to be connected to the same issue as @Jonk had, with the resetting working different via the object settings and the style settings, and there seem to be a 'one-click-delay' before the settings kick in. I'll come back to the other issues you raised as soon as I have more info on them. Class attributes.mp4

@Jonk, here is a recording on how to fix your hardscape objects. Hardscape with tiles.mp4 @Tom W.,

@Jonk, we had a long meeting about the hardscape this morning and we've found an easier way to fix these hardscape (a temporary fix, so you can keep working with them. Of course, this will be addressed within Landmark as well). I'll create a quick recording for you within the next hour. If you apply it, please let me know if it fixes your issue. @Tom W., I'll address your questions above as well at the same time.

@Tom W., I believe that the double layer system came from the request (many years ago) to have a gradient in the background and a JPO over that. They should be completely separate settings that have nothing to do with each other regarding attributes. In the image, the basefill is green, the JPO is flagstone and it has its attributes from the AA class (no fill, orange pen). Now, if you use a tile or hatch with background, then you don't need the base fill, as it will cover it. OR, you can just add the tile to the base fill and not use the JPO. That the whole hardscape disappear if you turn off the class you have for the JPO seems buggy - if you do the same with a plant cloud or plant line on a Landscape area, only that part of the object is made invisible. I'll bring this up tomorrow as well. We're creating the features not to rely on class attributes - you should be able to use the objects and set the attributes directly in the style settings instead of having to use classes. Otherwise, you'll need different classes for every combination of attributes. This doesn't mean that you can't use them, only that you shouldn't have to if you want the style to steer the attributes. Let me know if I'm not covering your question.

@Jonk, Ok, I've looked at the file you sent over - it seems like there is a bug. If I unstyle the hardscape and then create a style of it again, then it works perfectly, so there is something that was introduced between 2024 and now. I'm meeting with the engineers tomorrow morning and will bring this up to see what we can do and will update you after that.

@Jonk - I haven't noticed this. Do you have an example? And is this on hardscape created in 2025 or earlier, or both?

@Amanda McDermott, it was only that the site model had to be updated. I responded separately as there were other things we dealt with in the file 🙂.

Hi @jsundine, I've responded directly to you.