[SEDONA-434] Improve reliability by resolve the nondeterministic of the order of the Map

[MyEnthusiastic]

Did you read the Contributor Guide?

• Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

• Yes, the URL of the associated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-434

What changes were proposed in this PR?

Problem :

when the program reading from the newRdd, it assumes the order of the data to read into the Map

sedona/spark/common/src/test/java/org/apache/sedona/core/formatMapper/GeoJsonIOTest.java

Line 106 in a649720

String[] newGeomFields = newGeom.getUserData().toString().split("\t");

However, when it write the data, it did not assume the order according to the Oracle's official document

sedona/spark/common/src/main/java/org/apache/sedona/core/spatialRDD/SpatialRDD.java

Lines 571 to 572 in a649720

	Map<String, Object> fields = new HashMap<String, Object>();
	String[] fieldValues = spatialObject.getUserData().toString().split("\t");

So it will cause the ERROR when the environment has been changed

org.junit.ComparisonFailure: expected:<0[1]> but was:<0[23]>

	at org.junit.Assert.assertEquals(Assert.java:117)
	at org.junit.Assert.assertEquals(Assert.java:146)
	at org.apache.sedona.core.formatMapper.GeoJsonIOTest.testReadWriteGeoJson(GeoJsonIOTest.java:115)

Solution

So we can change the Map to use the LinkedHashMap to guarantee the order to solve the problem

How was this patch tested?

This error can be reproduced with the NondexTool with the following command (you can try that without modifying the pom, but feel free to use the plugin to protect your project and make it safer 😊 ), and this kind problem is widely documented in International Dataset of Flaky Tests (IDoFT)

Did this PR include necessary documentation updates?

• No, this PR does not affect any functionality public API, only improve the security by making the order deterministic

[Kontinuation]

Thank you for identifying a bug in the GeoJSON reader. While the proposed fix is appreciated, there is one more important issue we need to fix. The key issue is that the GeoJSON reader should have the capability to process GeoJSONs with properties in random orders within the same dataset.

Additionally, ensuring the consistent ordering of properties in GeoJSON files generated by Sedona is a valuable feature. It appears that this pull request addresses that aspect.

[jiayuasu]

@MyEnthusiastic Thanks for the PR. We will address the other problem mentioned by @Kontinuation separately.