Extent buffer

[FilipLeitner]

Description

Please give a short description of the changes you propose. Please use prose and try not to be too technical, if possible. Make sure to mention people that you think should know about the PR.

Related issues or pull requests

Please list issues or pull requests that the changes you propose are related to. It does not matter if they are still open and/or unmerged, any link is appreciated.

Pull request type

Please check the type of change your PR introduces:

• [ ] Bugfix
• [ ] Feature
• [ ] Dependency updates
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] Documentation content changes
• [ ] Other (please describe)
• [ ] I am unsure (we'll look into it together)

Do you introduce a breaking change?

• [ ] Yes
• [ ] No
• [ ] I am unsure (no worries, we'll find out)

Checklist

• [x] I understand and agree that the changes in this PR will be licensed under the [MIT License]
• [ ] I have followed the guidelines for contributing
• [ ] The proposed change fits to the content of the code of conduct
• [ ] I have added or updated tests and documentation, and the test suite passes (run npm test locally)
• [ ] I'm lost; why do I have to check so many boxes? Please help!

[FilipLeitner]

Reliably buffering the extent seem to be quite a task.

• previous implementation was failing for local projections such as EPSG:5514 where simple comaprison with projected bounds of WGS84 is just not possible. apart from that the buffer size or large extents got above the bounds quite easily
• trying to transform enlarged extent into WGS84 doesnt really solves anything as the trasnformation returns NaN for overflowed latitudes and nonsense for overflowed longitude (because theres basically no scuh thing since we operate on globe).
• thats why I opted for manually defined bounds for each projection while trying to somehow manage the size of the buffer. This however creates a constraint and prevents us from displaying data outside the bounds, which is teoretically correct but from the technical point of view not so much (because theres no real issue with that...maybe if we were to automatically set maximum map extent along with the view it would be less confusing)

Stll work in progress tho ..needs some manuall testing or pereferably refactoring which would solve the problem without adding constraints or too much complexity 😄

EDIT: -maybe we could try to define some function to calculatebuffer factor based on the length (maybe diagonal if we were to sue one number for both widht and height) of extent with some sort of limit lets say, 3000km where there would be no buffer applied? So we dont have to test for projected bounds. Something along this line migth work most of the time something like..but we acn play around

[FilipLeitner]

In b26bcb8 Ive reverted many changes and implemented polynomial function to scale buffer factor based on extents' diagonal length instead of checking the bounds against the predefined extent.

Function used scales factor from 0.12 for small extents down to to 0 for the extents with diagonal length of more than 4000km (somewhat random number taht could be adjusted). It looks somewhat like this

Combination

Problem with possible combination of both solutions (polynomial factor + some sort of world boundary chcek) is that we cant really get rid of the 'per projection' bounds completly.

We could thoretically transform each extent into EPSG:4087 and compare against bounds of this projection. However,

• does NOT work correctly for invalid inputs such as WGS84 extent of [-190,50,180,60] ( error in longitude) because the transformation to 4087 would 'fix' the outlier (-190) . Preventing this is not possible unless we check the original input extent -> bringing us back to the need of per-projection-bound

• ~trasformations on the edge of the projected bounds doesnt seem to be very precise. For example projected bounds of EPSG:4087 on EPSG.io~

@fzadrazil

[FilipLeitner]

Well this is kinda insane.... our 4087 def is just wrong. No idea how. It should not be

    proj4.defs(
      'EPSG:4087',
      '+proj=cea +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs',
    );

but

proj4.defs(
  'EPSG:4087',
  '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +type=crs',
);

honestly have no idea how I managed to screw this up :D

[jmacura]

Well this is kinda insane.... our 4087 def is just wrong. No idea how. It should not be

    proj4.defs(
      'EPSG:4087',
      '+proj=cea +lon_0=0 +lat_ts=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs',
    );

Hmm... looks like Lambert cylindrical equal-area projection to me 🤔

honestly have no idea how I managed to screw this up :D

Shit happens 😄

[FilipLeitner]

Wonder how would something like map resolution * some pixel value (ideally size of the symbol I guess) work .

Because I mean...the resolution is a measure of how many map units per pixel are currently being displayed on the map...this would allow us to increas the extent in a terms of pixels. However, results would differ based on the current 'zoom level' of the map eg. zoom level at the time of layer creation.

[fzadrazil]

Wonder how would something like map resolution * some pixel value (ideally size of the symbol I guess) work .

Yep, but the big issue is still the unknown size of the symbol. If we know this, the problem would be solved. Let's try it as it is and see what occurs in real life :-)