Mapmapper wrote:
I dont now, how to make a log-file. I added a picture with the maptool-warnings and a picture of the map with a missing part of a street.
I was talking about some extracts from the file produced with
Code:
maptool -i in.osm out.bin 2>&1 |tee log.txt
Anyway, your example was quite helpful.
Mapmapper wrote:
I tested without resolved Multipolygones and with resolved Multipolygones at the end and start of way-section. The result is, that the problem is always there, but more parts of streets missing with resolved Multipolygones. If they are at the beginning of the way-section, they are complete, at the end, no resolved appears on the map. That means, that the ways at the end of the way-sections are the problem.
I was thinking that the problem is node id values. Ways at the end of way section (whith higher way ids) in average would have higher node numbers and more probably would cross any existing limitations.
But the missing
way from your sample screen unfortunately doesnt seem to have any node id which might cross the signed 32 bit int limit.
Mapmapper wrote:
...
I looked for the reason myself and cannot find it. I saw a lot of type mismatch in osm.c. unsigned long long ids matched with long long ids.
...
In line 1250, there is used realloc. I think, there should be g_realloc. In the whole file g_realloc and similiar is used. But this is not very important.
The only problem I've noticed is that maptool sometimes still uses signed int formats to report node ids. It's quite confusing, so I'll fix it.
Mapmapper wrote:
In line 1235 attr_present[idx]=2. I think, it should be 3 there. But this never used in rule-file-part, so there should be go nothing wrong yet.
This is done intentionally. We're counting weight to find matches which use less wildcards than others. So "%s=*" and "*=%s" are given the same values.
Mapmapper wrote:
The only thing, that I could imagine is, that it works on 64-bit-Systems, because long int, long long and only int has different number of bytes on different systems. In C, variables are not platform-independent.
I have tired to reproduce this on my 32 bit system, but had no success. Probably it was because I was not using big files with loads of fresh data. But can't you you be getting your errors because you have a broken dataset? Can you try to reload it from the source?
Mapmapper wrote:
maptool says, that there are 134.000.000 nodes. This should be not to much for unsigned long.
sure.
Actually, maptool does not assign any internal numbering to all nodes. It uses osm ids when it has to reference a node. These ids are currently expected to be cut down to 32bit unsigned ints.