0.5.5

What's Changed

• Bumped current dependencies to tackle all open Dependabot alerts by @jaspersiebring in #16

Full Changelog: 0.5.4...0.5.5

0.5.4

What's Changed

• Added toml parsing for automated docs versioning by @jaspersiebring in #13

Full Changelog: 0.5.3...0.5.4

0.5.3

What's Changed

• Replaced MkDocs with Sphinx by @jaspersiebring in #11

Full Changelog: 0.5.2...0.5.3

0.5.2

What's Changed

• Dropped mkdocs (prep for Sphinx move) by @jaspersiebring in #12

Full Changelog: 0.5.1...0.5.2

0.5.1

What's Changed

• Added documentation with Material for MkDocs by @jaspersiebring in #10

Full Changelog: 0.5.0...0.5.1

0.5.0

What's Changed

• Refactored monolithic CLI to more dedicated Typer commands with input validation by @jaspersiebring in #8

Full Changelog: 0.4.2...0.5.0

Refactor of monolithic CLI into more dedicated Typer commands (i.e. geococo new, geococo add and geococo copy). Also added basic path validation and explicit documentation through Typer (instead of parsing it from the docstring). That also allowed us to drop typer-cloup and docstring-parser and just use Typer. Also added datetime parsing (used to populate date_created).

0.4.2

What's Changed

• Enabled autogeneration of release notes by Github by @jaspersiebring in #9

Full Changelog: 0.4.1...0.4.2

0.4.1

What's Changed

• Added cli options for (super)category names and ids by @jaspersiebring in #7

Full Changelog: 0.4.0...0.4.1

0.4.0

What's Changed

• Added (super)category mapping and input data validation by @jaspersiebring in #6

Full Changelog: 0.3.0...0.4.0

Users can now provide keys for columns that contain (super)category names or ids. Ids are autogenerated starting from last known id (incremental sequence) if only names are given. The values associated with these keys and the geometries themselves are validated through Pandera.

This did require a downgrade to Pydantic 1.10.12 and some refactoring of Pydantic V2 specific code (e.g. manual fowarding of model names, dropping of InstanceOf) as Pandera does not support v2 (yet). Still worth it though, considering how it simplifies data validation (and we'll upgrade as soon as they support v2).

If the input data passes validation, the values will be used to add new Category instances (if any) to the dataset. These are then used to map any existing category information to the new annotations (if matched). This gives users the option to start a COCO dataset from pretty much any shapefile with annotations as long as it includes some reasonable identifier (i.e. not necessarily COCO-specific keys). New annotations can be added whenever and geococo will update the meta data accordingly.

Users can also manually update the category names in their dataset to something a bit more expressive (particularly useful if the dataset was started from a shapefile that only contained category ids). Any subsequent annotations with the same id will then use this new name.

0.3.0

What's Changed

• Added mapping of arbitrary label attributes to COCO's category_id by @jaspersiebring in #5

Full Changelog: 0.2.1...0.3.0