geojson

A thin GeoJSON Layer above the aeson library

https://github.com/newmana/hs-geojson

Version on this page:1.3.3
LTS Haskell 22.41:4.1.1
Stackage Nightly 2023-12-26:4.1.1
Latest on Hackage:4.1.1

See all snapshots geojson appears in

BSD-3-Clause licensed by Dom De Re
Maintained by Andrew Newman
This version can be pinned in stack with:geojson-1.3.3@sha256:8a2379fd315ebb7ed38bfe8983734d0ed9f29a5ba47bc715206c926d5d83c934,4001

Module documentation for 1.3.3

geojson Build Status Hackage

A thin GeoJSON Layer above the aeson library

Building the project

Install the dependencies with:

cabal install --only-dependencies

Optionally add --enable-tests if you intend to run the unit tests

The project must be “configured” at least once everytime geojson.cabal changes, this can be done with:

cabal configure

If you wish to run the unit tests you will have to run:

cabal configure --enable-tests

Then finally build it with:

cabal build

See cabal build --help for more build options.

Running Unit Tests

After running cabal build, you can run the unit tests with the command:

cabal test

Adding Unit tests

Currently only files in the src/ directory are searched for tests, it is assumed that the code in main/ is a thin layer of code that uses modules from src/.

Development: Cabal Dependency Hell?

Cabal’s great, but when you are developing a few different projects with their own dependency chains, sometimes installing all your libraries to the same place causes problems,

Consider trying [cabal-dev] cabal-dev. In terms of using it, all thats required is replacing cabal with cabal-dev in all the above command lines.

It will download and install all the dependencies for your project and install them in a cabal-dev/ directory in your project directory, and they will only be used for this project.

Those with newer versions of cabal (>= 1.18 I think) can skip cabal-dev and instead run cabal sandbox init, and just start runnign the above instructions as is from cabal install --only-dependencies

Changes

1.3.0

1.3.1->1.3.3

  • Fixed Validation dependency.

1.2.0 -> 1.3.0

1.2.x

1.1.1 -> 1.2.0

  • Added the LineString data type for use with GeoLine, now a GeoLine with less than 2 positions is a type error or a parse error, as it should be according to the [spec] (http://geojson.org/geojson-spec.html#linestring “LineString in the GeoJSON v1.0 spec”)

1.1.x

1.1.0 -> 1.1.1

  • Just some version bumps, the lens version bounds for the transformer library (<0.4) were causing some conflicts.

1.0.1 -> 1.1.0

  • Corrected an issue with the Polygon ([here] (https://github.com/domdere/hs-geojson/issues/2 “Polygon Issue”))
    • Introduced the LinearRing datatype to handle the LinearRings described in the spec.
      • Valid JSON for a LinearRing contains at least 4 points (this is checked, parsing fails if the list is too short) and the last element should match the first, but this isnt checked due to performance issues with the current implementation (though its a resolvable issue)).
      • A LinearRing can be converted to a List with fromLinearRing or you can just fold/traverse over it.
      • Creating a LinearRing can be done with one of these:
        • makeLinearRing :: a -> a -> a -> [a] -> LinearRing a
        • fromList and fromListWithEqCheck, which will return a Validate result (see the type sigs) and [Data.Validation] (https://hackage.haskell.org/package/validation “Data.Validation”)

1.0.x

0.0.2 -> 1.0.0

  • Migrated from json to aeson, all JSON instances were removed and replaced with ToJSON and FromJSON instances
  • GeoFeature and GeoFeatureCollection are now of kind * -> *, parameterised on the Property type, GeoFeature a and GeoFeatureCollection a are in ToJSON and/or FromJSON if a is in ToJSON and/or FromJSON respectively.
  • Lenses and prisms have been generated for each of the types.
  • Orphan Instances were removed. Orphan Instances are bad. Breaking type class coherency had some rather annoying consequences, you only need to import Data.Geospatial now and the ToJSON and FromJSON instances will come with it. I wanted to split up the files and thought seperating the instances from the declarations was a good idea but it wasnt. Instead I split the data types into seperate modules and kept the instances with their respective data type declarations.