Convert library to KotlinMultiplatform by Fabi755 · Pull Request #40 · maplibre/maplibre-java

Fabi755 · 2025-01-07T15:07:53Z

This PR is converting the whole code to Kotlin and also use converts to use Multiplatform Framework.

The goal is to use this library in more parts than the Android one. As we also converting the maplibre-navigation-android one to Kotlin Multiplatform and @sargunv is working on a Multiplatform Compose variant of MapLibre.

Converting the Java stuff to Kotlin, and removing the Android and JVM specific stuff was straight forward work. More complicated was to avoid a breaking change release, and keep the support with MapLibre Native for Android.

To use the new models, we need to convert it back to JVM with toJvm() extension. But this should only a temporary solution, as I would create a PR on MapLibre Native to use the newer variant of this library.

The idea is that I create also an PR for including this library to the iOS platform code.

We have starting using this PR changes already in our PR that convert the navigation core. There is also a small example usage of navigation with this GeoJSON lib.

@sotomski is also implemented this early state of this repository with navigation one in a private repository for Kurviger.

Changes

As mentioned, the project is now a KMP one. So we having a new code folder structure:

commonMain (generic Kotlin native)
commonJvm (JVM target code. Here located the old method schemes)
commonTest (tests for generic Kotlin native)
jvmTest (tests for JVM target. Only used for test utils setup yet)
appleTest (tests for Apple target. Only used for test utils setup yet)

To avoid a breaking change release, I added all old function patterns to the JVM module. These are marked as deprecated and are working as proxy. The logic is removed and all calls are forwareded to the generic functions in Multiplatform commonMain package.

Follow up

Finally we need to decide how we handle the naming of this repository & project. The current maplibre-java is not matching anymore. I suggest something like maplibre-geojson.

Fabi755 · 2025-01-17T14:26:52Z

Ready for review and discuss now @louwers and any other who is working on this project!

louwers

Thanks, this is a very welcomed contribution!

I could use some help from maybe @sargunv and @westnordost to review this.

Did you already test this with MapLibre Android? I was thinking, maybe we make a pre-release of both this library and MapLibre Android, so we can test it?

Are there any breaking APIs needed in MapLibre Android you are aware of?

frankkienl · 2025-01-17T15:16:12Z

( commenting here, to keep in the loop )

Fabi755 · 2025-08-13T12:27:33Z

From my side, this is ready to merge now (except the naming).

I improved the models already based on the reviews. And the Turf functions are now extension functions on the models.

The turf module was only used in the navigation project and the native Android test app. The native project itself is using only the models.
I removed all turf functions that were not used there. We can think about to also drop the Point.circle(...) functions, that is only used in the test app of the native project.

And we need to discuss about the naming. Should we keep the turf? Or do a util will be better here, because we don't want be a turf.js copy.

westnordost · 2025-08-14T11:05:27Z

I put the review of this on my todo, since it is a lot, and I will review on the side bit by bit, it will take some time.
Especially regarding the multiplatform+gradle+iOS things, I am not so proficient.

louwers · 2025-08-14T12:10:47Z

Since these are dependencies of MapLibre Android, I would like to have a migration plan and probably a draft PR with the needed changes.

westnordost

I've read through the data classes and started reading the serializers. Love how clean it is, I found mostly typos.

For the latter, I noticed that this is a lot of boilerplate code as pretty much every single data class has a custom serializer, because of the coordinates field.
I recognize that the coordinates field is a different data structure for the different geometry types - a double array for the Point, an array of double arrays for LineString and MultiPoint, an array of arrays of double arrays for Polygon, MultiLineString and and array of arrays of arrays of double arrays of MultiPolygon so I guess maybe it can't be helped?

Anyway, two ideas to reduce copypasta / boilerplate:

abstract superclass or delegate class for the shared code (optional bbox, boilerplate serializer code)
serializers for linestring + multipoint as well as polygon+multilinestring should be the same, no?

westnordost · 2025-08-14T10:52:23Z

services-geojson/build.gradle

+    def xcf = new XCFrameworkConfig(project)
+    [iosX64(), iosArm64(), iosSimulatorArm64()].forEach { target ->
+        target.binaries.framework { framework ->
+            baseName = "maplibre-geojson"
+            xcf.add(framework)
+        }
+    }


What does this do? In other multiplatform libraries, I just see somethign like

Suggested change

def xcf = new XCFrameworkConfig(project)

