If I look at it in the flat mode, the borders are correct.
If I look at it in the surface mode, a wrong area is showed as protected.

Flat mode:

Surface mode:

@RWoof, I can't see any dynmap hook for claims on that map right now but it's interesting that you have the issue on both GriefDefender and GriefPrevention.

In GriefDefender, do new claims do the same thing, or are you just testing with claims migrated from GriefPrevention?

Could you try two things? Firstly add a world size of something like 100 blocks each way, then add some blocks on the border in your world and see if that lines up on your ISO30 view?
Secondly could you try adding a new view (say ISO30 but from a different direction) and see if that's any different?

If you look at one of the claim data files in griefdefender (plugins/GriefDefender/worlds/normal/world/ClaimData/basic), what are the Y heights?

I am having this same issue with the newest versions of dynmap and in both GriefPrevention (using LeahShields95 plugin) and GriefDefender. My claims are offset in surface mode exactly the same as MartinX3 showed in his photos. You can see this on my server map, lilasakura.ga/map

Any ideas on how to fix it? It almost seems like the land claim layer is too low?

@RobinWhitfield Thanks for the quick reply and sorry for the lack of griefPrevention overlay. I worked on GriefDefender for hours trying to set it up and eventually gave up and rolled back to GriefPrevention pre-map layer. The claims I was testing were imported from GriefPrevention and my map was originally brought over from single player. I also tried deleting the dynmap folder and rerendering using SQLite instead of file tree with the same result. I've reinstalled the layer plugin and will reboot when possible. I'll try the things you suggested, I'm assuming I'll need the world border plugin to do this? I'll be able to work on it later after work and I'll get back to you!

@RWoof, you can just use the default /worldborder command to set a border. Dynmap will then display this border automatically.

Just trying to work out right now whether it's an issue within dynmap that shows with any 2D box (such as the worldborder) or whether the issue is specific to GriefPrevention/GriefDefender.

@RobinWhitfield Thanks, I'll give it a shot when I can, I've re-enabled the layer for GP on my map now, I think you might be onto something with the Y values as my claims near sea level look much more accurate than ones on hills or uneven terrain, maybe I can try making a few claims at differing heights to see how things look on the map. Thanks for your help, I'll keep you posted as soon as I can get the chance to work on the server a bit!

Upon further thinking, I believe the get height function in GriefPrevention is using Z since it is calculating a 2D box referencing X and Z, Y is referenced elsewhere but the GriefPrevention Dynmap plugins use the get height function that uses Z instead of Y.

@RWoof, I can't see any dynmap hook for claims on that map right now but it's interesting that you have the issue on both GriefDefender and GriefPrevention.

In GriefDefender, do new claims do the same thing, or are you just testing with claims migrated from GriefPrevention?

Could you try two things? Firstly add a world size of something like 100 blocks each way, then add some blocks on the border in your world and see if that lines up on your ISO30 view?
Secondly could you try adding a new view (say ISO30 but from a different direction) and see if that's any different?

If you look at one of the claim data files in griefdefender (plugins/GriefDefender/worlds/normal/world/ClaimData/basic), what are the Y heights?

@RobinWhitfield I was able to test out the Y value, I've made 2 admin claims on my map, one is approximately at X -25 Z -380 (using mouse coords from the map) at sea level (using the /height command) and the other is at 84 -381 on top of the hill at 32 blocks above sea level. I've marked the boundaries with dark oak logs. You will see that the claim at sea level follows the marker blocks perfectly, while the claim at the higher height is very far off the markers. I put one dark_oak block at the lower corner of the falsely-located claim, when I stand on that block, I'm at 12 blocks above sea level and at 142 -324. Sea level on my map appears to be Y64. It's almost like as the claims get higher, the Y value is at a certain percentage less than it should be?

