fixing .geojson file not supported with mac os

[congchen1101]

FixBug .geojson file not supported in macos.

• In macOS .geojson file will be identified as type of "application/geo+json". So in checkFileType and readFile functions, they will not go into MIME_LOOKUPS list to find the corresponding type.
• Check first in MIME_LOOKUPS list and then the file.type will solve this problem. On behalf of DB Systel GmbH

Description

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• This is a minimal change in code, so a test and doc was not added

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

What is the current behavior?

#10081

What is the new behavior?
now import geojson is also supported with macOS

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

“On behalf of DB Systel GmbH”

[offtherailz]

Thank you for your contribution.
This quick fix could be ok, but the most correct solution could also be to support the mime-type in the code.
I'd also add a unit test to preserve this functionality across maintainance.

[congchen1101]

Thank you for your suggestions. While attempting to add unit tests, I discovered that unit tests for reading geojson files already existed. This led me to wonder why those tests were passing despite the issues at hand. Upon further investigation into the existing tests in processFiles-test.jsx, I noticed that most of them utilize the getFile method from testData.js. This method employs an axios.get call to read files from local test resources, attempting to extract the response-type value from the headers as the type to create a new Blob object, which is then used to create a File object.

# code before fix
export const getFile = (url, fileName = "file") =>
    Rx.Observable.defer( () => axios.get(url, {
        responseType: 'arraybuffer'
    }))
        .map( res => {
            return new File([new Blob([res.data], {type: res.headers['response-type']})], fileName);
        });

However, I encountered two main issues.

1. The res.headers does not contain a response-type, meaning that all newly created Blob objects lack a type attribute. This flaw explains why all current tests could pass: the absence of a type attribute in the checks leads the code to searching file extend in MIME_LOOKUPS table for the corresponding type.
2. Even after adjusting response-type to content-type, which allowed the new Blob object to successfully have a type property, the new File object still failed to inherit the Blob's type attribute.

Given these observations, I opted to directly assign the content-type as the type value when creating the new File object, rather than doing so during the Blob object's creation. This approach ensures that the intended file type is recognized correctly in tests.

# code after fix
export const getFile = (url, fileName = "file") =>
    Rx.Observable.defer( () => axios.get(url, {
        responseType: 'arraybuffer'
    }))
        .map( res => {
            const contentType = res.headers['content-type'] === 'null' ? undefined : res.headers['content-type'];
            return new File([res.data], fileName, {type: contentType});
        });

I've now also added code to support geojson. However, I noticed that the readGeoJson method returns an object includes an errors list. Currently, my code does not perform any actions based on the presence of errors in this list, such as throwing a new Error. Implementing such behavior would lead to the failure of existing tests, as the caput-mundi.geojson file in test resources include the crs attribute. This triggers the error 'old-style crs member is not recommended, this object is equivalent to the default and should be removed' when the geojsonhint method is called within readGeoJson.

I would greatly appreciate any further advice you could provide. Thank you.

[dsuren1]

@tdipisa @offtherailz Since this scenario can be tested effectively only on mac. Can I test and proceed with the backport?

[tdipisa]

You can test with MAC but let's also wait for functional tests as usual made by @ElenaGallo. No? Did I miss something?

[dsuren1]

@tdipisa @ElenaGallo Works fine in DEV and tested on a Mac with geosjon file

[ElenaGallo]

testpassed, @dsuren1 please backport to 2024.02.xx. Thanks