[iosX64(), iosArm64(), iosSimulatorArm64()].forEach { target ->

target.binaries.framework { framework ->

baseName = "maplibre-geojson"

xcf.add(framework)

}

}

iosX64()

iosArm64()

iosSimulatorArm64()

Also, what about

linuxX64() linuxArm64() macosX64() macosArm64()

?

westnordost · 2025-08-14T11:09:03Z

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/Feature.kt

+    //TODO(fabi755): can we use here something generic (not from kotlinx) instead?
+    //  any idea?
+    /**
+     * Additional custom properties for this feature.
+     */
+    val properties: JsonObject? = null,


Map<String, Any?>?

I think JsonObject? is the best possible fit, because it can not have Any? values, just what is allowed in JSON, i.e. certain primitives, JsonArrays and JsonObjects.

Yes correct, but this is the only part where we force the developer using the serialization library (kotlinx.serialization). And exposing this library. The other parts are all internal and not relevant to the public API. But for now I also think, it's the best solution

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/FeatureCollection.kt

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/LineString.kt

westnordost · 2025-08-14T11:38:16Z

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/Point.kt

+    /**
+     * The [BoundingBox] of this point.
+     */
+    override val boundingBox: BoundingBox? = null,


Well, I guess this is where the GeoJson spec doesn't make much sense. (A bounding box for a point? Lol)

However, the GeoJson spec distinguishes between Positions and Points while this PR does not.

A Point is a Geometry (hence having a bbox is allowed) while positions (or coordinates) are not.

It's not a big issue, but since positions/coordinates are used all over (in Polygons, LineStrings, ...), that means that the (in memory) data carries a lot of superfluous null bboxes. Anyway, does anything speak against keeping closer to the GeoJson spec? (distinguish between Position and Point)

It's not a big issue, but since positions/coordinates are used all over (in Polygons, LineStrings, ...), that means that the (in memory) data carries a lot of superfluous null bboxes.

Very good hint! I don't see this part. Make sense to add also a Position model like in the spec 👍
Thanks!

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/Polygon.kt

westnordost · 2025-08-14T11:50:04Z

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/Polygon.kt

