I disagree that much code duplication would occur even if every node that utilized map data in an unstructured Lanelet2 format has to do some sort of decoding - this is the purpose of shared libraries. A single encode and a single decode function should exist (or be created) in a shared library which can be linked against by any nodes needing to handle Lanelet2 format data. The decode function would return a class structure holding the in-memory representation of the map (or subset of the map) which can be manipulated as-needed by the consuming node and the encode function would simply return the encoded, unstructured data which can be published. Minimal code duplication.
On a related note, I agree with @simon-t4 - a structured representation of the data being passed around doesn’t serve much practical purpose with the design of Lanelet2 having such a strong decoupling of the primitives from what a grouping of primitives represent. The overhead inherent in encoding/decoding them as structured messages and the additional bandwidth required for the metadata are also non-trivial. Given that network I/O is second only to disk I/O in order of the most expensive operations you can perform on a modern computer, I lean heavily toward unstructured transport. I also think the actual implementation of how we access the map or a subset of the map (making requests to a server, segmenting the map, etc.) are somewhat irrelevant to representation of the data at the transport layer. Whether we split this up into multiple nodes or have a single server handling the map, they are still passing around the same basic datum and, in the case of Lanelet2, those datum are not easily reconstructed into the objects they represent without the structure of the Lanelet2 class objects.