Hi Gerd
I don't understand all of your comments, but I think that either I
Yes, sorry, everything you were saying was fine, and I am confusing the issues by talking about other things. I will try to keep messages separate.
missunderstand the code in RoadDef or something is wrong.
Yes, something is wrong. Or more accurately: something is different to the way Garmin makes its maps, but it (mostly?) works.
The comment in RoadDef says * A road definition. This ties together all segments of a single road * and provides street address information.
Yes, I still believe that this is how it is meant to work.
but the current implementation works different.
Correct.
In StyledConverter, we create one MapRoad instance for each segment of an OSM way. MapRoad itself creates one instance of RoadDef for this single segment. The RoadDef class contains code to handle multiple segments at the same zoom level.
Yes. But I think the only time that we get multiple segments is when a line is split because it is too big for a subdivision.
So, if my assumption is right that the order of segments does matter, we should probably make sure that the entries in NET1 appear in the right order,
- I don't think that the order of the entries in NET1 matters. - The order of lines within a single NET1 entry may matter (but I don't know for sure).
or we should not create multiple RoadDef instances for a single OSM way.
We should probably join lines (like --merge-lines) and then prevent subdivisions from growing too much. The problem is that we grow subdivisions to fit lines so that there is a lot of overlap. The alternative is to limit subdivisions so that they only overlap a little and trim lines at their borders. It is similar to the same problem with splitter. Its hard to explain without a diagram, and I would like a tool that shows the layout of the subdivisions so that I can compare the strategy that we use compared to other maps. ..Steve