+    private fun LineString.requireLinearRing() {
+        require(points.size >= 4) {
+            "LinearString for Polygon rings need to be made up of 4 or more Points."
+        }
+
+        require(points.first() == points.last()) {
+            "LinearString for Polygon rings require first and last Point to be identical."
+        }


For more informative error message (i.e. which ring exactly is wrong):

Suggested change

private fun LineString.requireLinearRing() {

require(points.size >= 4) {

"LinearString for Polygon rings need to be made up of 4 or more Points."

}

require(points.first() == points.last()) {

"LinearString for Polygon rings require first and last Point to be identical."

}

private fun LineString.requireLinearRing(name: String, index: Int?) {

require(points.size >= 4) {

"${getRingName}: LineString for Polygon rings need to be made up of 4 or more Points."

}

require(points.first() == points.last()) {

"${getRingName}: LineString for Polygon rings require first and last Point to be identical."

}

private fun getRingName(name: String, index: Int?): String {

val indexString = index?.let { " at index $it" } ?: ""

return "$name$indexString"

}

(also, typo: "LinearString" -> "LineString")

westnordost · 2025-08-14T11:51:06Z

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/model/Polygon.kt

+    /**
+     * The outer [LineString] ring of this Polygon.
+     */
+    val outerLineStringRing: LineString,
+
+    /**
+     * The inner [LineString] rings of this Polygon. Or empty list if no inner holes exists.
+     */
+    val holeLineStringRings: List<LineString> = emptyList(),


Suggested change

/**

* The outer [LineString] ring of this Polygon.

*/

val outerLineStringRing: LineString,

/**

* The inner [LineString] rings of this Polygon. Or empty list if no inner holes exists.

*/

val holeLineStringRings: List<LineString> = emptyList(),

/**

* The outer [LineString] ring of this Polygon.

*/

val outer: LineString,

/**

* The inner [LineString] rings of this Polygon. Or empty list if no inner holes exists.

*/

val inner: List<LineString> = emptyList(),

I think this would be more consistent.

westnordost · 2025-08-14T12:30:30Z

services-geojson/src/commonMain/kotlin/org/maplibre/geojson/utils/Json.kt

+    classDiscriminatorMode = ClassDiscriminatorMode.ALL_JSON_OBJECTS
+
+    // Encode
+    encodeDefaults = true


wouldn't that encode e.g. null for every Point (and other Geometry) for bbox?

Co-authored-by: Tobias Zwick <newton@westnordost.de>

westnordost

I didn't look at the tests because I think you just converted them to Kotlin and made them work after any interface changes you did, right?

Regarding the geodesy, it looks like the antimeridian is not taken into account at all. I expect this could lead to all kind of problems, but anyway, if it should not be implemented, then it should at least be very clearly documented at all affected places.

I also noticed that quite a bit of functionality that was available earlier seems to be missing now, such as

GeometryCollection.combine
GeometryCollection.explode
MultiPolygon.toMultiLineString
Polygon.toLineString
Polygon.contains
MultiPolygon.contains
Geometry.bbox
GeometryCollection.bbox
BoundingBox.toPolygon
Polygon.area
MultiPolygon.area
Geometry.center
GeometryCollection.center

I don't know if all of these are really necessary, but some look pretty necessary (point in polygon for example).
Edit: I see you stated earlier that you removed unused ones, ok.

westnordost · 2025-08-18T19:44:37Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+    return drop(1)
+        .mapIndexed { index, point ->
+            // Using unmodified index for previous point is working,
+            // because we drop the first point
+            get(index).distanceTo(point, unit)
+        }
+        .sum()


Clever. But also, a bit difficult to understand.

How about

/** Return a sequence that iterates through the given list of points in pairs */ internal fun Iterable<Point>.asLineSequence(): Sequence<Pair<Point, Point>> = sequence { val it = iterator() if (!it.hasNext()) return@sequence var p1 = it.next() while (it.hasNext()) { val p2 = it.next() yield(p1 to p2) p1 = p2 } }

and then

Suggested change

return drop(1)

.mapIndexed { index, point ->

// Using unmodified index for previous point is working,

// because we drop the first point

get(index).distanceTo(point, unit)

}

.sum()

return asLineSequence().sumOf { (p1, p2) -> p1.distanceTo(p2, unit) }

?

Actually, this convenience function would also make implementation of List<Point>.along slightly more straightforward.

westnordost · 2025-08-18T19:49:55Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+fun Point.findMidpoint(to: Point): Point {
+    val dist = this.distanceTo(to, MeasureUnit.MILES)
+    val heading = this.bearingTo(to)
+    return this.destination(dist / 2, heading, MeasureUnit.MILES)
+}


Hmm, other functions are not named something with find... (findLength, findBearingTo, ...), but of course, poin1.midpoint(point2) reads odd, true. I think a non-extension-function would be more expressive: midpoint(point1, point2)

Suggested change

fun Point.findMidpoint(to: Point): Point {

val dist = this.distanceTo(to, MeasureUnit.MILES)

val heading = this.bearingTo(to)

return this.destination(dist / 2, heading, MeasureUnit.MILES)

}

fun midpoint(p1: Point, p2: Point): Point {

val dist = p1.distanceTo(p2, MeasureUnit.RADIANS)

val heading = p1.bearingTo(p2)

return p1.destination(dist / 2, heading, MeasureUnit.RADIANS)

}

westnordost · 2025-08-18T20:09:40Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/MeasureUnit.kt

+/**
+ * Enum class representing various units of measurement and their corresponding factors.
+ * These units are used for geographical and mathematical calculations, particularly
+ * in the context of distance and angular measurements.
+ */
+@Suppress("unused")
+enum class MeasureUnit(val factor: Double) {


Is this from Turf, or from the old Java API?

I find a bit strange:

CENTIMETERS and also CENTIMETRES, METERS and METRES, KILOMETRES and KILOMETERS, why??

why even have anything else than METERS in SI measurement system? Users will I think be able to divide by 1000 for kilometers etc. themselves

An API like that requires the use of the MeasureUnit in every single function that deals with distances. why not always return in some standard unit, e.g. meters or probably rather degrees (because not dependent on hardcoded earth circumference) and either let the user do whatever conversion he needs after or provide convenience functions for that? MeasureUnit hardcodes the values for the circumference of Earth (except degrees, radians)

westnordost · 2025-08-18T20:11:23Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/MeasureUnit.kt

+    KILOMETRES(factor = 6373.0);
+
+    companion object {
+        val DEFAULT = KILOMETERS


What is this for? This makes it opaque what DEFAULT actually is wherever this is set as a default parameter.

Copied from before. But true, using this directly make it clear 👍

westnordost · 2025-08-18T20:18:30Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+    val difLat = degreesToRadians((point.latitude - this.latitude))
+    val difLon = degreesToRadians((point.longitude - this.longitude))
+    val lat1 = degreesToRadians(this.latitude)
+    val lat2 = degreesToRadians(point.latitude)
+
+    val value = sin(difLat / 2).pow(2.0) + sin(difLon / 2).pow(2.0) * cos(lat1) * cos(lat2)
+
+    return radiansToLength(
+        2 * atan2(sqrt(value), sqrt(1 - value)), unit
+    )


This will not yield correct results if the line between point A and point B crosses the antimeridian.

westnordost · 2025-08-18T20:24:13Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+ * @param unit The unit of measurement.
+ * @return A [Feature] containing the closest point and properties for index and distance.
+ */
+fun LineString.closestPoint(point: Point, unit: MeasureUnit = MeasureUnit.DEFAULT): Feature {


Why not return a DistancePoint here? Returning some Feature with properties with hardcoded keys seems unnecessary (and requires additional documentation to make sense of for lib users)

westnordost · 2025-08-18T20:30:58Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+ * @param points The list of points.
+ * @return The nearest point in the list.
+ */
+fun Point.closestPoint(points: List<Point>): Point {


That point1.closestPoint(emptyList()) returns point1 sounds odd. Not sure if this function is necessary at all, after all,

points.minBy { it.distanceTo(point) }

is hardly longer than

point.closestPoint(points)

but if it is necessary, I'd find it perfectly fine if it threw NoSuchElementException when points is empty.

westnordost · 2025-08-18T20:35:19Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+    val longitude1 = degreesToRadians(longitude)
+    val latitude1 = degreesToRadians(latitude)
+    val bearingRad = degreesToRadians(bearing)
+
+    val radians = lengthToRadians(distance, unit)
+
+    val latitude2 = asin(
+        sin(latitude1) * cos(radians) + cos(latitude1) * sin(radians) * cos(bearingRad)
+    )
+    val longitude2 = longitude1 + atan2(
+        sin(bearingRad) * sin(radians) * cos(latitude1),
+        cos(radians) - sin(latitude1) * sin(latitude2)
+    )
+
+    return Point(
+        radiansToDegrees(longitude2),
+        radiansToDegrees(latitude2)
+    )


If the resulting point crosses the antimeridian, the resulting point will have a longitude outside of the expected bounds of -180 and +180. Not sure if valid lat+lon are required/enforced? But it could very well be that software that uses the Point data structure assumes that the points are valid lat lon coordinates.

westnordost · 2025-08-18T20:38:15Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Measurement.kt

+ * @property onLine1 True if the intersection is on the first line segment.
+ * @property onLine2 True if the intersection is on the second line segment.
+ */
+data class LineIntersects(


Suggested change

data class LineIntersects(

private data class LineIntersects(

doesn't need to be exposed as long as it is only used internally

westnordost · 2025-08-18T20:40:04Z

services-turf/src/commonMain/kotlin/org/maplibre/geojson/util/Transformation.kt

+ * @return A [Polygon] representing the circle.
+ * @throws IllegalArgumentException if steps is less than 1.
+ */
+fun Point.circle(


or circle(point: Point, radius: Double, ...)? Or Point.createCircle?

westnordost · 2025-08-18T21:40:38Z

And we need to discuss about the naming. Should we keep the turf? Or do a util will be better here, because we don't want be a turf.js copy.

or geodesy? I agree with not mentioning turf, it could be misleading.

jgillich · 2025-09-16T03:41:50Z

Have we considered forking spatialk under the maplibre org? It's already used by maplibre-compose and it's probably(?) more idiomatic. I'd be happy to help maintain a fork since I also have several open PRs that have gone unanswered

sargunv · 2025-09-16T04:26:30Z

I don't have any strong opinion on whether to use this or fork Spatial-K, but will note that:

I find spatial-k's API is quite nice to use, especially the DSL for constructing geometry
I haven't tried this one yet

MapLibre Compose uses Spatial-K right now. Long term, I'll most likely use whichever is maintained under the MapLibre org, whether that's a fork of Spatial-K or this KMP port.

louwers · 2025-09-16T09:17:56Z

@jgillich Here is the process for onboarding a new repo: https://github.com/maplibre/maplibre/issues/new?template=new-repo-checklist.md

louwers · 2025-09-16T12:04:47Z

@Fabi755 Do you want to try updating MapLibre Android in the maplibre-native repo with one of the pre-releases?

Fabi755 · 2025-09-16T12:07:32Z

Yes I can do this as next step. I'm back from my holiday now, and will try this out next 👍

jgillich · 2025-09-16T15:59:42Z

I have submitted a proposal for forking spatialk ^, feel free to share your thoughts

Fabi755 added 12 commits December 28, 2024 13:24

Enable Kotlin support for turf module

1625b64

Migrate Turf module to Kotlin

e29098a

Migrate GeoJSON models to Kotlin

6bc8627

Clean up

a9d14cd

Update turf module to new models

b06eba2

Fix tests

b21a898

Clean up, Add missing documentation, Fix open todos

9f49e3f

Migrate constant units to enum

ca54686

Remove Android & Java dependencies

bfc062c

Convert GeoJSON module to KotlinMultiplatform project

ce5552a

Convert Turf module to KotlinMultiplatform project

568b52b

Keep previous JVM protocols on GeoJSON module

e79277b

Fabi755 changed the title ~~Convert library to KotlinMultiplatform~~ DRAFT: Convert library to KotlinMultiplatform Jan 8, 2025

Fabi755 added 12 commits January 8, 2025 15:39

Keep previous JVM protocols on Turf module

2e4c0cd

Fix publishing KMP modules

98dd14f

Remove toolchain annotation

85a123e

Fix property converting of deprecated Feature

e138125

Fix lineSlice issue

96bef08

Make polyline utils static

17aa05a

Fix missing geometry converting

5b3624c

Update to latest Kotlin version

8c83b63

Set build info

4c5503b

Add iOS ARM test resource copying task

ded1bef

Make feature properties editable

e44e8fb

Finalize build configuration

a92c8e3

Fabi755 changed the title ~~DRAFT: Convert library to KotlinMultiplatform~~ Convert library to KotlinMultiplatform Jan 17, 2025

louwers requested a review from artakka January 17, 2025 14:35

louwers reviewed Jan 17, 2025

View reviewed changes

Fabi755 added 3 commits August 13, 2025 13:19

Add tests for turf utils

93dc3be

Make serializers work on Kotlin native

9623ee9

Fix tests on node

00720ff

Fabi755 marked this pull request as ready for review August 13, 2025 12:27

Fabi755 changed the title ~~WIP: Convert library to KotlinMultiplatform~~ Convert library to KotlinMultiplatform Aug 13, 2025

westnordost reviewed Aug 14, 2025

View reviewed changes

Fabi755 and others added 7 commits August 14, 2025 23:30

Fix typo

d329ce0

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typo

8b6d0cd

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typo

a5b624c

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typo

9cd40af

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typo

839344f

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typo

0e035ff

Co-authored-by: Tobias Zwick <newton@westnordost.de>

Fix typos

c10c99a

Co-authored-by: Tobias Zwick <newton@westnordost.de>

westnordost requested changes Aug 18, 2025

View reviewed changes

jgillich mentioned this pull request Sep 16, 2025

Onboarding repository Spatial K maplibre/maplibre#475

Closed

28 tasks

birkskyum mentioned this pull request Sep 22, 2025

Call for Submissions: Sep 2025 Newsletter maplibre/maplibre.github.io#449

Closed

This was referenced Sep 22, 2025

Code Review: Things that should be taken from maplibre-java#40 maplibre/spatial-k#154

Closed

Generic Position serializer maplibre/spatial-k#150

Merged

birkskyum mentioned this pull request Sep 27, 2025

MapLibre Native Android 13.0.0 maplibre/maplibre-native#2736

Open

westnordost mentioned this pull request Sep 29, 2025

simplify position constructor maplibre/spatial-k#195

Merged

	data class LineIntersects(
	private data class LineIntersects(

Uh oh!

Comments

Conversation

Fabi755 commented Jan 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Follow up

Uh oh!

Fabi755 commented Jan 17, 2025

Uh oh!

louwers left a comment

Choose a reason for hiding this comment

Uh oh!

frankkienl commented Jan 17, 2025

Uh oh!

Fabi755 commented Aug 13, 2025

Uh oh!

westnordost commented Aug 14, 2025

Uh oh!

louwers commented Aug 14, 2025

Uh oh!

westnordost left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fabi755 Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

westnordost Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

westnordost Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westnordost left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westnordost Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westnordost Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Fabi755 commented Jan 7, 2025 •

edited

Loading

westnordost left a comment •

edited

Loading

Fabi755 Aug 19, 2025 •

edited

Loading

westnordost Aug 14, 2025 •

edited

Loading

westnordost Aug 14, 2025 •

edited

Loading

westnordost left a comment •

edited

Loading

westnordost Aug 18, 2025 •

edited

Loading

westnordost Aug 18, 2025 •

edited

Loading