Update
I had a look at the java file for the Griefprevention Dynmap plugin and it seems to be referencing claims.getheight to figure out the Y value. I was able to find this function in the Griefprevention github here: https://github.com/TechFortress/GriefPrevention/blob/master/src/main/java/me/ryanhamshire/GriefPrevention/Claim.java

Here is the line I think is calculating the height, I'm a complete newbie so I could be wrong:

public int getHeight()
{
    return this.greaterBoundaryCorner.getBlockZ() - this.lesserBoundaryCorner.getBlockZ() + 1;
}

Here's something interesting, when I look at the claim that was off the markers, if I do the calculation, greater boundary corner in GriefProtection is Z -337 and lesser is -348. The difference is exactly 11 blocks which is the position of the height of the misaligned claim!

Update 2
I checked the github for GriefDefender, they seem to use this formula to calculate height, at least sometimes, not sure what the Override is... The link is here: https://github.com/bloodmc/GriefDefender/blob/master/bukkit/src/main/java/com/griefdefender/claim/GDClaim.java

@Override
public int getHeight() {
    return this.greaterBoundaryCorner.getY() - this.lesserBoundaryCorner.getY() + 1;
}

Both plugins have slightly different boolean inClaim functions in those files as well to determine if a player is inside a claim or not.

GriefPrevention seems to ignore the Y value in that function, but I believe it must be calculated somewhere to protect 5 blocks under the Y value. When I go to my claim on top of the hill, blocks are owned until I get to about 6 blocks down into the hill. They don't extend right down to sea level or lower. Perhaps if GriefPrevention corrected the getheight function to use Y instead of Z it would fix the map layer? Not sure if it would break anything else. I'm not sure why GriefDefender didn't show my claims properly with it's formula but maybe the Y values got mixed up somehow during migration if they relied on any function in GriefPrevention. Unfortunately I've uninstalled GriefDefender so I can't test that. I posted an issue on the GriefPrevention github for them to have a look at. Bedtime for me now, I'm looking forward to your input on this! Thanks for your help!

@RWoof, looking at your map, I can't see an issue the same as the original issue.

Your claims appear to be being rendered at sea level (which is what you'd expect for 2D claims, as they don't contain info on the ground height or the height at which you originally placed them).
Even for 3D claims I'd expect them to be rendered at sea level as otherwise you'd need to calculate the box location based on the claim height and the ISO view that has been rendered.

@MartinX3's claims on the other hand appear to be being rendered a number of blocks below sea level.

Thinking about the original issue, I do wonder whether it's an issue with that specific render and whether doing a full render would shift everything over to the right place.

Adding a worldborder should make it obvious if that's the case.

Ahh, that's interesting. It seems that GriefDefender 2D claims show the lesser as 0 and the greater as 255, which wouldn't allow you to draw the claim at the placed location, but for that a 3D view may work better anyway.

I'd forgotten that indeed Dynmap can draw 3D regions on an ISO view. Redprotect's dynmap hook (and others) give you the option for that.

I guess that both GriefDefender and the GriefPreventionDynmap plugin really could do with a 3D option, and a custom sea level height for 2D regions (for custom worlds).

On a somewhat related note, I get the feeling that someone (not the developer of the plugin) could do with doing a bit of a guide for how to set up GriefDefender. It's a very powerful plugin, but it can be very confusing and quite tricky even just to get it set up in the way that people might expect it to be set up, and the troubleshooting suggestions are often "read the wiki". Maybe I'll give that a go at some point as we're just about set up and happy.

@RWoof, looking at your map, I can't see an issue the same as the original issue.

Your claims appear to be being rendered at sea level (which is what you'd expect for 2D claims, as they don't contain info on the ground height or the height at which you originally placed them).
Even for 3D claims I'd expect them to be rendered at sea level as otherwise you'd need to calculate the box location based on the claim height and the ISO view that has been rendered.

@MartinX3's claims on the other hand appear to be being rendered a number of blocks below sea level.

