Bump geo from 3.6.0 to 4.0.0

[dependabot]

Bumps geo from 3.6.0 to 4.0.0.

Release notes

Sourced from geo's releases.

v4.0.0

Potentially breaking change: Default decoded GeoJSON to SRID 4326 (WGS 84)

This aligns our GeoJSON decoding with the GeoJSON spec by making all decoded GeoJSON infer the WGS 84 datum (SRID 4326) by default. Whereas previously when you called Geo.JSON.decode/1 or decode!/1, we would return geometries with an :srid of nil, we now return srid: 4326. Likewise when encoding GeoJSON, we explicitly output a crs field indicating the datum.

This is unlikely to break real-world usage unless your implementation was assuming a different datum by default.

A couple examples of the changes:

Before:

iex> Geo.JSON.decode!(%{"type" => "Point", "coordinates" => [1.0, 2.0]})
%Geo.Point{
  coordinates: {1.0, 2.0},
  # Note the old default nil SRID!
  srid: nil
}

After

iex> Geo.JSON.decode!(%{"type" => "Point", "coordinates" => [1.0, 2.0]})
%Geo.Point{
  coordinates: {1.0, 2.0},
  # New explicit default of WGS 84
  srid: 4326
}

If you were to then encode this value again, you'd end up with a new crs field in the output GeoJSON:

iex> %{"type" => "Point", "coordinates" => [1.0, 2.0]}
...> |> Geo.JSON.decode!()
...> |> GeoJSON.encode!()
%{
  "type" => "Point",
  "coordinates" => [1.0, 2.0],
  # Note the new `crs` field which was not present in the input to Geo.JSON.decode!/1
  "crs" => %{"properties" => %{"name" => "EPSG:4326"}, "type" => "name"}
}

This last behavior is the most potentially troublesome. However, we don't have a good way of distinguishing a case where you explicitly had the crs set in the input to the decoding function (in which case you would probably also like to have it present in the re-encoded version) compared to one in which it's been inferred.

Thanks to @​gworkman for reporting this issue (#129).

Potentially breaking change: Convert string coordinates to floats, or raise an error

... (truncated)

Changelog

Sourced from geo's changelog.

v4.0.0 — 2024-09-17

Potentially breaking change: Default decoded GeoJSON to SRID 4326 (WGS 84)

This aligns our GeoJSON decoding with the GeoJSON spec by making all decoded GeoJSON infer the WGS 84 datum (SRID 4326) by default. Whereas previously when you called Geo.JSON.decode/1 or decode!/1, we would return geometries with an :srid of nil, we now return srid: 4326. Likewise when encoding GeoJSON, we explicitly output a crs field indicating the datum.

This is unlikely to break real-world usage unless your implementation was assuming a different datum by default.

A couple examples of the changes:

Before:

iex> Geo.JSON.decode!(%{"type" => "Point", "coordinates" => [1.0, 2.0]})
%Geo.Point{
  coordinates: {1.0, 2.0},
  # Note the old default nil SRID!
  srid: nil
}

After

iex> Geo.JSON.decode!(%{"type" => "Point", "coordinates" => [1.0, 2.0]})
%Geo.Point{
  coordinates: {1.0, 2.0},
  # New explicit default of WGS 84
  srid: 4326
}

If you were to then encode this value again, you'd end up with a new crs field in the output GeoJSON:

iex> %{"type" => "Point", "coordinates" => [1.0, 2.0]}
...> |> Geo.JSON.decode!()
...> |> GeoJSON.encode!()
%{
  "type" => "Point",
  "coordinates" => [1.0, 2.0],
  # Note the new `crs` field which was not present in the input to Geo.JSON.decode!/1
  "crs" => %{"properties" => %{"name" => "EPSG:4326"}, "type" => "name"}
}

This last behavior is the most potentially troublesome. However, we don't have a good way of distinguishing a case where you explicitly had the crs set in the input to the decoding function (in which case you would probably also like to have it present in the re-encoded version) compared to one in which it's been inferred.

Thanks to @​gworkman for reporting this issue (#129).

... (truncated)

Commits

• 44ee1de Default decoded GeoJSON to SRID 4326 (WGS 84) per the spec (#219)
• 9ad50c3 Convert string coordinates to floats, or raise an error (#218)
• 7f3077b Fix broken test (#217)
• 6dc06aa Resolves felt/geo#193 (#194)
• 9c7847f Fix typo (#216)
• 122e7a6 Bump jason from 1.4.3 to 1.4.4 (#215)
• 1d35cf0 Bump ex_doc from 0.34.1 to 0.34.2 (#214)
• 20e8f4a Bump jason from 1.4.1 to 1.4.3 (#213)
• 099d4ea Bump ex_doc from 0.34.0 to 0.34.1 (#212)
• 7701d8b Bump benchee from 1.3.0 to 1.3.1 (#210)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Looks like geo is up-to-date now, so this is no longer needed.