@easbar could you verify that the VectorTile support still works as intended? I simply recreated that file based on the information in#2698

I've added a unit test just to be sure. At least the decoding seems to work correctly.

Blocked byMobilityData/gtfs-realtime-bindings#138 😞

@karussell we could simply generate the protobuf classes forGtfsRealtime andVectorTile as part of our build. We can useprotobuf-maven-plugin to automate this. As a small benefit, we get rid of generated code in our repository and don't have to keep the protobuf version of three dependencies in sync. WDYT?

@karussell The current PR now generates both classes from their protobuf source.

Thanks for the work here@otbutz!

generates both classes from their protobuf source.

I would avoid creating the pbf as part of the build as I made not too good experiences with different IDEs when this is done. Probably the better way is to fork and create com.graphhopper.external::gtfs-realtime-bindings? If the issue is a blocking issue for this PR?

I would avoid creating the pbf as part of the build as I made not too good experiences with different IDEs when this is done.

Fair point. I've tested the integration in Intellij which worked flawlessly. I've added the necessary m2e annotations for Eclipse as well.

Probably the better way is to fork and create com.graphhopper.external::gtfs-realtime-bindings?

We'd need to create an additional external project if we take that approach.VectorTile was manually generated fromvector_tile.proto and also needs to be kept in sync with the protobuf version we're using internally.

@karussell how should we proceed here? I can create two repositories which encapsulate the pre-built protobuf classes.

With two projects do you mean the VectorTile and realtime GTFS dependencies?

Currently we are using the VectorTile.java which was created once. Couldn't we just update it to use the more recent 4.x version without the need for an external dependency?

btw: Does the PBF version update have other advantages, such as faster import?

Currently we are using the VectorTile.java which was created once. Couldn't we just update it to use the more recent 4.x version without the need for an external dependency?

We could do this. However, if I remember correctly, newer versions of protobuf are more restrictive in terms of the compatibility of generated classes with the library. We might need to update it every time we update the protobuf dependency.

We could also mix both strategies. The generated files stay checked into the repository, but we provide the manual Maven goal to easily regenerate them if we update the dependency.

btw: Does the PBF version update have other advantages, such as faster import?

Maybe? I haven't done any benchmarks as the focus was purely on dependency management. Our current dependency won't be updated any longer, so we'll need to switch either way 🤷

@karussell the generated classes are now in the repository and can be recreated with theprotobuf maven profile:

mvn compile -P protobuf

@karussell any chance to get this merged for the v11 release?

Unfortunately no. This is too tricky and also not fully tested (I think) for the parts that were replaced.

@karussell feel free to give it a spin 😉