minotor 1.0.0 → 1.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +3 -3
- package/README.md +1 -11
- package/package.json +3 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
|
|
1
|
+
## [1.0.1](https://github.com/aubryio/minotor/compare/v1.0.0...v1.0.1) (2025-02-03)
|
|
2
2
|
|
|
3
3
|
|
|
4
|
-
###
|
|
4
|
+
### Bug Fixes
|
|
5
5
|
|
|
6
|
-
*
|
|
6
|
+
* trigger new version after fixing types export ([b14dccc](https://github.com/aubryio/minotor/commit/b14dccc37b607fb9e06814bed9bd9795e47e6f5c))
|
package/README.md
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
A lightweight and easy to use public transit router primarily targeting client-side usage for research, data visualization, dynamic web and mobile apps.
|
|
6
6
|
|
|
7
|
-
Unlike most transit planners out there, **minotor**
|
|
7
|
+
Unlike most transit planners out there, **minotor** can store all the transit data for a given day in memory on the client, allowing for fast runtime queries using only local data.
|
|
8
8
|
This is particularly useful for highly dynamic applications or complex visualizations for research purposes where the user needs to query the data in real-time.
|
|
9
9
|
Privacy-conscious applications where the user does not want to share their location data with a server can also benefit from this model.
|
|
10
10
|
|
|
@@ -141,16 +141,6 @@ Make sure you have a working node setup as well as a protobuf compiler.
|
|
|
141
141
|
|
|
142
142
|
Releases are automatically published to npm when merging to the `main` or `beta` (pre-release) branch.
|
|
143
143
|
|
|
144
|
-
## Known issues
|
|
145
|
-
|
|
146
|
-
### \[Work in Progress\] Train splits in Switzerland
|
|
147
|
-
|
|
148
|
-
In the swiss GTFS feed, some transfers are missing for proper handling of trains that splits in two and diverge route at a given station.
|
|
149
|
-
They are modeled as 2 routes, one covering the full route of the first variant and the other covering the route for the other variant but only from the split station (on the platforms where the part of train splitting is located) to the destination.
|
|
150
|
-
The challenge is that no transfer indicates that it's possible to continue from the platform where the train arrives to the part of the platform where the other part of the train splits and continues on the other route.
|
|
151
|
-
This is for example the case with the train starting from Landquart splitting in Klosters to reach lower Engadin or Davos. A transfer between 8509068:0:3 and 8509068:0:3AB is missing to understand that it's possible to continue on the way to Davos.
|
|
152
|
-
While these transfers should ideally be handled at a route/trip level (the swiss feed contains only stop level transfers for now), artificially adding transfers between a station platform and its corresponding "sub-platforms" would be enough to tackle the issue in a minimal way.
|
|
153
|
-
|
|
154
144
|
## Roadmap
|
|
155
145
|
|
|
156
146
|
The project is under active development. Here are some of the features that are planned:
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "minotor",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.1",
|
|
4
4
|
"description": "A lightweight client-side transit router.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"minotor",
|
|
@@ -31,7 +31,8 @@
|
|
|
31
31
|
"exports": {
|
|
32
32
|
".": {
|
|
33
33
|
"import": "./dist/bundle.esm.js",
|
|
34
|
-
"require": "./dist/bundle.cjs.js"
|
|
34
|
+
"require": "./dist/bundle.cjs.js",
|
|
35
|
+
"types": "./dist/index.d.ts"
|
|
35
36
|
}
|
|
36
37
|
},
|
|
37
38
|
"types": "./dist/index.d.ts",
|