Legend Code

Sadly the problem still persists. I created an image with 100x40 pixels like metioned here (How To Add Hatch Patterns to New Geologies - OpenGround Wiki - OpenGround | gINT | Keynetix - Bentley Communities). Its displayed in the log, but there is no difference to before. Its still almost 4 times smaller and you can imagine what it looks like compared to the "default" ones in the graphics bar. Even if i create a graphics bar dependent on the image size, its still stretched. Ticking the box "FitToWidth" is stretching the image in both variants too. Am I missing something?

Hi Daniel, it's hard to say. Would it be possible to upload your image file and some screen shots of your graphics bar. And just to make sure... is the width of the image 100 pixels? 

Hi Daniel, it's hard to say. Would it be possible to upload your image file and some screen shots of your graphics bar. And just to make sure... is the width of the image 100 pixels? 

Hey Jesse,

I tried different things and in case of having the wrong width I created different images.
The image size is in the picture (pixels).
The numbers and the images do not matter, its just for testing.
I really want to understand why its behaving like this.
I added some default images for comparison.

If I go with How To Add Hatch Patterns to New Geologies - OpenGround Wiki - OpenGround | gINT | Keynetix - Bentley Communities ,
the image size of the default ones is 100x40. So my images in 100x40 (or 40x100 in case i got it wrong) should be displayed like  the default ones. But they arent. In "Fit to width" you can argue that its stretched the same way, but why is it without "fit to width" so different.
The only image thats getting similar results like the default without "fit to width" is the 100x100, but only with "fit to width".
Because this is a template i created just for testing i made the graphics bar cloumn 10mm wide so each image with 
84 pixels width should fit. Like mentioned here communities.bentley.com/.../how-do-material-symbols-legend-codes-work .
But the one with 84 pixels doesnt fit either way, but the default 100x40 reacts perfectly to the column size without "fit to width".
Its just very confusing. And without knowing how exactly this works and should be done, I cant create a Picklist for the norms of Germany.
Sadly there are none in OpenGround yet.
I hope this is understandable and someone can may help. 
Thanks for your effort anyway so far!

Well, I fought myself halfway through it. The conclusion sadly is, that the only possibility is, to have the image in the correct size for the column width. And if the column size changes i need to adjust the images too. But through these tests i found out, that the correct image width for 10mm would be 100 pixels and not 84.Thats not quiet efficient work. Problem for me is, I need to layer two hatch patterns exactly on top each other and they can repeat downwards but cant repeat sideways cause it wouldnt longer serve the german norm.

Hi Daniel, sorry for the challenges. It can be a bit tricky to create the images and get the tiling/sizing right sometimes.

It is hard to tell what is going on without seeing the actual image files you are using for your custom graphics. How are you determining the dimensions of your images? The screen-shots above indicate they might be a bit narrower than the dimensions listed, but it's hard to tell for certain. For example, if you right-click on the image files in Windows Explorer, what are the dimensions listed in the Details tab?

I'm not sure the conclusion that the "correct image width for 10 mm would be 100 pixels not 84" is correct though (but happy to change my mind if there's something I'm missing)...

The graphic from 1.90 to 2.40 looks like the 101/TOPSOIL graphic in the standard BS/UK config packs:

That image is 100x40 pixels so would be ideally suited for a 12 mm column per the chart in link above. In your image on the left above where you use FitToWidth, you can see it is compressed horizontally into the 10 mm column compared to the original graphic. In your image on the right without FitToWidth, you can see it has the same aspect ratio as the original graphic, but the pattern gets cut-off slightly because the 100 pixel width is a bit to wide for the 10 mm column.

I'm seeing similar for the graphic at 2.90 which looks like 305/Organic SILT.

Anyway, please let us know if you are experiencing something different. It would be good to understand if so. Thank you.

I got the dimensions for my images exactly in the same way you got them.
From the details tab in windows explorer. Before that i created them with GIMP and determing the exact pixels in settings.
I just skipped the snapshot part for each details, sorry about that.
But here are the graphics: (please keep in mind, they are just some random examples without any purpose, in case your are wondering about the depiction)
         

Yes, they are the 101/TOPSOIL and 305/Organic SILT graphics.
Thats the confusing part. I got graphics with the same dimensions but they act totally different.
Maybe I have to ad that my graphics are .png.
And the other one still is, that i dont understand why the 100x100 is looking best in the 10mm column.

For explanation: 
I'm working in Germany and the norms and short forms are quiet different to them in GB for example.
For me its more about how to layer different graphics on top of each other with different picklists to match the german norm.
Longterm there are graphics needed for each main soil and rock type, for each soil/soil, soil/rock, rock/soil combination, each sub type (this, for example, needs to be a graphic. that just has a hatch pattern on the right half of the graphic) and graphics for each color determined by the first main type. And lets just not talk about how the german norm wants anthropogenic soils to be treated and displayed. 
It would be very nice to use OpenGround the way its supposed to be used, because we also use Leapfrog for example.
But you can imagine how many graphics and combinations are needed to be displayed.
Without a database for all this it can't be used propperly in Germany.
Would be interesting to know, if there are any plans from Bentley to create such a database and provide it to the customer for the norms of other countries. Because other Software solutions are doing this and it becomes hard to argue, why OpenGround is the way to go.

Still, many thanks for your help!

Hi Daniel,

Thank you so much for the detailed input. It is extremely helpful. I was able to replicate what you are experiencing, and I think figured out what is going on...

By default, GIMP uses a default resolution of 300 ppi when creating new images. If you create images at that resolution using the pixel dimensions suggested in this Wiki article, it will make them print much smaller. If you change that to 96 ppi, the images will behave and print as suggested in the Wiki article.

I have updated the Wiki article with a note that the suggested pixel dimensions are for a 96 ppi image.

(Sorry, we had not come across this issue before, but thanks for the details to help identify it.)

As far as your general feedback... We are planning to review how OpenGround manages graphics/symbols. And we are also looking to provide standard configurations for additional regions. I will share your feedback with the rest of the team as we plan for those efforts.