@RobinWhitfield Thanks for your help, the GriefPrevention claim data files actually do contain a Y value for the claims, however, I don't think it's being used in the GriefPrevention-Dynmap plugins when creating the area marker, so the marker isn't at the correct height. Here is the yml for the GriefPrevention claim that is on top of the hill:

Lesser Boundary Corner: hello new world im dino girl;116;89;-348
Greater Boundary Corner: hello new world im dino girl;129;89;-337
Owner: ''
Builders: []
Containers: []
Accessors: []
Managers: []
Parent Claim ID: -1
inheritNothing: false

I think there should be a way to use the height of 89 to generate the area marker at that Y value on the map using the dynmap core api? I checked all of my claim files and they all have a Y value and all of them are the same number in greater and lesser (2D).

I've disabled the GP overlay on my map for now, I like the idea of it, but it's a bit weird and confusing on the surface map with things being offset on higher ground. Thanks for all of your help and knowledge trying to figure things out.

Since you mentioned GriefDefender, I will describe my experience with it. Maybe someday I'll try it again (especially if GriefPrevention becomes obsolete), I didn't have enough time when I installed it to really get in depth and figure things out and the default settings were not good for my server. Since the plugin page looks so similar to GriefPrevention's I thought it was the same plugin with extra features and more customization options, however once I installed it and migrated the data I saw how different things were.

The documentation in the config files was not easy enough for me to understand how to configure things properly, I didn't know what format to put things in between the brackets and braces and every time I made a mistake, the config file would reset and I'd have to start over. I couldn't figure out how to disable phantoms from spawning in the world, and the default settings allowed lava buckets, TNT block damage and creeper block damage in the wilderness which I suppose is OK in some worlds but I didn't want players dumping lava everywhere and blowing up holes in my map.

I also found that unlike GriefPrevention, the GriefDefender commands did not show in EssentialsX /help even when I tried to add permissions like essentials.help.* essentials.help.gd essentials.help.griefdefender to my user group in luckperms and there didn't seem to be any instruction manuals to deliver to new users like GriefPrevention offers. As far as I could see in my limited experiment, if a player doesn't know the /gp help command, they won't see help for GriefDefender anywhere. The menus and help being shown in chat is cool, but you can't interact with it unless you press "t" again and most of it is cut off until you press "t" so that might be confusing as well for some players. The /gp help seemed to show all commands without checking to see if a user had permission to use them or not, showing a bunch of useless commands to users.

All in all, I found GriefPrevention a much more user-friendly, plug-and-play initial experience where GriefDefender, while likely superior in many ways, was less user-friendly, lacking the documentation for someone like me to be able to configure it properly, and I found the default settings allowed too many potential problems on my server. I agree with you that if there was a better wiki or more user-friendly documentation in the config files, it would be very helpful. It might also be nice to have the default config prevent forms of griefing even in the wilderness, until the sever owner decides what they want to allow and what not.

Which version of dynmap are you running, and which dynmap plugin (and version) are you using for GriefPrevention?

This one? https://www.spigotmc.org/resources/grief-prevention-dynmap-support.2881/
Or this one? https://dev.bukkit.org/projects/dynmap-griefprevention
Or perhaps another one?

This sounds to me like a plugin issue rather than a dynmap issue.

Using GriefDefender (which is similar to GriefPrevention in its Dynmap hook) with its inbuilt dynmap support, the location of the area is shown correctly (at sea level)

I'll fire up an old server with GriefPrevention to see what the (mofidied) plugin I used to use did for me. I don't remember it being off the mark though

With a modified plugin (https://github.com/leahshields95/GriefPreventionDynmap - updates still to come before pull requests into master but feel free to buid it yourself), the regions are lined up with dynmap (iso_SE_30_vlowres used for testing)

This test server is running MC 1.15.2 on Paper 161 with GriefPrevention 16.13.0 and GriefPreventionDynmap-1.4-SNAPSHOT

@MartinX3 - any updates on your issue?

Oh, sorry
I was busy
I better tag our server administrator :)

@Gouster4 please report