Fix documentation links

Cargo.toml

@@ -24,4 +24,4 @@ edition = "2021"
 keywords = ["gis", "map", "rendering"]
 license = "MIT OR Apache-2.0"
 repository = "https://github.com/Maximkaaa/galileo"
-version = "0.1.0"
+version = "0.1.1"

galileo-mvt/Cargo.toml

@@ -8,6 +8,7 @@ license.workspace = true
 keywords.workspace = true
 documentation = "https://docs.rs/galileo-mvt"
 description = "Mapbox Vector Tile format reader"
+readme = "../README.md"
 exclude = [
     "test-data/*"
 ]

galileo-types/Cargo.toml

@@ -8,6 +8,7 @@ license.workspace = true
 keywords.workspace = true
 documentation = "https://docs.rs/galileo-types"
 description = "Trait based geo geometries and algorithms"
+readme = "../README.md"
 
 [features]
 default = ["geo-types", "geodesy"]

galileo-types/src/geometry_type.rs

@@ -3,7 +3,7 @@
 /// This trait allows automatically implement [`Geometry`](crate::Geometry) trait for types that implement specific
 /// geometry traits (e.g. [`Polygon`](crate::Polygon) etc).
 pub trait GeometryType {
-    /// Type of the geometry. [`Geometry`] trait is implemented for one of the following types:
+    /// Type of the geometry. [`Geometry`](crate::Geometry) trait is implemented for one of the following types:
     /// * [`PointGeometryType`]
     /// * [`MultiPointGeometryType`]
     /// * [`ContourGeometryType`]

galileo-types/src/lib.rs

@@ -18,8 +18,8 @@
 //!
 //! Because of that, `galileo-types` crate makes strong distinction between geographic and cartesian coordinates. Basic
 //! trait for coordinates in any space is a point:
-//! * [`GeoPoint`] is defined in [`geo`] module, and represents a point in geographic coordinate system
-//! * [`CartesianPoint2d`] is defined in [`cartesian`] module, and represents a point in cartesian coordinate system
+//! * [`GeoPoint`](geo::GeoPoint) is defined in [`geo`] module, and represents a point in geographic coordinate system
+//! * [`CartesianPoint2d`](cartesian::CartesianPoint2d) is defined in [`cartesian`] module, and represents a point in cartesian coordinate system
 //!   on a flat surface of the Earth (or another stellar body)
 //!
 //! Geometry traits are generic over point type they are constructed with.
@@ -45,16 +45,17 @@
 //! different set of methods with their own meaning.
 //!
 //! At this point, one such trait is defined:
-//! * [`CartesianPoint3d`] - a point in *XYZ* coordinate system, where *Z* is defined in projection units.
+//! * [`CartesianPoint3d`](cartesian::CartesianPoint3d) - a point in *XYZ* coordinate system, where *Z* is defined in projection units.
 //!
 //! # Converting between coordinate systems
 //!
-//! Converting between different types of coordinates is done using [`Projections`](Projection).
+//! Converting between different types of coordinates is done using [`Projections`](geo::Projection).
 //!
 //! # Geometry types
 //!
 //! A subset of OGC geometry types are supported at the moment:
-//! * [`GeoPoint`], [`CartesianPoint2d`], [`CartesianPoint3d`] (correspond to OGC *Point* geometry)
+//! * [`GeoPoint`](geo::GeoPoint), [`CartesianPoint2d`](cartesian::CartesianPoint2d), [`CartesianPoint3d`](cartesian::CartesianPoint2d)
+//!    (correspond to OGC *Point* geometry)
 //! * [`MultiPoint`]
 //! * [`Contour`] (corresponds to OGC *LineString* geometry with slight difference, check the trait's documentation)
 //! * [`MultiContour`] (corresponds to OGC *MultiLineString* geometry)
@@ -70,7 +71,7 @@
 //! and at the same time let the user override default implementation with more specific one (because of
 //! trait specialization problem).
 //!
-//! There is a way around those limitations though. You can use [`GeometryType`] trait to make your type, implementing
+//! There is a way around those limitations though. You can use [`GeometryType`](geometry_type::GeometryType) trait to make your type, implementing
 //! any of the specific geometry traits, also implement [`Geometry`] trait automatically.
 //!
 //! # Implementation for foreign types

galileo/src/control/mod.rs

@@ -8,8 +8,8 @@
 //! way to handle user interactions for the application.
 //! 3. `EventProcessor` has a list of [`UserEventHandler`]s, which change the state of application based on the events.
 //!
-//! To write a user interaction logic, the app must provide an implementation of [`UserEventHandler`] trait (or use
-//! a provided one like [`CustomEventHandler`]) and add it to the `EventProcessor` handler list.
+//! To write a user interaction logic, the app must provide an implementation of [`UserEventHandler`] trait and add it
+//! to the `EventProcessor` handler list.
 
 use crate::map::Map;
 use galileo_types::cartesian::Point2d;
@@ -95,15 +95,15 @@ pub enum UserEvent {
     Zoom(f64, Point2d),
 }
 
-/// Value returned by an [`EventHandler`] to indicate the status of the event.
+/// Value returned by an [`UserEventHandler`] to indicate the status of the event.
 pub enum EventPropagation {
     /// Event should be propagated to the next handler.
     Propagate,
     /// Event should not be propagated to the next handler.
     Stop,
     /// Event should not be propagated to the next handler, and the current event handler should be considered the
     /// owner of the event. This is used, for example, to indicate, that the handler wants to take ownership of
-    /// the [`UserEvent::DragStart`], so that all consequent drag events are only processed by this handler.
+    /// the [`UserEvent::DragStarted`], so that all consequent drag events are only processed by this handler.
     Consume,
 }
 

galileo/src/layer/feature_layer/feature_store.rs

@@ -4,7 +4,7 @@ use std::sync::{Arc, Mutex};
 ///
 /// All access operations in the storage return [FeatureContainer] or [FeatureContainerMut] structs. These containers
 /// then allow access to references to the features themselves. When a feature is modified through
-/// [FeatureContainerMut::into_mut] or [FeatureContainerMut::edit_style], the `FeatureLayer` containing them
+/// [AsMut::as_mut] or [FeatureContainerMut::edit_style], the `FeatureLayer` containing them
 /// is automatically notified of the change, and the layer can update rendering of the given features without redrawing
 /// the whole feature set.
 #[derive(Default)]

galileo/src/layer/feature_layer/mod.rs

@@ -40,7 +40,7 @@ pub use symbol::Symbol;
 /// hand, the CRS of the layer doesn't have to be same as the CRS of the map. When the layer is requested to be rendered,
 /// it will project all its features into needed CRS automatically.
 ///
-/// Feature layer can render features differently at different resolutions. See [`FeatureLayer::new_with_lods`] for
+/// Feature layer can render features differently at different resolutions. See [`FeatureLayer::with_lods`] for
 /// details.
 pub struct FeatureLayer<P, F, S, Space>
 where

galileo/src/lib.rs

@@ -1,9 +1,6 @@
 //! Galileo is a cross-platform map rendering engine. It supports raster and vector layers, custom and flexible styling,
 //! working with different coordinate systems and projects.
 //!
-//! <div class="warning">This crate is in pre-release alpha stage. Documentation is not complete and some parts do not
-//! work yet.</div>
-//!
 //! # Quick start
 //!
 //! You can create a simple interactive map with two layers by this code:
@@ -41,7 +38,7 @@
 //! care of creating a window, setting up GPU context and configuring user interactions to control the map position
 //! with mouse or touch.
 //!
-//! Calling [`.run()`](galileo_map::GalileoMap) starts `winit` event loop, which will run until the user
+//! Calling [`.run()`](GalileoMap) starts `winit` event loop, which will run until the user
 //! closes the window.
 //!
 //! Running the map in a dedicated window is quite straightforward, but to integrate Galileo map into your application
@@ -51,8 +48,8 @@
 //!
 //! As surprising as it is, everything in a mapping library revolves around
 //!
-//! * [`Map`](Map) struct, which is quite simple by itself and contains only currently displayed
-//!   [`MapView`](MapView), inner state, such as animation parameters, and a set of
+//! * [`Map`] struct, which is quite simple by itself and contains only currently displayed
+//!   [`MapView`], inner state, such as animation parameters, and a set of
 //! * [`layers`](layer) that actually contain data and know how it should be displayed. There are different
 //!   types of layers depending on what kind of data they use (images, vector tiles, geometric features etc) and on
 //!   their capabilities for transforming that data into what a user wants to see. To render the data layers use
@@ -64,7 +61,7 @@
 //!
 //! In case a user is supposed to interact with the map in your application, you would also need
 //!
-//! * [`EventProcessor`](control::event_processor::EventProcessor) to convert raw system event into
+//! * [`EventProcessor`](control::EventProcessor) to convert raw system event into
 //!   some intermediate representation, more convenient to deal with, and some
 //! * [`controls`](control) that actually change state of the map or layers based on the user input.