initial vector tile integration

[rkreienbuehl]

New MR as discussed.

[p-lr]

This is much clearer now. I'll have look and the goal is to merge asap.

[p-lr]

We don't need this, we're using compose navigation

[rkreienbuehl]

In the meantime I will try to get a complete list of what is missing in case of rendering compared to the MapLibre Style Specs.

[p-lr]

Not sure exactly why we need this

[p-lr]

Are those changes necessary?

[p-lr]

Just to clarify: my goal for now is only to ensure the minimum changes are made to the core library. The rest will come later.
I've started to make comments. Also, I'd like to regroup vector specific classes under vector package.
For example, SymbolState should be into vector/ui/state and so on. Another example:
SymbolComposer.kt into vector/ui/symbols
That will simplify the review. Could you do this?

[p-lr]

Instead of making a ton of annoying comments, we can do it this way:
In addition to the vector package refactoring, could you please have a look at all the changes made to the core library, and remove the ones which aren't strictly necessary?
By doing this, when I'll do my final pass, I will know that the changes I see are changes you really want to make.

[rkreienbuehl]

Sure, I will refactor it. Some of the changes I need to look into, because they were made prior my work. I think today or maybe tomorrow I should push the changes in a commit.

[p-lr]

Ok no problem!

[rkreienbuehl]

I made the changes and packed it again in a single commit. In this instance I added a minimal implementation of infinity scroll y to be able to revert all changes in library/src/commonMain/kotlin/ovh/plrapps/mapcompose/core/VisibleTilesResolver.kt compared to master.
There are now no changes in core only small changes in api, ui/state and MapUi.kt. New Files are all held in vector package.
Should I also move MapState.addVectorLayer() into a separate api package in vector package?

• kotlinx-datetime is used in a test that @jershell implemented to measure performance
• pbandk is used to decode Protobuf

[p-lr]

I made the changes and packed it again in a single commit. In this instance I added a minimal implementation of infinity scroll y to be able to revert all changes in library/src/commonMain/kotlin/ovh/plrapps/mapcompose/core/VisibleTilesResolver.kt compared to master.

Good one. I haven't implemented infinity scroll y for practical reason. Do you see a use case? I would say this is out of scope for this feature.

Should I also move MapState.addVectorLayer() into a separate api package in vector package?

We can keep those in core indeed.

kotlinx-datetime is used in a test that @jershell implemented to measure performance

Alright, we just need to make sure it's added as testImplementation. My comment was on kotlinx-datetime only.

Thanks

[rkreienbuehl]

Good one. I haven't implemented infinity scroll y for practical reason. Do you see a use case? I would say this is out of scope for this feature.

Sorry, I meant infinite scroll x

Alright, we just need to make sure it's added as testImplementation. My comment was on kotlinx-datetime only.

It is added unter commonTest.dependencies.

[rkreienbuehl]

@p-lr Update from my side: when comparing the current state with the reference implementation of maplibre-style-spec I had some trouble to figure out what is implemented and what is missing. therefore I started reimplementing the expressions and by porting the ts implementation. This way it was easier to track what is missing. also legacy filters are handled like maplibre does it by converting them to expressions. Now all filters and expressions should be implemented.
I will proceed with implementing the remaining style features to hopefully get to a point where the style specs are completely implemented in the near future.

[p-lr]

Maybe also port the ts unit tests if they (hopefully) have them. This is a way to double check correctness.
Thanks!

[rkreienbuehl]

I invested a lot of time in the past few weeks, and am nearly finished with porting maplibre-gl-js to MapComposeMP. I also added tests for the ported logic. The vector part should then be feature complete as far as I can tell.
I then made an assessment of the logic with the help of ChatGPT to find missing features or undocumented divergences (keeping track of all the features is really hard, especially because I didnt started the code), and am working on fixing them. Will push all the changes including a rebase on master as soon as I am finished. Hopefully I am getting there this week, because afterwards my time is really limited, and I cannot work on it for quite some time.
If you find the time (or anyone from the community), reviewing, testing, fixing bugs and more important, improving performance, would be very helpful. Maybe a first merge would be good if someone else wants to contribute?
Keep you updated.

[p-lr]

That's great, thanks. Since you're getting close, it's best to have clear goals. Once you rebase on master, I'll be focusing on the changes to the core library. If this is going to be merged, all changes to the core must be carefully thought, and with absolute zero performance and risk to the existing raster tile rendering.
Last time we talked about it, you pointed out that some changes to the core are needed for performance reasons. I don't remember exactly but we were talking about the TileCollector.
I'm not sure what your plan is, but we don't need to get everything right in the first merge. We could have a "feature complete" but non-optimized version -- for now.

And when the focus will be on the optimization, I'll again be cautious on how and why changes are made.